RFP Examples: Templates and Real-World Samples

Most buyers do not need a theory of procurement. They need a document they can open, edit and send out this week. This guide gives you a reusable request for proposal outline, section by section, and then shows the same outline stretched over three very different purchases: a software platform, a facilities services contract and a manufactured component. The examples are illustrative and generic, so you can lift the structure, the tables and the scoring grids straight into your own template.

A reusable RFP outline

A request for proposal is a structured invitation for suppliers to describe how they would meet a need and what they would charge. The structure below is deliberately plain. It has eight blocks, it reads in the order a supplier thinks in, and it maps one to one onto the evaluation grid you will use later.

• Background and objectives. Who you are, why you are buying, and what a good outcome looks like in twelve months.
• Scope of work. The boundary of the engagement, stated as what is in and what is explicitly out.
• Requirements. Numbered, testable statements split into mandatory and desirable.
• Questions to suppliers. Open questions about approach, team, references and risk, each with a word limit.
• Commercial format. A fixed pricing table every bidder must complete, so costs line up.
• Evaluation criteria and weightings. The categories, their weights and how scores are awarded.
• Timeline. Issue date, clarification window, submission deadline, demonstrations, award, mobilisation.
• Terms and conditions. Contract form, service levels, data and compliance obligations, and any deal breakers.

Keep the numbering stable across every RFP your organisation issues. When section 3.4 always means a mandatory requirement and section 6 always means evaluation, your team stops rereading the document from scratch and suppliers who bid with you regularly answer faster and better. Our complete RFP guide covers the process around the document; this article stays with the document itself.

What goes in each section

The table below is the working version of that skeleton. It shows the purpose of each block, a realistic length, and the one mistake that most often spoils it.

Example one: a software platform

A mid sized organisation wants to replace a set of spreadsheets and shared inboxes with a single platform. The purchase is a five year commitment, the users are internal, and switching later would be painful. That shapes the whole document.

Scope. In scope: implementation, data migration from two legacy sources, integration with the finance ledger, training for roughly two hundred users, and three years of support. Out of scope: hardware, process redesign, and any change to the finance ledger itself.

Requirements. A numbered matrix split into functional, technical, security and support. Each line is marked M for mandatory or D for desirable, and suppliers respond with a compliance code: fully met as standard, met via configuration, met on the published roadmap, or not met. That single convention does more for comparability than any amount of narrative.

Evaluation. Because the risk sits in adoption and integration rather than in unit price, the weightings tilt towards capability and delivery.

The commercial table for a software buy should ask for year one and years two to five separately, list licence, implementation, integration and support as distinct lines, and require any assumption about user counts to be stated. Otherwise the cheapest headline invariably turns out to exclude migration. If you are on the receiving end of documents like this, our guide to writing RFP proposals looks at the same structure from the supplier's side.

Example two: a facilities services contract

Now take a three year cleaning and maintenance contract across four sites. Nothing is being built and nothing is being installed. The value lies in consistent performance by people you do not employ, which means the RFP has to be specific about outcomes, coverage and measurement.

Scope. In scope: daily cleaning of listed areas, waste handling, consumables, reactive call outs within agreed response times, and planned maintenance on a published asset list. Out of scope: specialist deep cleans, grounds, and anything above a stated repair value, which is quoted separately. Include the site square footage, occupancy hours and headcount as an annexe, because suppliers cannot price labour without them.

Requirements. Written as service levels rather than features. For example, reactive call outs attended within four working hours for priority one faults, ninety eight per cent of scheduled tasks completed on time each month, and a named site supervisor present during core hours. Each service level needs a stated measurement method and a reporting frequency, or it becomes unenforceable.

Evaluation. Price carries more weight here than in the software example, because the service is well understood and the market is competitive, but staffing quality still drives the outcome.

Notice what changed. The requirement list became a service level schedule, functional fit disappeared, and mobilisation appeared as its own criterion because a botched handover in a live building is felt immediately. The skeleton is identical; the muscle is different.

Example three: a manufactured component

The third example is a recurring order for a machined component, perhaps eighty thousand units a year against a released drawing. Here the specification does most of the work, and the RFP exists to test capacity, quality systems and landed cost rather than creativity.

Scope. In scope: manufacture to the attached drawing and revision, first article inspection, packaging to the stated standard, and delivery to two plants under a call off schedule. Out of scope: tooling design, which the buyer owns, and any material substitution without written approval.

