How to write a website RFP that produces clear, comparable proposals

A website request for proposal can create clarity, or it can disguise uncertainty behind a long list of features. The difference is usually established before any agency begins writing its response.

When each respondent receives different background information, interprets vague requirements differently and chooses its own pricing structure, the resulting proposals are not genuinely comparable. One may include content migration, another may exclude it, and a third may assume an integration is simple without seeing the systems involved. The totals can look precise while representing different projects.

A better RFP is a decision instrument. It gives every agency the same evidence, separates facts from preferences and open questions, asks for a consistent response, and makes assumptions visible. It does not pretend that procurement documentation has already solved the user, content, technology and governance decisions that belong in an appropriately scoped engagement.

The short answer: comparability starts before proposals arrive

Clear proposals require a clear comparison basis. Before issuing the RFP, define the business outcomes, priority audiences, available current-state evidence, fixed constraints and material unknowns. Then require each agency to respond under the same headings and distinguish included professional services, client responsibilities, exclusions, assumptions and third-party costs.

The objective is not to eliminate every unknown. It is to stop unknowns being priced as though they were settled facts. When an unresolved question could materially change architecture, integration effort, data migration, security, governance, scope or cost, identify it as a Discovery question rather than demanding unsupported certainty.

• Describe outcomes before prescribing features
• Disclose the same current-state evidence to every bidder
• Separate mandates, preferences and unresolved questions
• Require a common proposal structure
• Compare assumptions, risks and dependencies alongside price
• Keep selection, contract, Discovery and implementation as distinct gates

A feature list is not a substitute for shared context.

First decide whether a formal RFP is the right tool

A formal RFP is useful when governance, probity, multiple stakeholders or a documented competitive process require it. It can establish a consistent evidence base, record the evaluation rationale and give internal teams a controlled way to resolve questions. The distinction is explored further in website brief versus paid Full Website Discovery.

It is not always the smallest credible next step. A contained website with clear requirements may be better served by a concise brief and direct proposal process. A complex opportunity with unresolved systems, content, data or governance may need an expression of interest or capability shortlist followed by paid Full Website Discovery before implementation can be responsibly defined. A formal tender conducted too early can produce extensive documents without improving the underlying decision.

Before approaching agencies, agree who owns the process, who can clarify requirements, who evaluates responses and who makes the final decision. Record any mandatory procurement rules, confidentiality arrangements, conflict declarations and approval stages. If the process itself is uncertain, settle that governance first.

Australian procurement terminology varies

Australian organisations may call the document an RFP, RFQ, RFT, tender or EOI. Internal procurement rules and any governing framework determine the correct process. The principles here concern the quality of information, clarification and comparison, rather than treating one label as a universal legal format.

Describe the business problem and intended outcomes

Start with why the website needs to change. Explain what is difficult for customers, prospects, members, partners, staff or other priority audiences. Describe the business consequences, such as poor-quality enquiries, fragmented content, slow publishing, weak product discovery, inaccessible journeys or duplicated administration.

Set outcomes at a level that allows agencies to propose a responsible approach. Useful outcomes might include helping a defined audience complete a priority task, improving the quality of leads passed to sales, reducing content duplication, supporting regional governance or making a service more inclusive. Include available baseline evidence and say how improvement may be assessed. Do not invent a target merely to make the document look measurable.

Keep desired outcomes separate from assumed solutions. The need to let customers find the right service is an outcome. A particular menu design, search product or CMS feature is a possible solution. If a solution is genuinely mandated, explain why and identify the governing constraint.

Give every bidder the same current-state evidence

An agency cannot assess transition risk from a page count alone. Provide a concise current-state picture: the platform and relevant versions, domains, languages, content types and approximate volumes, integrations, forms, analytics, consent tools, authentication, hosting parties, third-party services and known technical debt. Identify system owners and any access limitations.

List the artefacts that can be made available to shortlisted respondents, such as analytics summaries, content inventories, brand guidelines, architecture diagrams, accessibility findings, security requirements and API documentation. Use suitable confidentiality controls where information is sensitive. Give all bidders materially equivalent access and clarification.

If an important fact is unknown, say so. An explicit unknown is more useful than an inaccurate requirement. Ask agencies to explain the consequence of the uncertainty, the evidence needed to resolve it and how their recommendation would change if the assumption proved false.

Separate fixed requirements, preferences and open questions

