When you put out a web design RFP (request for proposal), you are doing two things at once: clarifying what you actually need, and giving agencies a fair way to price and plan the work. A strong RFP saves you from “apples to oranges” bids, vague timelines, and the classic surprise of finding out that something you assumed was included was never in scope.
If you want better proposals, you need a better prompt. Think of your RFP as a set of guardrails. The more clearly you define goals, scope, and decision criteria, the more confidently a vendor can commit to cost, timing, and outcomes.
Start with the outcome, not the pages
Before you ask about page count or design style, lock in why the site exists. A website is not a poster. It is a system that should produce measurable results: sales, leads, donations, bookings, applications, signups, support deflection, course enrollments, or member renewals.
If you can name the result, you can design for it. If you cannot, your RFP will drift into preferences and opinions, and vendors will respond with pretty mockups and soft promises.
What to include in a practical web design RFP
Your RFP can be short and still be complete, as long as it covers decisions that affect price and risk. You are aiming for “clear enough to quote” without writing a 40-page novel.
After the paragraph above, use a simple structure like this:
- Project summary
- Goals and success metrics
- Audience and user actions
- Scope, deliverables, and what is out of scope
- Technical requirements and integrations
- Content, SEO, accessibility, and compliance needs
- Timeline, budget range, and constraints
- Support after launch
- Proposal format and evaluation process
That layout keeps you in control. It also makes it easier for agencies to respond consistently, which helps you compare them.
RFP questions that force clarity (and better proposals)
The best RFP questions do not ask vendors to guess. They give vendors enough context to propose a plan that fits your reality, including your team’s capacity to review work and provide content.
Here are questions you can paste directly into your template, grouped by theme:
- Business goals: What are your primary objectives for the new site, and what KPIs will define success?
- Primary conversions: What actions should users take most often (buy, donate, request a quote, join, enroll, subscribe)?
- Target audiences: Who are your key user groups, and what do they need most when they land on the site?
- Brand inputs: What brand guidelines, visual assets, and examples of sites you like or dislike should guide design?
- Content ownership: Who writes and supplies copy, images, video, product data, and downloads, and who uploads them?
- SEO expectations: What organic search goals matter most, and what baseline data can you share (rankings, traffic, conversions)?
- Accessibility: Which standard are you targeting (commonly WCAG 2.1 AA), and how should it be tested and documented?
- Technical constraints: What CMS or platform requirements exist, and what integrations are required (CRM, email, payments, shipping)?
- Security and privacy: What data do you collect, what policies apply, and what constraints exist around cookies and tracking?
- Timeline and milestones: What deadlines are fixed, what is flexible, and who approves each phase?
- Budget range: What budget range are you prepared to fund for this scope, and what tradeoffs are acceptable if needed?
- Post-launch support: What level of ongoing support do you want (updates, backups, monitoring, content help, feature iteration)?
- Communication: Who is your day-to-day contact, what meeting cadence works, and what tools do you want to use?
If you answer these well, you will notice something: the “right” vendors start asking sharper follow-up questions instead of rushing to pitch a design trend.
Scope that vendors can price (without padding)
Scope is where RFPs most often fail. Not because teams are careless, but because scope feels obvious from the inside. Agencies do not live inside your business, your approvals, or your existing tech stack. You have to spell it out.
A clean scope section has four ingredients: deliverables, phases, inclusions, exclusions. You can keep it readable by writing in plain language and using acceptance criteria where it matters.
Define deliverables by phase
You will get more accurate timelines when you require phase-based deliverables. Many teams like a flow that starts with discovery, then an initial design “north star” (often a homepage mockup), then the rest of the pages and templates, then build, then testing and launch.
That pattern is common among agencies that care about conversion and clarity, including teams like Wapiti Digital that emphasize upfront discovery and an early approved design direction before deeper build work. It keeps your feedback targeted and prevents redesigning everything midstream.
Make inclusions and exclusions explicit
“In scope” is what you will pay for. “Out of scope” is what will trigger a change order, a separate phase, or a separate vendor. When you write this section well, you avoid resentment later.
Common scope gaps that cause conflict:
- Content writing vs content placement
- SEO setup vs ongoing SEO work
- Accessibility compliance vs “best effort”
- Integrations vs “links to external tools”
- Photography and video production vs using existing assets
- Training vs handing over logins
Add change management before you need it
Your RFP should state how many revision rounds are included per phase and how changes are approved. You are not being rigid. You are protecting your timeline and the vendor’s ability to staff the project.
A simple policy works: two rounds of revisions per major phase, then a written change request for anything outside the approved direction.
Technical requirements: keep it concrete
You do not need to dictate a framework unless you have a real constraint. You do need to name the systems that must connect and the environments the site must run in.
Write requirements that a technical lead can validate:
- Hosting and deployment expectations (vendor-managed or client-managed)
- CMS needs (who updates what, how often, and with what skill level)
- Integrations (CRM, email marketing, payments, shipping, membership, donations, LMS)
- Browser and device support
- Analytics and tracking (GA4, Tag Manager, ad pixels, consent tools)
- Performance targets (page speed goals, image formats, caching expectations)
If you are running eCommerce, subscriptions, memberships, donations, or courses, say so early. Those features change architecture, content models, and QA scope. They also change how you should judge vendor experience.
SEO, accessibility, and performance: write your minimum bar
If you want the site to rank and convert, these cannot be optional. They must be requirements with a definition of “done.”
A practical way to set the bar:
- On-page SEO: indexable templates, metadata fields, clean URLs, redirects, sitemap, canonical strategy where needed
- Performance: compressed media, modern formats, sensible script loading, caching plan
- Accessibility: target standard (often WCAG 2.1 AA), testing method, fixes included before launch
When you require these in the RFP, you stop rewarding proposals that look affordable only because they leave out the hard work.
Timeline, roles, and approvals: your hidden project engine
Agencies can move quickly when your internal team can review quickly. Your RFP should name who approves what, and how long feedback will take. If your legal review takes two weeks, put that in writing. If your team can only meet on Fridays, say so.
Also state what you will provide and by when. Content delays are the number one reason “the agency missed the deadline” even when the agency did not.
Proposal format: ask for comparable answers
You are allowed to make it easy to evaluate. Request a consistent response structure:
- Approach and process
- Project team and roles
- Deliverables and assumptions
- Timeline with milestones
- Pricing with payment schedule
- Examples of similar work
- Support options after launch
If you want fewer surprise fees, ask vendors to list assumptions and exclusions. A vendor who is confident will be specific.
Evaluation checklist you can actually score
You will choose better when you score proposals against the same criteria. Below is a ready-to-use rubric. Keep it simple: 1 to 5 per category, then talk through the differences.
| Criteria | What you are looking for | Score (1-5) |
|---|---|---|
| Relevant experience | Proof they have built sites like yours, including required features and complexity | |
| Technical competence | Clear plan for CMS, integrations, security, and deployment | |
| Design and brand fit | Design quality plus rationale tied to your audience and conversions | |
| Timeline and planning | Milestones that feel realistic, with review cycles and dependencies acknowledged | |
| Budget and value | Transparent pricing tied to deliverables, not vague buckets | |
| Team and capacity | Named roles, availability, and who does what | |
| References | Recent references that match your type of project | |
| Communication | Clear process, predictable touchpoints, and good responsiveness during Q and A | |
| Post-launch support | Options for updates, monitoring, fixes, and iteration | |
| Accessibility | Stated standard, testing approach, remediation before launch | |
| SEO and performance | Built-in technical SEO and performance practices, not an afterthought | |
| Security and data protection | SSL, backups, patching approach, privacy considerations |
You can also decide in advance what is non-negotiable. If accessibility compliance is required, treat it as pass or fail, then score the rest.
A lightweight evaluation workflow (so you do not overthink it)
Once proposals arrive, decision fatigue is real. You can avoid it with a short, structured evaluation flow that still leaves room for instinct and chemistry.
After the paragraph above, use this checklist:
- Screen for dealbreakers (budget range, timeline feasibility, required platform experience).
- Score the top candidates using the rubric table.
- Interview your top two or three vendors with the same set of questions, then request a final clarification or revised scope if needed.
This keeps you moving while still being fair to every respondent.
A copy-and-paste RFP template (fill-in sections)
Below is a fill-in template you can drop into a doc. Keep your answers brief. Clarity beats length.
1) Organization and project overview
State who you are, what the site does today, and why you are commissioning a new build or redesign. Include the URL of the existing site and any related properties.
2) Goals and success metrics
Name your top objectives and how you will measure them (conversion rate, qualified leads, revenue, donations, subscriptions, course enrollments, reduced support tickets). If you have baseline analytics, include a snapshot.
3) Target audiences and key user actions
List your main audiences and the actions you want each to take. Mention any accessibility needs your users may have.
4) Scope of work
Define:
- Deliverables by phase (discovery, wireframes, design, development, QA, launch)
- Page types and templates (home, about, product detail, landing pages, blog, resource library)
- Feature requirements (search, filtering, forms, booking, donation flows, membership gates, LMS modules)
- Out-of-scope items
5) Content and migration
Explain who writes copy, who supplies visuals, and what needs migrating from the old site. If you have a hard content deadline, state it.
6) Technical requirements and integrations
List your must-have systems (CRM, email marketing, payment processor, shipping, inventory, membership, donor management). Note hosting constraints and who will own accounts.
7) SEO, analytics, accessibility, and performance requirements
State your minimum bar for technical SEO, redirect handling, analytics setup, accessibility standard, and performance expectations.
8) Timeline, reviews, and approvals
Provide target dates, fixed deadlines, and your internal review process. State how many revision rounds you expect and who has final sign-off.
9) Budget range and payment preferences
Include a range and any procurement constraints. Ask for milestone-based pricing tied to deliverables.
10) Post-launch support
Describe the support you want after launch: training, documentation, maintenance, updates, monitoring, ongoing improvements.
11) Proposal submission requirements
Request structure, due date, contact person, and whether Q and A will be shared with all bidders.
If you write your RFP with this level of specificity, you will notice proposals shifting from sales language to real plans. That is when you start choosing a partner based on fit, rigor, and outcomes, not just on who sent the prettiest PDF.
