How to Write a Website RFP That Gets You Quotes You Can Actually Compare

Imagine three agencies quoting for the same website. One price is half the second, while the third is much higher. You open the proposals and discover that one includes copywriting, another assumes all content is supplied, and the third has priced an integration you never discussed. The headline prices alone cannot explain the difference.

A website RFP, or request for proposal, should reduce those differences before suppliers spend time estimating. It does not need to dictate every technical choice. It needs to describe the same outcome, identify known constraints and require suppliers to expose their assumptions in a consistent format.

Describe the business task before the page count

Begin with what visitors need to accomplish. A business website might need to help buyers understand three service lines, submit a qualified enquiry and download current specifications. An online shop has a different operational burden. The supplier should see the important journeys before interpreting a phrase such as modern ten-page website.

Name the people who will operate the finished site. A receptionist changing opening hours, a marketing manager publishing articles and a product team importing specifications need different editing capabilities. Include the tasks they perform and the approval steps involved. This prevents a polished demonstration from hiding an impractical day-to-day workflow.

State which outcomes you will measure without demanding promises a developer cannot control. Correct enquiry routing and a working product filter are testable deliverables. A guaranteed quantity of sales is not a sensible substitute for defining them. Ask suppliers to explain how the implementation supports the outcome and how its operation will be checked.

Count templates and content separately

A page count can conceal substantial differences. Fifty product pages built from one consistent template are different from fifty individually designed campaign pages. List the main page types, estimate how many content items use each and mark anything that requires a unique layout or special behaviour.

For each type, include a representative example with realistic content. A service page containing two paragraphs differs from one needing a comparison table, downloadable drawings and an application form. Suppliers do not need your final wording to recognise those requirements, but they do need enough detail to estimate them responsibly.

Identify languages and explain who supplies translations and approves them. Do not assume a second language is merely another copy of the first layout. Ask the supplier to state what is included in content entry, layout checks and language switching, with any exclusions made visible in the response.

Assign content work to named roles

Write a small responsibility list covering copy, photography, illustrations, translations, product data and policy wording. For each, state whether it already exists, requires revision or must be created. Attach samples where available. The same website can have very different costs depending on whether a supplier is arranging content or only placing it.

Be honest about the condition of existing material. A folder of mixed image sizes and a spreadsheet with inconsistent product fields is not a ready-to-import catalogue. Ask suppliers to price cleanup separately if its extent is uncertain, and request the assumptions behind any migration allowance.

Set a content approval owner on your side. A supplier cannot make a reliable schedule if several departments can overturn approved wording without a decision process. Include expected review times and explain what happens when content arrives late, so quotations describe a workable collaboration rather than a calendar based on wishful thinking.

Describe integrations as workflows

Replace vague labels such as CRM integration with a short example. Explain which form fields should arrive in which system, who receives a notification and what happens when the receiving service is unavailable. Include the current provider and whether documentation or a test account is available, without circulating secret credentials in the RFP.

State which system is authoritative when records disagree. If product availability comes from an inventory application, the website team needs to know whether updates are immediate, scheduled or manual. Ask the supplier to identify dependencies and unanswered questions rather than quietly choosing an interpretation that makes its quote smaller.

For a payment or booking flow, request a clear list of included states: successful, rejected, cancelled, pending and interrupted where relevant. The RFP need not prescribe the code. It should make clear that customers and staff need understandable outcomes when something fails as well as when it succeeds.

Illustrative concept for comparing proposals against the same set of requirements.

Make acceptance observable

Write a short acceptance example for each important journey. A hypothetical service enquiry might require a usable mobile form, clear validation, delivery to the correct team and a confirmation that matches the actual process. Give the supplier room to propose the implementation while keeping the required behaviour unambiguous.

Include accessibility and performance as defined review work rather than unexplained adjectives. Ask what pages, journeys, devices and conditions will be checked, which target is proposed and how findings are resolved. A statement that a site will be fast and accessible does not tell you what evidence arrives at handover.

Specify the evidence you expect: a demonstration, test record, configuration summary or content reconciliation where appropriate. Avoid making every minor preference a launch blocker, but do name the failures that prevent the business from using the site. Agree who accepts each deliverable and how disputed findings are assessed.

Price ownership and ongoing operation

Ask who will control the domain, hosting, source repository and paid third-party accounts. Distinguish access from contractual ownership and request any transfer conditions in writing. A supplier's ability to log into an account does not tell you whether the business can continue operating independently after the engagement ends.

If a GitHub repository is involved, its official transfer documentation describes permissions and consequences that depend on repository circumstances. This is a useful reminder to ask for a concrete handover method rather than the loose promise that you will get the code. The contract and the actual access arrangement both need review. GitHub repository transfers.

Separate one-off build charges from recurring services, licence renewals and optional support. Ask suppliers to show what happens when support is not renewed: which services continue, what access remains and which tasks become your responsibility. Compare costs over the same period using stated assumptions, rather than treating every monthly charge as interchangeable.

Give suppliers a common response sheet

Request a response against each requirement using included, excluded, optional or clarification needed. Add columns for assumptions, deliverables and price where useful. This makes omissions easier to see without requiring suppliers to copy a particular technical solution. Invite a recommended alternative separately so useful ideas do not obscure the base quotation.

Require a milestone schedule with dependencies, not just a completion date. Design approval, content delivery, integration access and testing all affect the calendar. Ask suppliers to indicate what they need from your team and what could change the estimate, including how additional work is authorised.

Share material clarifications with every shortlisted bidder. If one supplier discovers that the catalogue has several price lists rather than one, the other suppliers need the same information before final comparison. Otherwise the most careful proposal can look expensive simply because it includes work the others have not understood.

Compare the explanation as well as the price

Build a comparison that separates scope, assumptions, evidence, operating cost and commercial terms. Note differences before negotiating. A lower price may be entirely reasonable for a narrower solution, but the decision should recognise what your team must provide or manage instead.

Use a short clarification meeting to test understanding. Ask each supplier to explain one important journey and one likely project risk in plain language. You are looking for an answer connected to your business, with explicit unknowns and a workable next step, not an impressive list of tools.

Keep a decision note after selection. Record the scope you chose, alternatives declined and assumptions still requiring confirmation. This is especially useful when the person who requested the website differs from the person who will manage delivery. A clear purchasing decision gives the project team a practical starting point rather than another round of interpretation.

For a website development proposal, send the same brief, examples and response sheet to each supplier. Keep the first version focused on the decisions that materially affect effort. A good RFP earns its length by removing ambiguity; it does not become better simply because it grows into a large document.