Many organizations treat a website redesign RFP as a pricing exercise: describe the project loosely, send it to a handful of agencies, and see who comes back with the lowest number. That approach usually backfires. A vague RFP produces proposals that cannot be fairly compared, because each agency ends up answering a slightly different question. A strong RFP gives every bidder the same background, the same goals, and the same evaluation criteria, so the responses reflect capability rather than guesswork.
PMI’s global research on project success found that projects with clearly defined goals, a measurement system, and tracked metrics were nearly twice as likely to succeed. An RFP is where those goals get written down for the first time. What goes into it shapes how the entire redesign plays out, long before a single wireframe exists.
What an RFP Is Actually For
A website redesign RFP is not a quote request. It is a structured brief that explains why the redesign is happening, what the organization needs, and how vendors will be evaluated. Done well, it lets an unfamiliar agency understand a business quickly enough to propose a realistic, comparable solution. Done poorly, it produces a stack of proposals with wildly different assumptions and no clear way to judge which one actually fits.
Company and Project Background
Start with context an outside agency would not otherwise have: what the organization does, who it serves, and how the current site came to exist. Include the current website URL, when it was last redesigned, and any branding or messaging work already in progress. This section does not need to be long. A few paragraphs are usually enough to orient a vendor who has never worked with the organization before.
Project Goals and Success Metrics
This is the most important section of the document. Vague goals like “we need a modern look” produce vague, uninspired proposals. Specific goals tied to a business outcome produce specific plans. A goal framed as “reduce our contact form abandonment rate” or “increase demo requests by a defined percentage within a set window” gives every bidder something concrete to design against and gives the organization a way to judge whether a proposal actually addresses the problem.
Scope of Work
List the pages, features, and integrations the project needs to cover, and separate anything that belongs in a later phase from what has to be part of the initial launch. Vendors need to know whether the scope includes e-commerce functionality, a client portal, a blog migration, or third-party integrations such as a CRM or booking system. Ambiguity here is one of the most common sources of scope creep once a project is underway.
It also helps to note what should stay the same. If certain pages, campaigns, or tools are working well and should not be redesigned from scratch, say so directly. Vendors often assume a full rebuild unless told otherwise, and that assumption alone can inflate a proposal well beyond what the organization actually needs.
Technical and Functional Requirements
Cover the practical constraints that affect how a vendor would actually build the site: current CMS platform, hosting environment, required integrations, accessibility standards, and any compliance requirements tied to the organization’s industry. If content ownership matters, such as who writes and who migrates existing pages, state that explicitly. These details rarely change the vision for the site, but they change how a vendor scopes and prices the work.
Timeline and Budget Expectations
A realistic budget range, even an approximate one, produces far more useful proposals than no budget information at all. Without it, vendors are left guessing at the level of investment the organization is prepared to make, and the resulting bids can range so widely that they become difficult to compare on anything other than price. The same applies to timeline. A target launch window, even a flexible one, helps a vendor propose a realistic plan rather than an idealized one.
Evaluation Criteria and Submission Instructions
Explain how proposals will be reviewed and what factors matter most, whether that is relevant experience, proposed approach, team structure, or price. Include a single point of contact for questions, a clear submission deadline, and the preferred format for responses. This section protects the organization’s time as much as the vendor’s. Without clear instructions, review teams often end up comparing proposals that are formatted so differently that a fair side-by-side comparison becomes difficult.
It also helps to decide in advance who will be reviewing proposals and how. If the review involves multiple departments, such as marketing, IT, and leadership, note that in the RFP so vendors understand the decision is not resting on a single stakeholder. Agencies often tailor parts of their response, such as technical depth or strategic framing, depending on who is expected to read it.
What Happens After the RFP: Moving Into Discovery
Once a vendor is selected, the relationship typically moves into a discovery phase, where the agency translates the RFP’s goals into a detailed sitemap, wireframes, and a technical specification. Design In DC’s website discovery process is where that translation happens: stakeholder interviews, competitive research, and user journey mapping turn a written brief into a concrete plan the design and development team can execute against. The RFP sets the direction. Discovery is where that direction becomes a buildable plan.
Common RFP Mistakes to Avoid
- Describing goals in vague, aspirational language instead of measurable outcomes
- Omitting a budget range entirely, which produces bids that are impossible to compare fairly
- Leaving out evaluation criteria, so vendors do not know what to emphasize in their response
- Being overly prescriptive about implementation details rather than the underlying goals, which limits stronger proposals a vendor might otherwise suggest
- Skipping a single point of contact, which leads to inconsistent answers across different bidders
Frequently Asked Questions
Should a website redesign RFP include a budget range?
Yes. Even an approximate range helps vendors propose realistic, comparable solutions instead of guessing at what the organization is prepared to spend.
How long should an RFP be?
Long enough to cover goals, scope, technical requirements, timeline, and evaluation criteria clearly, but concise enough that vendors can read it in one sitting. Most effective RFPs run a handful of pages rather than an exhaustive specification.
What is the difference between an RFP and a discovery phase?
An RFP happens before a vendor is selected and is used to compare proposals from multiple agencies. Discovery happens after a vendor is chosen and turns the agreed direction into a detailed sitemap, wireframes, and technical plan.
Bringing It Together
A website redesign RFP works best when it treats vendor selection as a genuine comparison exercise rather than a simple pricing request. Clear goals, an honest budget range, defined scope, and explicit evaluation criteria give every agency the same starting point and give the organization a fair way to judge the results. That clarity pays off well beyond the initial vendor selection process. It becomes the foundation the entire redesign project gets built on from day one.
If you are preparing a redesign and want a second set of eyes on your requirements before you send it out, you’re welcome to submit your RFP to our team directly.
