When you are choosing a production agency or a systems vendor, it is not unusual to end up thinking: this is not what we expected, or every quote rests on different assumptions so we cannot compare them. In most cases the root cause is the same. The buyer asked for proposals without first putting the request in writing. An RFP, or request for proposal, is the document that prevents this. This article covers what an RFP is, how it differs from an RFI and a quote request, the sections it should contain, and a template you can adapt directly.
What Is an RFP (Request for Proposal)?
An RFP is a document a buyer issues when outsourcing work such as system development, website production, or advertising operations. It tells candidate firms: here is the problem we want solved and the conditions we need met, now show us how you would solve it.
The key point is that an RFP is not a specification. What it defines is the problem to be solved and the conditions to be satisfied. How the work gets done is left to the proposing side. If you dictate the method in detail, you lose access to the expertise your vendors have and to better alternatives they might have suggested, which defeats the purpose of running an RFP at all.
When You Need an RFP
Redesigning a corporate site or a product site
Introducing or replacing a core system, SFA/CRM, or marketing automation tool
Switching partners for advertising operations or content production
Any situation where several firms must be compared before a decision
Large-value engagements where internal approval requires a documented rationale
Conversely, if the vendor is already decided and the job is a small one-off, a short brief may be enough without a formal RFP. Writing and evaluating an RFP takes real effort on both sides, so judge by the scale of the engagement and by whether you genuinely need to compare options.
How an RFP Differs from an RFI, an RFQ, and a Requirements Document
Several documents are easy to confuse with an RFP. Sorting them by purpose and by when they appear makes the distinction clear.
RFI (request for information): Used before you shortlist. You ask for track record, team structure, scope of capability, and a rough sense of cost. This is the stage for understanding what options exist in the market.
RFP (request for proposal): Sent to the shortlisted firms, asking for a proposal that covers approach, team, schedule, and cost.
RFQ (request for quotation): Assumes the work is fully defined and compares price. There is essentially no room for proposal.
How to Approach a Website Redesign: The Process from Requirements to Launch, with Checklists
Requirements document: Produced after the vendor is selected and under contract, to fix exactly what will be built. In most cases the vendor drafts it and the buyer approves it.
The sequence runs RFI, then RFP, then selection, then contract, then requirements definition. You do not need requirements-document precision at the RFP stage.
Four Benefits of Writing an RFP
1. Proposals become genuinely comparable
Without shared conditions, one firm quotes with maintenance included while another quotes initial build only. The assumptions diverge, and neither price nor content can be compared. Stating the conditions in an RFP puts every proposal on the same footing.
2. Internal requirements get organized
Writing an RFP forces you to collect requests from every stakeholder team and rank them. That exercise alone surfaces objectives and non-negotiables that had been left vague internally.
3. You prevent rework caused by misalignment
The late-stage arguments about what was never mentioned or what everyone assumed was included happen because scope was never written down. An RFP also serves as the reference point for alignment after the contract is signed.
4. You can explain the decision
With evaluation criteria defined in advance, you can explain objectively why a particular firm was chosen, whether to an approval committee or an auditor. A selection process that does not look arbitrary makes internal agreement far easier to reach.
The 11 Sections an RFP Should Contain
Regardless of industry or project type, covering roughly these eleven sections is enough for a document to function as an RFP.
1. Background and objectives
Explain why you are doing this now and what state you want to reach. Not we want a newer site, but we want to grow inquiries from 30 to 60 a month. Writing the intended outcome changes the quality of the proposals you receive. Add a brief overview of your business and organization.
2. Current problems
Describe your current system or site structure, operational workflow, and performance data such as traffic, transaction volume, or hours spent, along with the specific problems occurring. The more you write in facts and numbers, the more precisely vendors can respond.
3. Scope of work
Write both what is in scope and what is out of scope. Stating boundaries such as copy and photography supplied in-house, or maintenance under a separate contract, avoids disputes over additional costs later.
4. Functional and non-functional requirements
Alongside the features you need, do not forget non-functional requirements: performance, security, availability, supported browsers, accessibility, and integration with existing systems. Marking each as required, preferred, or optional gives vendors room to propose within your budget.
5. Deliverables and handover format
Define what must be delivered for the work to count as complete: design files, source code, documentation, manuals, and the ownership of copyright and source code. The items most likely to cause friction later are exactly the ones to write down first.
6. Schedule
State your target launch date and any immovable constraints, such as a campaign start or the expiry of an existing contract. When the constraints are explicit, vendors can build a realistic plan around them.
7. Budget
Give a ceiling or an expected range, and separate initial cost from running cost so the quotes come back in comparable form. Hiding the budget only invites proposals that are unaffordable or padded, which wastes evaluation time.
8. Team and division of responsibility
Name your project owner and decision maker, the hours your side can commit, and the meeting cadence. How much the buyer can actually do changes the working method a vendor should propose.
9. What the proposal should cover
List the items you want in the proposal: approach, team chart, schedule, cost breakdown, comparable past work, and risks with mitigations. Specifying this at the level of a table of contents means every proposal arrives in the same structure, which makes comparison dramatically easier.
10. Evaluation criteria and method
Disclose what you will assess and with what weighting, for example 40 points for problem understanding and proposed approach, 25 for track record and team, 25 for cost, and 10 for ongoing support. Publishing the criteria up front focuses the proposals and keeps your internal scoring consistent.
11. Submission process, timeline, and contact
State the deadline, where to submit, file format, the question window and answer date, whether there will be a presentation and when, and when the decision will be communicated. Add a line on confidentiality as well.
An RFP Template You Can Use as Is
Use the following structure directly as your section headings and fill each one in. Ten to twenty pages is a reasonable length.
Introduction (purpose of this document, handling notes, confidentiality)
About us (business overview, organization, related services)
Background and objectives (target outcomes and KPIs)
Current state and problems (existing environment, performance data, issues)
Scope (in scope and out of scope)
Requirements list (functional and non-functional, marked required, preferred, or optional)
Deliverables and ownership of rights
Schedule (milestones and constraints)
Budget (initial and running cost, ceiling or range)
Team and division of responsibility (buyer side and vendor side)
Proposal requirements (list of items the proposal must cover)
Selection method (evaluation items, weighting, and process)
Submission instructions (deadline, format, destination, questions, presentation dates)
Appendices (current site map, screen inventory, data definitions, and similar)
Five Steps from Drafting to Selection
Step 1: Gather requirements internally
Collect the pain points and expectations of each group involved, including the operating teams, IT, and management. At this stage, do not filter. Get everything on the table first.
Step 2: Prioritize the requirements
Sort what you gathered into required (without this the project has no point), preferred (this improves the outcome), and optional (only if there is room). If everything is marked required, no proposal will come back inside your budget.
Step 3: Write the RFP and secure internal approval
Draft along the structure above and get sign-off from the decision maker before distribution. The worst outcome is having the premises overturned after proposals are already in hand.
Step 4: Distribute and run a question period
Take questions in writing and share the answers with every firm, which keeps the process fair. The questions themselves are useful feedback: they show you exactly where the RFP is thin.
Step 5: Score against the criteria and decide
Have several people score individually against the published weighting before discussing. Discussing first tends to pull the room toward whoever speaks loudest, so score first as a rule.
Five Things to Avoid
Over-specifying the method: Locking in a particular CMS or architecture shuts out better options. If a constraint is real, explain why it exists.
Vague adjectives: Easy to use and modern cannot be evaluated. Translate them into testable criteria such as application completed within three clicks, or under three seconds to render on mobile for key paths.
Inviting too many firms: Writing a proposal costs vendors real hours. Three to five is realistic, and beyond that your own evaluation load becomes unmanageable.
Allowing too little time: Give two to four weeks from distribution to submission. A shorter window yields nothing but recycled boilerplate.
Setting criteria after the fact: Deciding how to evaluate once proposals are in hand leaves you unable to defend the decision. Fix the weighting before distribution.
Frequently Asked Questions
Should we disclose the budget?
Yes, we recommend it. The instinct to withhold in order to keep costs down is understandable, but in practice it just produces proposals at wildly different scales and makes comparison harder. Stating a ceiling and asking for the best solution within it tends to produce better proposals.
How long should an RFP be?
Ten to twenty pages is typical. What matters more than length is whether the information needed to make a judgment is present. Detailed screen inventories and data definitions are easier to read as appendices than buried in the body.
Can we issue an RFP before requirements are settled?
You can. An RFP is precisely the document for presenting a problem before requirements are fully fixed and borrowing expertise. Mark the unsettled areas as undecided and note that you welcome proposals on them, and you will get constructive answers.
Do we need to notify the firms we did not select?
Yes. Since they invested real hours in the proposal, communicate the outcome promptly and give reasons where you can. Handling this well protects your reputation and determines whether strong firms are willing to participate next time.
Summary
An RFP is the document that communicates the problem you want solved and the conditions that must be met, so that you receive proposals you can actually compare. Cover the core skeleton, which is background and objectives, current problems, scope, requirements, budget, and evaluation criteria, and the document will do its job regardless of formatting.
Writing one is not a small effort, but given that the process organizes your internal requirements and reduces rework after selection, it is time well spent. Start by using the template structure above as a skeleton and adding or removing sections to fit your own project.
A seven-phase website redesign process, from current-state analysis through requirements definition, partner selection, ...
