Most redesign RFPs fail for a simple reason: they describe what the company wants but not how the company decides. Vendors respond with different assumptions, wildly different scopes, and prices that can’t be compared.
If you are a service business, the RFP is not just a buying tool. It is your first trust test. It shows whether you understand your own priorities and whether you can lead a complex decision without drowning everyone in paperwork.
This guide shows how to structure a redesign RFP so it produces clear proposals, realistic budget signals, and a scoring model you can actually use.
Start by deciding how you will choose
A Request for Proposal is used when factors beyond price are weighted for award. In procurement terms, it’s a “best value” process, not a lowest-price competition. The New York State OGS procurement glossary describes RFPs and RFQs as different tools depending on how you intend to evaluate proposals. OGS procurement glossary
That distinction matters. If you only care about cost, don’t use an RFP. If you care about outcomes, risk, and fit, then you need a scoring model that reflects that.
A simple way to decide:
- Use an RFP if multiple stakeholders need to score vendors and you need a documented comparison.
- Use a short brief if you want speed and a smaller vendor list.
If you are not sure, start with a short brief. You can evolve it into a full RFP once you have internal alignment. The website project brief guide is a clean starting point.
The three signals vendors need to price accurately
RFPs often ask for “pricing” without giving vendors enough signals to estimate the work. That guarantees proposals that are padded or unrealistic. Good RFPs provide three pricing signals up front:
1) Scope boundaries
List the pages and features that are in scope, but also state what is explicitly out of scope. This is how you reduce scope creep. A scope statement should describe the work content and the deliverables, not just the goals. PMI’s guidance on scope management emphasizes the value of a documented scope statement before execution. PMI scope management
Keep this tight. A vendor doesn’t need a full spec. They need the boundary lines.
2) Risk factors
Tell vendors about your biggest risks: complex content migrations, multiple stakeholder approvals, or legal requirements. If you already have a rough inventory of content, share the counts. If you have multiple service lines, say that.
Your information architecture and navigation patterns posts can help frame this.
3) Budget intent
You don’t need to share an exact number. But you do need to signal your range. A vendor can’t propose a realistic solution without knowing the level of investment you can make. If you are unsure, use the web development cost guide as a baseline.
A buyer-friendly RFP structure that works
Here’s a structure that consistently produces usable proposals without turning into a bureaucratic mess.
1) Context and business goals
Explain your business model, how you sell, and what the website is supposed to do. If you sell complex services, say that. If most of your leads come from referrals, say that. This context matters more than any feature list.
2) Scope summary
Use a short scope summary: redesign vs rebuild, content migration, analytics, performance expectations, and integrations. Don’t make vendors guess.
If you already know you need a service hub page, price ranges, or revised messaging, call that out and link to your internal thinking. Services hub page structure and pricing page strategy are good reference points for what you might include.
3) Success criteria
Define how you’ll measure success. These aren’t vanity KPIs. They should map to revenue or decision quality: qualified inquiries, lower sales friction, clearer positioning, or a shorter time-to-brief. If you’re not sure, start with the analytics baseline guide.
4) Timelines and constraints
Provide a timeline window and known constraints like team availability, legal review cycles, or product launch dates. If you need a 10 to 20 week build, say so. Realistic timeline planning gives a baseline.
5) Proposal format requirements
Give vendors a format. Otherwise proposals become sales decks and you will struggle to compare them. Ask for:
- Project approach and phases
- A scoped deliverables list
- Team roles and availability
- Risk assumptions
- Cost breakdown by phase
- Timeline by phase
6) Scoring model
You can’t compare proposals without a scoring model. This is where most RFPs fall apart. Use a simple weight-based model with 4 to 6 criteria and explain the weighting.
Example scoring buckets:
- Strategy and discovery (how they run the discovery phase)
- Scope clarity (how well they define deliverables)
- Relevant proof (case studies and outcomes, not logos)
- Team fit (who will actually work on your project)
- Total cost and risk (realistic vs optimistic)
You can also add a small score for response quality. Sloppy proposals predict sloppy delivery.
The most common RFP mistakes (and how to fix them)
Mistake 1: Vague scope
If the scope is vague, vendors will fill it in with assumptions. That’s where scope creep starts. Tighten the scope summary and list explicit exclusions.
Mistake 2: No decision narrative
Most RFPs skip how the decision will be made. Vendors then overproduce content to cover themselves. Add your scoring model and the decision timeline.
Mistake 3: Overemphasis on design mockups
Early visual concepts are a poor proxy for strategic fit. If you want to evaluate thinking, ask vendors to describe how they would approach positioning, information architecture, and messaging first. You can ask for a small paid workshop later if you need tangible examples.
Mistake 4: No access to internal constraints
If your legal review takes two weeks, say it. If you have a CMS constraint, say it. Hidden constraints increase cost and reduce trust.
RFP vs proposal request: when a shorter brief wins
If you are working with a short vendor list and you care about speed, a brief can outperform a full RFP. It tends to produce clearer conversations and less box-checking.
A good brief includes:
- Business context
- Core goals
- Scope boundaries
- Timeline window
- Budget range
- Decision process
That’s it. You can still compare vendors, but you get a conversation instead of a cold submission. For many service businesses, the brief is enough.
If you want to use a brief-first approach, the proposal evaluation guide shows how to compare vendors without a formal RFP.
How to keep vendors honest without killing creativity
RFPs can force vendors into safe answers. The fix is to create one optional section where they can propose a different approach. You’re not obligating yourself to accept it, but you are giving them room to show strategic thinking.
You can ask:
- If you could simplify the scope, what would you change and why?
- What risks do you see that we may have missed?
- What would you sequence differently if you had full control?
These questions separate real partners from template responders.
The point of an RFP is clarity, not volume
A strong RFP is short. It defines the scope, the decision process, and the constraints. It doesn’t try to solve the entire redesign itself.
If you want help shaping your RFP, start with your project brief and convert it into a structured request once the priorities are clear. If you want feedback on vendor proposals, use the contact form and I’ll point out where the assumptions hide.