A common RFP weakness is that every stakeholder request appears as a mandatory requirement. This creates a crowded scope, discourages better alternatives and makes trade-offs invisible.

Classify each material item. Fixed requirements are evidenced constraints, such as an approved brand, a required identity provider, a contractual integration, a defined accessibility objective or an organisational security control. Preferences are desired technologies, features or methods that respondents may challenge with reasoning. Open questions are matters where the organisation does not yet have enough evidence to select or price a solution.

Use paid Full Website Discovery when an open question materially affects the solution. Examples include uncertain data flows, complex integrations, major content migration, ecommerce rules, portals, permissions, multi-region requirements or consequential security and governance decisions. A straightforward, controlled public website may need a smaller planning pathway. The correct level depends on the actual unknowns and consequences.

The classification should reflect evidence and consequence, not stakeholder confidence alone.

Require a common agency response

Let agencies bring different thinking, but make them present it in a form that supports comparison. Supply a mandatory response schedule covering understanding of the problem, recommended approach, phases, deliverables, proposed team, responsibilities, client dependencies, timing logic, assumptions, exclusions, material risks, quality controls, change control, support transition and commercial structure.

Ask respondents to separate professional services from third-party platform, app, licence, payment, fulfilment and hosting costs. Those third-party services are normally contracted and paid directly by the client. Emote does not sell or resell hosting infrastructure; it may advise on requirements and coordinate with an appropriate provider or the client’s suitable existing host.

Request price conditions, not only a total. What evidence was available? What volumes were assumed? Which features rely on standard configuration, extensions or custom work? What is outside the estimate? What would trigger a variation? An apparently lower price can be less comparable if it transfers substantial work or risk back to the client.

Score evidence, risk and fit, not presentation polish

Agree the evaluation dimensions and their relative importance before proposals arrive. Typical dimensions include understanding of the problem, relevance of delivery evidence, quality of reasoning, proposed team access, governance, approach to risk, commercial fit and the credibility of dependencies. The weighting should reflect the organisation and project rather than a universal template.

Record panel scores and the reasons behind them. Discuss large scoring differences rather than averaging them away. Ask whether the evidence supports the confidence expressed. A carefully qualified proposal may be stronger than one that promises a fixed solution without seeing the content, systems or data.

Treat unexplained certainty, an unusually low price, generic case studies, vague team access and missing client dependencies as questions to investigate. None is an automatic rejection, but each can indicate that the proposals are describing different work.

Run a fair clarification and selection process

Give respondents reasonable time and a clear channel for questions. Share material clarifications with all bidders, subject to legitimate confidentiality boundaries. If the RFP changes, identify what changed and allow responses to be adjusted.

Shortlist before asking for high-effort presentations. Do not require unpaid strategy, architecture, wireframes, prototypes, visual concepts or bespoke technical specifications as a condition of being considered. Those artefacts require context and professional effort, and speculative work often rewards presentation theatre rather than the team and method that will produce the strongest result.

Separate four decisions: preferred partner, contract, Discovery or definition phase, and implementation approval. Selection does not remove the need to validate consequential assumptions. The implementation scope should be approved only when the evidence supports it.

A practical website RFP structure

A decision-ready RFP can remain concise if it directs respondents to supporting material. The following structure is a sound starting point, to be adapted to the organisation’s governance and project risk.

• Organisation, project context and procurement contacts
• Business problem, priority audiences and intended outcomes
• Current website, content, technology, data and supplier landscape
• Fixed constraints, preferences and explicitly open questions
• Expected engagement phases and the boundary of any required Discovery
• Common response schedule for approach, team, responsibilities, assumptions, risks and costs
• Third-party cost and account-ownership requirements
• Evaluation process, clarification rules, timetable and decision rights
• Contractual, privacy, security, accessibility and legal review requirements
• Appendices and controlled access to supporting evidence

The RFP should ask the agency to demonstrate how it will reach decisions, not to invent a complete solution before it has the evidence. That distinction produces clearer proposals and a more defensible appointment.

Make assumptions and dependencies first-class commercial information

Require every respondent to maintain an assumption schedule rather than scattering qualifications through the proposal. Each assumption should identify the affected scope, evidence used, owner, consequence if false and the point at which it must be validated. This turns vague caveats into manageable project controls. It also shows whether an agency has understood the limits of the available information. Making dependencies explicit also reduces the conditions under which website projects blow out.