Requirements. Mostly quality and process rather than product: tolerance conformance demonstrated by capability studies, a documented quality management system, traceability by batch, a stated capacity ceiling, and confirmed lead times at three demand levels. Ask for the second source plan too, because single site dependency is the real risk in this category. This is where an RFP shades into strategic sourcing, since the decision shapes your supply base for years.

Evaluation. Price weighting rises again, but it is landed cost, not unit price: piece price plus tooling amortisation, freight, duty, packaging and minimum order quantity effects. A common split is landed cost forty five per cent, quality systems twenty per cent, capacity and lead time twenty per cent, and continuity or risk fifteen per cent.

Across all three examples the ratio holds: the more the outcome depends on how the supplier works, the more weight moves away from price. That single judgement, made openly before bids arrive, is what keeps procurement decisions defensible.

Writing requirements that get comparable answers

Most unusable proposals trace back to a requirement that could be answered honestly in three different ways. A requirement is testable when a reasonable person could look at the delivered thing and say yes or no. "Good reporting" fails that test. "Users can export any list view to CSV without administrator involvement" passes it.

Four habits fix the majority of cases. Number every requirement so responses can be traced. Split compound requirements, because a supplier who meets half of a two part line will answer yes. Limit mandatory items to what you would genuinely walk away over, since an RFP where everything is mandatory tells suppliers nothing about priority. And constrain the response format, whether that is a compliance code, a word limit or a fixed table, so the evaluation team compares like with like.

It also helps to write the scoring guidance at the same time as the question. If you cannot describe what a five out of five answer would contain, the question is not ready to issue.

Common RFP mistakes

The failure patterns repeat across industries. Copying last year's requirement matrix without rereading it is the most frequent, and it produces proposals aimed at a problem you no longer have. Close behind is inventing weightings after the proposals land, which almost always rationalises a preference someone already held.

Others worth naming: leaving out exclusions, so bids cover different work; allowing free format pricing, which hides implementation and exit fees; giving suppliers ten working days for a document that took your team six weeks to write; running no clarification window, so ambiguity turns into assumption; and hiding the contract terms until after award, which is where otherwise sound processes collapse into renegotiation.

One more is quieter. Teams often evaluate on personality after a good demonstration, then reverse engineer the scores. The antidote is procedural rather than moral: score written responses before the demonstrations, record the reasons, and treat the demonstration as a separate criterion with its own weight.

From template to repeatable process

A template only pays back if it is used the same way twice. That means storing the skeleton somewhere everyone edits from, keeping a reusable requirement library per category, and holding the evaluation grid, the clarification log and the scores in one place rather than in a folder of spreadsheets emailed between reviewers.

ProcureWave gives sourcing teams that structure by default: reusable RFP templates, a requirement library, supplier responses collected in a single comparable format, weighted scoring with an audit trail, and the award flowing straight into contract and purchase order records. The document stops being a file someone owns and becomes part of the process.

If you would like to see how the outline in this article maps onto a live sourcing event, take a look at what ProcureWave does or get in touch and we will walk through one of your own categories with you.

Frequently asked questions

Is there a single RFP template that works for everything?

No, but there is a single skeleton that works for everything. Background, scope, requirements, supplier questions, commercial format, evaluation criteria, timeline and terms appear in almost every RFP. What changes between a software buy and a factory component is the weighting of those sections and the depth of the requirement list, not the running order.

How long should an RFP document be?

Long enough to be unambiguous and no longer. A routine services renewal can sit comfortably in eight to twelve pages. A complex platform replacement might run to thirty pages once the requirement matrix and terms are attached. If a section does not change how a supplier answers or how you score them, cut it.

Should evaluation weightings be published to suppliers?

Publishing the top level weightings is good practice and is mandatory in most public sector regimes. It tells suppliers where to invest their effort and it disciplines your own team, because you have to agree the criteria before you see any proposals. Keep the detailed scoring guidance internal if you prefer.

How many suppliers should receive the RFP?

Three to six is the usual sweet spot. Fewer than three makes comparison weak, and more than six creates an evaluation burden that tempts teams to skim. If you have a long list, run a short qualification stage first, as described in our guide to RFI, RFP and RFQ.

Can I reuse last year's RFP for a similar purchase?

Reuse the structure and the boilerplate terms, but rewrite the scope, the requirements and the criteria every time. Copied requirements are the single most common source of irrelevant answers, because suppliers respond to what is written rather than what you meant.