Most Website RFPs Are Designed to Fail
The typical website RFP produces a stack of proposals that look remarkably similar, make promises that are impossible to verify, and quote prices that range so wildly you can’t meaningfully compare them. This isn’t because agencies are bad at responding. It’s because the document they received gave them almost nothing to work with. If you want useful, comparable, honest responses from qualified vendors, you need to write an RFP that gives them enough substance to respond with substance.
Across our projects at NexusBond, we’ve reviewed hundreds of RFPs that clients brought to us after receiving confusing or disappointing proposals. The pattern is remarkably consistent: vague requirements produce vague proposals. A vendor can’t give you a realistic price for “a modern, responsive website that reflects our brand” any more than an architect can quote you for “a nice house.” The specificity of what you put in determines the quality of what you get back.
This article walks through exactly what to include, what to leave out, and how to structure your RFP so that it attracts the right vendors and gives them enough information to respond honestly.
Why Standard RFP Templates Produce Terrible Results
If you’ve downloaded an RFP template from the internet or borrowed one from a colleague, you’ve likely ended up with a document that asks vendors to describe their company history, list their certifications, and provide three references. These sections eat up pages but tell you almost nothing useful. The vendor with the best copywriter wins, not the vendor best suited to your project.
The core problem with template-based RFPs is that they focus on the vendor instead of the project. They ask “tell us about yourself” when they should be saying “here’s exactly what we need, and here’s the context you need to propose something intelligent.” Vendors responding to a generic RFP have two choices: ask a bunch of clarifying questions (which many won’t bother doing if they sense the client doesn’t know what they want) or make assumptions and pad the quote to cover the unknowns.
That padding is where budgets quietly inflate. When a vendor encounters ambiguity, they either price it low and plan to handle it through change orders later, or price it high to protect themselves. Neither outcome is good for you. The first leads to scope creep and budget overruns; the second means you’re paying a risk premium for your own lack of preparation.
Start with the Business Problem, Not the Feature List
Before you write a single line of your RFP, get clear on why this project exists. “Our website looks outdated” is not a business problem. “Our sales team reports that 40% of qualified leads say the website made them question our credibility” is a business problem. “We’re launching three new product lines in Q3 and our current CMS can’t handle the content structure” is a business problem.
The opening section of your RFP should explain the business context in plain language. What is happening in your organisation that makes this project necessary right now? What does success look like in terms the business cares about? This context is incredibly valuable to a good vendor because it lets them propose solutions that address your actual goals rather than just building what you described.
Here’s what to cover in your business context section:
- What your organisation does and who it serves
- Why this project is happening now (the trigger)
- What measurable outcomes would make this project a success
- Any constraints driving the timeline (product launch, rebrand, compliance deadline)
- Who the primary decision-maker is and what they care about most
A vendor reading this section should immediately understand whether they’re a good fit for your project. That self-selection is exactly what you want. A well-written RFP repels the wrong vendors as effectively as it attracts the right ones.
Define Your Audience Before Your Pages
One of the most common mistakes we see is an RFP that jumps straight to a sitemap or page list without establishing who the website is for. Your audience definition shapes every downstream decision: information architecture, content strategy, user journeys, conversion design, even the technology platform.
You don’t need full personas with stock photos and fictional names. What you need is a clear, honest description of the two to four primary audiences your website must serve, what each audience is trying to accomplish when they arrive, and what you want them to do. For a B2B company, this might look like: “Technical evaluators researching our product capabilities, who need to find detailed specifications and integration documentation. They should be able to request a sandbox environment within two clicks of arriving.”
That single sentence gives a vendor more to work with than three pages of generic requirements. It tells them about navigation priorities, content needs, calls to action, and user flow. When you multiply this across your key audiences, a clear picture of the website’s job starts to emerge.
Describe Current State Honestly
Vendors need to know what they’re working with. Describe your current website platform, hosting environment, and any integrations that exist today. If you’re running WordPress 4.x on shared hosting with a custom plugin that connects to Salesforce, say that. If your current site has 2,000 pages and you suspect only 300 are actively visited, say that too.
Be honest about what’s broken. If your content is a mess, your analytics tracking is unreliable, or your brand guidelines haven’t been updated since 2016, include that information. This isn’t embarrassing; it’s essential context. A vendor who doesn’t know about these issues will either discover them mid-project (causing delays and extra costs) or build something that inherits the same problems.
Include the following if you have it:
- Current CMS and version
- Hosting provider and any contractual constraints
- Active integrations (CRM, marketing automation, ERP, analytics)
- Approximate number of pages and content types
- Current monthly traffic volume (a rough figure is fine)
- Known technical debt or issues
- Any recent audit results (SEO, accessibility, performance)
If you don’t have some of this information, that’s fine. Stating “we don’t currently have reliable analytics data” is far more helpful than saying nothing, because it signals to the vendor that analytics setup should be part of the scope.
Specify Requirements at the Right Level of Detail
This is where most RFPs go wrong in one of two directions. They’re either so vague that vendors can’t price anything (“the website should be easy to use and look professional”) or so prescriptive that they’ve essentially designed the solution themselves (“the homepage hero should be 1440px wide with a 16:9 video background and a two-line headline in Helvetica Neue 48pt”).
The sweet spot is describing what the website needs to do, not exactly how it should do it. Focus on functional requirements and user outcomes. “Visitors should be able to filter our product catalogue by industry, use case, and integration type, and save filtered views for later” is a great requirement. It’s specific enough to price but flexible enough for the vendor to propose the best approach.
Functional Requirements
Group your requirements by area: content management, user interactions, integrations, search, personalisation, e-commerce (if applicable), and reporting. For each requirement, describe the capability you need and, where relevant, the scale. “The blog needs to support 50+ articles with category and tag filtering” is fundamentally different from “the blog needs to support 5,000+ articles with full-text search and related content recommendations.”
Non-Functional Requirements
These are the requirements that vendors frequently overlook because clients don’t mention them. Performance expectations, accessibility standards, security requirements, and uptime needs all fall into this category. If you operate in a regulated industry, state the compliance requirements explicitly. If your target audience includes government organisations, WCAG 2.1 AA compliance isn’t optional; it’s a hard requirement that affects how much development effort is needed.
Specify your expectations around page load time, supported browsers and devices, language and localisation needs, and data residency requirements if you operate across jurisdictions.
Be Transparent About Budget
This is the section where most organisations get uncomfortable, and it’s precisely where transparency pays the biggest dividends. Including a budget range in your RFP is not a negotiating weakness; it’s a quality filter.
When you don’t include a budget, every vendor who reads your RFP has to guess. Some will guess low and propose a stripped-down version of what you need. Others will guess high and propose a Rolls-Royce when you needed a well-equipped Volvo. The proposals become impossible to compare because they’re not even bidding on the same project.
If your approved budget is £80,000 to £120,000, say so. A good vendor will tell you what they can deliver within that range and flag anything they’d recommend deferring to a phase two. A vendor who can’t deliver what you need within your budget should tell you that honestly, and if they don’t, that tells you something important about how they’ll handle budget conversations during the project.
If you genuinely don’t have a fixed budget and need vendors to help you understand what the project should cost, state that explicitly. But understand that this shifts the conversation into discovery territory. You’re asking vendors to do scoping work in their proposal, which is why many experienced teams prefer a structured discovery phase before committing to a full build. We explore this approach in detail in our blueprint-first guide, which explains why separating scoping from execution leads to more predictable outcomes.
Define Your Evaluation Criteria and Process
Tell vendors exactly how you’ll evaluate their proposals. This isn’t just polite; it’s strategic. When vendors know you’re weighting technical approach at 30%, relevant experience at 25%, team composition at 20%, timeline at 15%, and price at 10%, they’ll structure their proposal to give you what you need in each area. Without this guidance, you’ll get proposals optimised for whatever the vendor thinks matters most, which is usually their own differentiator.
Be specific about your selection process and timeline. How many vendors will be shortlisted? Will there be a presentation or Q&A round? Who will be in the evaluation panel? When do you need the project to start? Vendors with busy schedules (often the good ones) need this information to decide whether they can commit to your timeline.
Also state whether you’re open to alternative approaches. If a vendor believes your requirements point to a different solution than what you’ve described, do you want to hear about it? Most organisations should answer yes, because a good vendor’s outside perspective is part of what you’re buying.
Structure the Response Format
If you want to compare proposals efficiently, give vendors a consistent response structure to follow. This doesn’t mean a rigid template that constrains their creativity. It means specifying the sections you need and the questions you want answered.
A practical response structure looks like this:
- Understanding of our project: demonstrate that you’ve understood our goals and challenges
- Proposed approach: how would you tackle this project, and why?
- Technology recommendation: what platform and tools, with rationale
- Team and roles: who will work on this project and what’s their relevant experience?
- Timeline and milestones: realistic project phases with dates
- Pricing breakdown: itemised by phase or workstream, with assumptions stated
- Risk and assumptions: what could affect scope, timeline, or cost?
- Relevant case studies: two to three projects of similar scale and complexity
The “risk and assumptions” section is particularly revealing. A vendor who identifies real risks is demonstrating experience. A vendor who says there are no risks is either inexperienced or telling you what they think you want to hear. Neither is a good sign.
What to Leave Out of Your RFP
Just as important as what you include is what you don’t. Removing noise from your RFP makes it faster for vendors to respond and easier for you to evaluate. Cut the following without hesitation:
Company boilerplate and marketing language. Your “About Us” section should be two paragraphs maximum. The vendor doesn’t need your annual report; they need to understand your market, your customers, and your competitive position as it relates to the website.
Detailed technical specifications for the implementation. Unless you have a genuine technical constraint (for example, the site must run on Azure because of existing infrastructure contracts), avoid dictating the technology stack. You’ll get better proposals if you describe what you need the technology to do and let vendors recommend the best tool for the job.
Excessive legal terms upfront. A note about your standard contract terms or procurement process is fine. A 15-page appendix of legal conditions attached to the RFP signals to vendors that working with you will be bureaucratic and painful. Save the detailed contract negotiation for after you’ve selected a preferred vendor.
Design direction or wireframes you created internally. Unless they’ve been validated through user research, internally created wireframes tend to bake in assumptions that constrain better solutions. Describe the problems the design needs to solve and let the vendor’s UX team do what you’re paying them for.
Managing the RFP Process Itself
How you run the process matters as much as what you write. Send your RFP to a focused shortlist of five to seven vendors, not a blast to twenty. You want thoughtful responses, and vendors who know they’re competing against a dozen others are less likely to invest serious effort in their proposal.
Schedule a single Q&A window during the response period. This can be a group call or a written Q&A document where all questions and answers are shared with all vendors. This keeps the process fair and often surfaces questions you hadn’t anticipated, which improves the quality of every response you receive.
Give vendors at least three weeks to respond for a project of meaningful size. Two weeks is too short for a serious proposal. If a vendor needs to involve a senior strategist, a technical architect, and a project manager in their response (and they should), they need time to coordinate and produce something worth reading.
Finally, commit to providing feedback to unsuccessful vendors. You don’t have to write an essay, but a brief explanation of why they weren’t selected helps them improve and maintains your reputation as a good client to work with. The web industry is smaller than you think, and agencies talk to each other.
The Uncomfortable Truth About RFPs and Complex Projects
There’s a scenario where even a perfectly written RFP won’t solve your problem. If your project involves significant unknowns, if you’re unsure about your content strategy, your integration requirements are complex, or your stakeholders aren’t aligned on goals, then you’re asking vendors to price a project that isn’t fully defined yet. No amount of RFP polish can fix that.
In our experience at NexusBond, the projects that go most smoothly are ones where the client invested in proper scoping before going to market. This means validating requirements with real stakeholders, mapping integrations with the technical team, auditing existing content, and agreeing on success metrics. When this work is done upfront, the RFP practically writes itself, and the responses you receive are dramatically more accurate and useful.
For projects under £30,000 with well-understood requirements, a solid RFP might be all you need. For anything larger or more complex, consider whether a structured discovery phase would give you the clarity to write an RFP that gets genuinely useful responses, rather than a collection of educated guesses.
Putting It Into Practice
Writing a good RFP is work. It forces you to make decisions, align stakeholders, and confront uncertainties before you go to market rather than discovering them mid-project. That upfront investment typically saves mid-market teams six to twelve weeks of rework and eliminates the most common source of budget overruns: scope that was never properly defined.
Start by documenting your business objectives and audience needs. Be honest about your current state and budget. Specify your requirements at the functional level without dictating the solution. Tell vendors how you’ll evaluate them and give them a consistent format to respond in. Send it to a small, curated list and give them enough time to respond thoughtfully. The proposals you receive will be more specific, more comparable, and more honest. And that’s exactly the foundation you need to choose the right partner and start the project with confidence.
Ready to get started?
