RFQ vs RFP vs RFI: Which Sourcing Document, and When
Three sourcing documents that get used interchangeably and should not be — what an RFI, RFQ, and RFP each ask for, when each fits, and the cost of picking the wrong one.
RFI, RFQ, and RFP are three different questions you can put to the market, and treating them as synonyms is how buyers end up comparing incomparable bids. An RFI asks who is out there and what can they do. An RFQ asks what will you charge for exactly this. An RFP asks how would you solve this, and at what price. The document you choose is a declaration of how well you already understand what you are buying.
| Document | The question it asks | You use it when |
|---|---|---|
| RFI — Request for Information | Who can do this, and how do they approach it? | You are scoping the market and do not yet know your options or requirements |
| RFQ — Request for Quotation | What is your price for this exact, defined item? | Specs are fixed and price is the main variable — commodities, standard goods |
| RFP — Request for Proposal | How would you solve this, and what would it cost? | The solution is complex, open-ended, or the "how" matters as much as the price |
RFI: mapping the field
A Request for Information is the low-commitment opener. You do not know who supplies this, what capabilities exist, or what a sensible requirement even looks like — so you ask. Responses are qualitative: capabilities, references, rough approaches, indicative (not binding) pricing. The output of an RFI is a shortlist and an education, which then feeds a sharper RFQ or RFP. Skipping it is fine when you already know the market; running it when you do not saves you from writing a specification that no supplier can actually meet.
RFQ: price on a fixed spec
A [Request for Quotation](/glossary/request-for-quotation) is the workhorse of routine procurement. It works precisely because the specification is nailed down: same item, same quantity, same delivery terms, so the only variable left is price (and sometimes lead time). Because every quote answers an identical question, they are directly comparable — you can line them up side by side and the decision is largely arithmetic. This is the document behind competitive quote comparison: three quotes, one grid, a defensible choice.
The RFQ trap: a vague spec turns quotes into guesses
An RFQ is only comparable if the specification is complete. Leave brand, grade, delivery, or warranty open and each supplier fills the gap differently — now you are comparing a cheap quote for inferior goods against a fair quote for the right ones, and the cheapest "wins" by quietly quoting something else. If you cannot write a tight spec, you do not need an RFQ; you need an RFI or an RFP first.
RFP: buying a solution, not a SKU
A Request for Proposal is for when you can describe the problem but not dictate the solution — a software rollout, a construction project, a service contract, anything where suppliers bring different methods. An RFP states outcomes, constraints, and evaluation criteria, then invites suppliers to propose how they would deliver, with pricing attached. Evaluation is multi-dimensional and scored — technical approach, experience, timeline, risk, and price together — not a single lowest-number pick. The RFP is more work to write and to judge, and that effort is the point: you are choosing an approach, and the cheapest approach is frequently the worst one.
Choosing correctly — and why it matters downstream
- Know your options but not your price? RFQ. The market and spec are clear; competition on price is what you want.
- Know the problem but not the best solution? RFP. Let suppliers propose, then score the approaches.
- Know neither? RFI first, then an RFQ or RFP once you understand the field.
- Using an RFP to buy a commodity buries a simple price decision under proposal admin. Using an RFQ to buy a solution forces suppliers to quote a price for a problem nobody has scoped — and you get what you paid for.
The choice ripples through the rest of the procure-to-pay chain: a clean RFQ produces a clean PO and a clean three-way match; a fuzzy sourcing document produces disputes at the receiving bay and the invoice. Whichever you run, the discipline is the same — issue it to multiple suppliers, capture responses against the same criteria, and keep the scoring on record. That audit trail is what turns a supplier choice into a defensible one, which matters most in NGO and public procurement where every award may be questioned. Supplier responsiveness and quality over time also belong on file, feeding vendor performance so the next sourcing round starts from evidence, not memory.
What AWRA OpsHub does today
- RFQs as a real record, issued to multiple suppliers with line items, plus an approval permission of their own.
- Supplier quotations captured against the RFQ, so responses are comparable rather than scattered across email.
- The award trail onward: quotation to purchase order to receipt to invoice to payment, each referencing the last.
- Supplier prequalification as a separate front door — a public per-tenant application, document capture, review and approval before a supplier becomes usable.
- Vendor blacklisting with a reason, a date and an actor.
More we can add to your workspace
- An RFP entity: a request-for-proposal document, a scoring model, weighted evaluation criteria and panel scoring. A complex proposal exercise happens outside the system today.
- A RFI entity either — an information-gathering round has nowhere to live except as notes or an RFQ used loosely.
- Sealed-bid handling, withholding quotations from viewers until a closing date.
- Collusion detection and price benchmarking are judgements about intent and about a market reference we decline to assert. We record what suppliers said; whether it was rigged or expensive is your audit.
So map the article onto us honestly: the RFQ column is built, the other two are process you run elsewhere and attach evidence to. For a straightforward price comparison that is enough. For a donor-funded tender with weighted scoring and a panel, expect to run the evaluation outside and record the outcome here.
Anything above that you need, we can build for you
Everything listed above as something we can add describes what ships in the standard product today — it is a starting point, not a limit on what AWRA OpsHub can do for your organisation. Kenya's eTIMS integration and its maintained payroll engine are both in the product because clients needed them and commissioned them; neither appeared by itself, and the same door is open for whatever you just read about. One qualification so this is worth what it claims: a small number of things on this blog we deliberately leave to a specialist rather than build — a statutory ledger we will not sign our name to, a rule that would decide a tax question for you, a clinical or member-funds record that belongs in a regulated system — and where that is true the post says so in those words. Everything else is a scope, a timeline and a price.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
The module-shaped additions, which are the ones readers ask for most often
A price list with real discount authority, a customer-facing quotation that expires, a bill of materials or recipe costing, a staff advance that is issued, acquitted and chased, a member or unit ledger, a matching rule that holds a payment. Each of these is a build rather than a setting, and each has been quoted before — a bigger piece of work than a custom field, with a written spec and a date instead of a roadmap slide.
The report, document or pack nothing currently produces
The board pack in the shape your board actually asks for, a donor or funder layout, an invoice or receipt template carrying what your regulator or your customer expects, a dataset the report builder cannot reach yet. Usually the fastest thing on this list to deliver, because the data is already in the system.
Systems, rails and hardware you already run
The accounting package, CRM, online store, core banking or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed. Plus the physical edge: a scanner, a scale, a weighbridge or a till peripheral feeding the door it belongs to.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. Nothing here waits on a regulator or a published specification, which is why operational builds are the ones we quote fastest. Tell us the requirement that would otherwise rule us out — that is a better first conversation than a demo.
Tell us what your operation needsRun sourcing that stands up to scrutiny
AWRA OpsHub issues RFQs to multiple suppliers, compares responses on one grid, and keeps the full sourcing trail — from request to award to PO.
See sourcing and quote comparisonFrequently asked questions
What is the core difference between an RFQ and an RFP?
An RFQ asks for a price on a fully specified item — the spec is fixed and price is the variable, so quotes are directly comparable. An RFP asks suppliers to propose *how* they would solve a problem, with pricing as one factor among several. Use an RFQ for defined goods, an RFP for complex or open-ended solutions.
When should I use an RFI?
When you do not yet know who supplies what you need, what is feasible, or how to write the requirement. An RFI is a low-commitment way to map the market and build a shortlist. Its output feeds a sharper RFQ or RFP later. If you already know the field well, you can skip straight to those.
Can I use an RFQ for a complex project to keep things simple?
It backfires. An RFQ assumes a fixed specification; a complex project does not have one yet, so suppliers either refuse to quote or quote wildly different scopes, and the cheapest number wins by quoting the least. Complex, solution-shaped purchases need an RFP so approaches can be compared, not just prices.
Do these documents need to be competitive to be useful?
For control and value, yes — issue them to multiple suppliers and evaluate responses against the same criteria. A single-source RFQ or RFP is really just a negotiation with one party, which is sometimes justified but should be a documented exception. Competitive sourcing with a recorded trail is what makes an award defensible in an audit.
