How to Write a Website RFP That Gets Great Proposals

Why Your RFP Matters

I've responded to hundreds of website RFPs over my career. The quality of the RFP directly predicts the quality of the project. Vague RFPs produce vague proposals, mismatched expectations, and troubled projects.

A good RFP does three things: it attracts qualified vendors, enables accurate pricing, and creates a shared understanding that carries through the entire project. A bad RFP wastes everyone's time and sets up a relationship destined for conflict.

The RFP asked for "a modern, user-friendly website." Every single proposal interpreted that differently. We ended up picking based on price because we couldn't compare anything else.

Marketing Manager, Nonprofit Organization

This guide will help you write an RFP that gets you proposals you can actually evaluate—and a project you can actually succeed with.

The Essential Sections

A complete website RFP should include these sections. I'll detail each one below.

1. Organization Overview

   Who you are, what you do, and why you need a new website.

2. Project Goals

   What business outcomes the website should achieve.

3. Target Audience

   Who will use the site and what they need to accomplish.

4. Scope and Requirements

   Features, content, integrations, and technical needs.

5. Budget and Timeline

   Financial parameters and key dates.

6. Evaluation Criteria

   How you'll assess and compare proposals.

7. Submission Requirements

   What you need from vendors and when.

Organization Overview

Give vendors context about your organization. They need to understand your world to propose effective solutions.

Include:

• What your organization does and who you serve
• Your size (employees, customers/members, locations)
• Your current website situation (URL, platform, age, problems)
• Why you're doing this project now
• Any relevant history (past redesigns, failed projects)

Example:

Project Goals

This is the most important section of your RFP. Goals drive every decision that follows.

Good Goals Are:

• Specific: "Increase online appointment bookings by 40%" not "improve user experience"
• Measurable: You can tell whether you achieved them
• Business-oriented: Tied to organizational outcomes
• Prioritized: Not everything can be #1 priority

Example Goals:

1. Increase online appointment requests by 40% within 6 months of launch
2. Achieve WCAG 2.2 Level AA accessibility compliance
3. Reduce average page load time to under 2 seconds
4. Enable marketing team to update content without developer assistance
5. Integrate with Salesforce CRM for lead tracking

Target Audience

Who will use this website? What do they need to accomplish? This shapes everything from information architecture to design tone.

For Each Audience Segment, Describe:

• Who they are (demographics, role, relationship to your organization)
• What they're trying to accomplish on your site
• How they currently accomplish these tasks
• What devices and contexts they use
• Any accessibility needs

Example:

Scope and Requirements

This section details what you need. Be thorough but distinguish between requirements (must have) and nice-to-haves.

Content Scope

• Approximate number of pages
• Content types (blog, events, staff directory, etc.)
• Who will provide content? Who will write/migrate it?
• Existing content to migrate vs. new content needed
• Multilingual requirements

Functional Requirements

• Forms and their purposes
• Search functionality needs
• User accounts or member areas
• E-commerce or payment processing
• Scheduling or booking systems
• Interactive tools or calculators

Integration Requirements

• CRM systems
• Email marketing platforms
• Analytics tools
• Payment processors
• Third-party databases or APIs

Technical Requirements

• Platform preferences or requirements (if any)
• Hosting requirements or constraints
• Security requirements
• Performance requirements
• Accessibility standards (WCAG level)

Budget and Timeline

Yes, include your budget. I know procurement often advises against this, but for creative services, it's counterproductive to hide it.

Why Include Budget?

• Vendors can self-select (if your budget is $10K, enterprise agencies won't waste your time)
• Proposals will be appropriately scoped (a $50K solution looks different than a $150K solution)
• You can compare apples to apples
• It demonstrates you've done your homework

If you truly don't know, provide a range: "Our budget is $40,000-60,000, not including ongoing hosting and maintenance."

Timeline Information to Include:

• RFP release date
• Deadline for questions
• Proposal due date
• Expected decision date
• Desired project start date
• Required launch date (and why, if it's firm)
• Any blackout periods or constraints

Evaluation Criteria

Tell vendors how you'll evaluate proposals. This helps them emphasize what matters to you and signals that you have a thoughtful selection process.

Example Criteria:

Submission Requirements

Be specific about what you want in proposals. This makes evaluation easier and ensures you get the information you need.

Request:

• Company overview and history
• Relevant project examples (with results, not just screenshots)
• Proposed team members and their roles
• Understanding of your project and proposed approach
• Detailed cost breakdown
• Proposed timeline with milestones
• References (3 recent clients with similar projects)
• Answers to specific questions (see below)

Questions to Ask:

1. How do you approach discovery and requirements gathering?
2. What is your design and development process?
3. How do you handle scope changes and additional requests?
4. What does your testing and QA process look like?
5. What training and documentation do you provide?
6. What ongoing support options do you offer?
7. What makes your team the right fit for this project?

Common Mistakes to Avoid

These RFP mistakes lead to bad outcomes.

• Being too vague: "We need a modern website" tells vendors nothing useful.
• Being too prescriptive: Specifying technologies and approaches limits creativity and may exclude better solutions.
• Hiding the budget: Results in wildly varying proposals that can't be compared.
• Unrealistic timelines: Rush jobs produce rushed work. Be honest about constraints.
• Ignoring content: The #1 cause of project delays. Who's writing and providing content?
• Asking for free work: Requesting spec designs or detailed technical plans without compensation is disrespectful and attracts desperate vendors.
• Blasting to everyone: Send to 3-5 qualified vendors, not 50. Respect vendors' time.
• No Q&A process: Vendors will have questions. Build in a process to answer them fairly.