How to Write a Website RFP (With a Template)

A website RFP (request for proposal) is the document you send to agencies so they can propose an approach, a timeline and a price for your project. A good one gets you proposals you can compare side by side. A weak one gets you a stack of guesses, each priced against a different imagined project.

Below is what to include, a template you can copy section by section, and the mistakes that make good agencies decline to respond.

Before you write: a short discovery

Most RFP problems start before the document. Teams describe a solution ("we need a new WordPress site with a blog and a portal") before they have agreed on the problem.

The UK government's Service Manual puts it plainly: before you commit to building a service, you need to understand the problem that needs to be solved. Its discovery phase looks at users and what they are trying to achieve, at the constraints you would face in changing how the service runs, and at opportunities to improve things, and it says you should not start building during discovery. Nielsen Norman Group describes UX discovery the same way: research the problem space and frame the problem before designing, because moving forward on assumptions risks solving a problem that doesn't really matter.

A small business site doesn't need weeks of this. A few working sessions with the people who answer the phone, sell and deliver the service will do. Come out with answers to:

• What should the site do that it doesn't do now? Name outcomes: more booked consultations, fewer "what are your hours" calls, more applications from qualified caregivers.
• Who are the main visitors, and what is each trying to get done?
• What has to connect to the site: CRM, booking calendar, payments, an ERP, a client portal?
• What constraints exist: accessibility requirements, regulated content, approvals, a fixed launch date?

What to include in a website RFP

Keep it as short as the project allows. Agencies read many of these, and a clear ten pages beats a padded thirty.

1. About you. What the business does, who it serves, and how the website fits into how you win customers.
2. Problem and goals. Two or three measurable goals from discovery. Say how you measure them today, even if the answer is "we don't."
3. Audiences and tasks. Write the main tasks as user stories. The GOV.UK Service Manual format works well: "As a… I need/want/expect to… So that…". For example: "As an adult child arranging care for a parent, I need to see which areas the agency covers, so that I don't waste a call."
4. Scope. Pages or page types, content you have, content you need written, photography, integrations, and migration of existing content and URLs.
5. Technical context. Current platform, hosting, domains, who will edit the site after launch, and the systems it must talk to.
6. Constraints. Accessibility target, compliance considerations, brand guidelines, approval process.
7. Budget range. More on this below.
8. Timeline. The decision date, the desired start, any fixed launch date and why it is fixed.
9. Response format. A fixed list, so proposals line up.
10. Evaluation. How you will decide.
11. Logistics. Deadline for questions, deadline for proposals, a single contact, and whether shortlisted agencies get a call.

The template

Copy this structure and fill it in.

1. Overview. One paragraph: who we are, what we need, by when.

2. Goals. For each: the goal, how we'll measure it, and today's baseline.

3. Users and tasks. Three to eight user stories. Give each acceptance criteria written as "it's done when…", which is how the GOV.UK Service Manual suggests confirming that a story has met the user's need.

4. Scope. Three lists: in scope, out of scope, not sure yet. The "not sure" list is valuable because it invites agencies to advise you.

5. Content and assets. What exists, what needs writing, who approves it.

6. Integrations. For each system: what data moves, and in which direction.

7. Constraints. Accessibility, compliance, brand, hosting.

8. Budget. A range.

9. Timeline. Key dates.

10. Response format. Approach, relevant work, team, timeline, itemized cost, assumptions, references, ongoing support options.

11. Evaluation. Criteria and their weights.

12. Contacts and dates.

Should you include a budget?

Yes. Without a range, agencies either propose the version they guess you can afford, which you can't compare, or they decline. A range lets each agency show what it would do for that money and where it would spend it. If you genuinely don't know, say so, and ask each agency to price a core scope plus options. That shows you the cost drivers, which is useful in itself.

How to evaluate the responses

Write the scoring before you open the first proposal, so the most polished deck doesn't set the criteria. Give each criterion a weight that adds up to 100. As a hypothetical example, a firm whose main worry is a tricky booking integration might use 25 for understanding, 20 for relevant work, 25 for approach, 10 for team and 20 for cost. Score every proposal from 1 to 5 on each line, multiply by the weight, and have two people score separately before comparing notes. A simple set of criteria:

• Understanding of the problem. Did they restate your goals in their own words, and challenge anything?
• Relevant work. Projects with similar users or integrations, ideally live sites you can click through.
• Approach. Discovery, design, build, testing, launch, and what happens after launch.
• Team. Who actually does the work, and who your day-to-day contact is.
• Cost and assumptions. Itemized, with assumptions stated. The assumptions list is where hidden scope lives.

Then talk to the two or three you shortlist. A call shows you quickly whether they ask good questions.

Mistakes that cost you good proposals

• A feature list with no goals. Agencies can only price what you listed, and you lose their advice.
• An unrealistic timeline. Three weeks from proposal to launch filters out careful teams.
• Spec work. Asking for free designs in a proposal favors whoever has the most idle time, which is rarely the agency that fits best.
• Too many recipients. A short list of agencies you have already vetted gets more serious responses than a mass mailing.
• Hiding the decision-maker. If the owner will make the final call, the owner should be on the shortlist calls.
• Silence afterward. Tell everyone the outcome. You may want to work with the runner-up later.

Before the RFP goes out, run through our website redesign checklist, so content, analytics and redirects are on the list from the start. If timing is a worry, our post on how long a website takes to build helps set a realistic schedule.

Working with Pinn.Media on an RFP

We respond to RFPs, and we are just as happy to help you write one. If you are early, we can run a short discovery with your team and leave you with goals, user stories and a scope you can send to any agency, including us. Book a discovery call and bring whatever draft you have.