Dependencies need the same discipline. A client-supplied content decision, API access, legal approval, data extract or brand asset can control the critical path even when the agency’s build work is progressing. Ask respondents to explain which client inputs are needed, how much notice is required and what happens if they are late. The RFP timetable should allow the organisation to meet those responsibilities rather than transferring them invisibly into delivery risk.

Ask for a clear change-control method. The proposal should distinguish clarification within the approved scope from a variation that changes effort, timing, risk or deliverables. It should explain how an emerging issue is documented, estimated, approved and reflected in the plan. A fixed price is only useful when the boundary and change mechanism are equally clear.

Design a timetable that permits useful responses

Work backwards from the quality of decision required, not from an arbitrary announcement date. Allow time for agencies to review the material, ask questions and obtain input from the people who would actually deliver the work. Very short response windows can favour pre-written marketing content and reduce the technical, content and governance scrutiny the buyer needs.

Publish the intended stages: release, clarification, response, shortlist, presentation, reference or due-diligence checks, preferred-partner decision, contracting and any paid Full Website Discovery. State which dates are firm and which are indicative. Tell respondents when they will receive answers and how material changes will be communicated. This also lets agencies identify whether the proposed implementation deadline is compatible with the procurement process itself.

If presentations are required, give shortlisted teams the same scenarios and evaluation criteria. Ask to meet the proposed delivery people, not only senior sales representatives. Use the session to test reasoning, collaboration and response to uncertainty. A polished concept created without discovery is weaker evidence than a team that can explain what it would validate, why it matters and how that decision affects implementation.

Check whether proposals still describe the same project

Before scoring totals, normalise the proposals. Build a comparison view for phases, deliverables, content, migration, integrations, environments, testing, training, launch, warranty, support, licences, third-party costs and client effort. Mark included, excluded, assumed and unresolved items. Do not insert a missing item into an agency’s scope without clarification. Use how to compare website proposals as the downstream evaluation guide.

Then conduct a scenario check. If content volume doubles, an integration lacks the expected endpoint or a security requirement changes, which proposal has described a responsible path? This is not an invitation to price every hypothetical. It tests whether the commercial and delivery model exposes risk and has usable decision gates.

The final selection record should explain the chosen partner, material trade-offs, assumptions accepted and matters reserved for Discovery or contract. That record protects continuity when stakeholders change and gives the mobilisation team an honest starting point.

The strongest comparison is not simply line-item price against line-item price.

Frequently asked questions

How detailed should a website RFP be?

Detailed enough to establish outcomes, evidence, constraints, response requirements and procurement rules. It should not manufacture certainty about architecture, integrations or migration. Use appendices for supporting material and identify what remains to be validated.

Should an RFP include a budget?

A credible approved budget or planning range can help agencies assess fit and propose proportionate pathways. Explain what the budget is expected to cover and whether third-party costs sit inside or outside it. Do not publish an arbitrary ceiling simply to drive lower bids.

Should we prescribe the CMS or technology stack?

Only where the decision is already governed by valid evidence and constraints. Otherwise describe the required outcomes, integrations, ownership, security and operating model, then ask respondents to explain their recommendation and trade-offs.

Can agencies provide fixed implementation prices from an RFP?

Sometimes, when the scope and dependencies are genuinely clear. If consequential unknowns remain, a responsible response may price a definition or Discovery phase first and keep implementation subject to the resulting evidence.

How many agencies should receive the RFP?

There is no universal number. Invite enough credible respondents to support the organisation’s procurement objective without creating unnecessary effort for the buyer or market. An early capability screen can keep the formal shortlist focused.

Should we ask for free concepts or wireframes?

No. Speculative design is produced without the research, content and collaboration needed for a responsible solution. Evaluate relevant evidence, team quality, method and reasoning, then commission project-specific strategy and design within an agreed paid engagement.

Does a strong RFP remove the need for Discovery?

No. It can make known information and uncertainties clearer. Discovery is still appropriate where the unanswered questions materially change users, content, architecture, data, integrations, risk, governance or implementation scope.

How Emote can help

Emote can help translate a website opportunity into a clear procurement brief, with outcomes, assumptions, dependencies, responsibilities and comparison fields made explicit.

Where requirements are contained, the next step may be a defined website proposal. Where content, integrations, data, security or governance remain material, paid Full Website Discovery can establish the evidence needed before scope is fixed.

If you are preparing to approach website partners, book an initial meeting with Emote to discuss the most appropriate next step.