RFI vs RFP vs RFQ: When to Use Each (Templates and Scoring)

What is the difference between an RFI, an RFP and an RFQ?

RFI vs RFP vs RFQ is a key topic in modern project management and teamwork. An RFI gathers information about what the market can do. An RFP asks shortlisted vendors to propose how they would meet a defined requirement, with pricing and references attached. An RFQ asks for a price against a specification that is already fixed, so the only real variable left is cost. The three documents differ in purpose, in how much of the requirement you have already decided, and in what you can legally do with the answers.

That distinction is doing more work than most buying teams realise. An RFI is not a soft RFP, and an RFQ is not a shortened RFP. Each one produces a different kind of evidence, and each one creates a different expectation in the vendor’s mind about what happens next.

A fourth document sits beside these and causes most of the confusion in construction: the RFI raised during delivery, not during procurement. It is a formal question to the architect or engineer about a drawing, a specification, or a conflict between the two, and it is tracked in an RFI log rather than scored in a matrix. Same acronym, different job. This guide covers both, because most searches for “RFI” mean one of the two and the templates overlap more than people expect.

When should you use each one?

Use an RFI when you cannot write a good requirement yet. Use an RFP when the requirement is clear but the route to it is not. Use an RFQ when both are settled and you are buying a commodity, a defined quantity, or a renewal.

The trigger for an RFI is a gap in your own knowledge, not a gap in the market. If your team cannot say which integration patterns are realistic, whether a capability even exists at your scale, or what a budget should look like, an RFI buys that knowledge cheaply. Ten vendors, a five-page questionnaire, two weeks: you finish with a market map and a defensible budget range instead of a guess.

The trigger for an RFP is accountability. You are about to commit money and reputation to one option, and you need the choice to survive an audit, a board question, or a challenge from an unsuccessful bidder. An RFP produces the paper trail: the requirement, the criteria, the scores, the reasons.

The trigger for an RFQ is repetition. You have bought this before, the specification is stable, and the meaningful differences are price and lead time. Running a 40-page RFP for a purchase you make every quarter is a way to spend $9,000 of internal time to save $400.

There is a failure mode at each end. Teams that run RFIs for everything end up with a library of market research and no decisions. Teams that run RFQs for everything end up buying the cheapest option that meets a specification written by someone who did not know what was available.

What does a good RFI document contain?

A good RFI contains a clear purpose statement, the scope boundaries, a short company and technical context section, a structured question set, the response format and deadline, and an explicit statement of what you will and will not do with the answers. The question set is where most RFIs fail: too many questions produce marketing brochures, and too few produce nothing you can compare.

Write questions that cannot be answered with “yes”. “Do you support SSO?” invites a yes from every vendor, including the ones whose SSO costs extra and only works with one identity provider. “Describe how a user authenticates with SAML 2.0, which identity providers you have certified, and whether SSO is included in the base tier” produces something you can score.

A workable structure:

1. Purpose and background — two paragraphs, no marketing language.
2. Scope — what is in, what is explicitly out, and which sites or teams are affected.
3. Current state — systems, volumes, headcount, known pain points, with numbers.
4. Functional questions — grouped by capability, capped at 25, each with a “describe how” framing.
5. Technical and security questions — hosting, data residency, encryption, identity, audit, export.
6. Commercial questions — pricing model, minimum commitment, implementation approach, typical timeline.
7. References — two customers of similar size and sector, with contact permission.
8. Response instructions — format, page limit, deadline, single point of contact, and the Q&A window.

The Q&A window matters more than it looks. Publish every question and every answer to every participant, on a stated date. It keeps the process fair, it stops one vendor from getting an advantage through a private phone call, and it produces a written record you will want when the shortlist is challenged.

How do you score an RFI or RFP properly?

Score against a weighted matrix that you publish with the document, using a fixed scale and written justification for every score. The matrix has three parts: criteria, weights that sum to 100, and a scoring scale with descriptions of what a 1, a 3, and a 5 look like. Without the last part, two evaluators will read the same answer and land four points apart.

Two rules make the matrix honest. First, must-haves are pass/fail and are assessed before scoring; a vendor that fails a must-have is removed, not marked down. Second, price is scored by formula, not by feel: the lowest compliant three-year total gets full marks, and every other bid gets `5 × (lowest price ÷ its price)`. That formula keeps a $96,000 bid from being called “reasonable” because the presenter was convincing.

What does a filled example look like?

Four vendors, one requirement, the weights above. Functional and integration scores come from the written responses and two demo sessions; price is the compliant three-year total including implementation and training.

The arithmetic for B: `(5.0 × 35) + (4.0 × 20) + (1.9 × 25) + (3.0 × 10) + (5.0 × 10) = 382.5`, divided by 5 gives 76.5 out of 100. Vendor C’s price score of 5.0 comes from being the lowest bid; B’s 1.9 comes from `5 × (36 ÷ 96) = 1.875`, rounded.

B wins by half a point over C, and the half point hides a $60,000 difference. That is not a result you act on. It is a signal that the matrix is under-specified, and the right move is a sensitivity check before award.

Change the weights to 25% functional, 20% integration, 35% price, 10% support, 10% references — a defensible position if the two products are close on capability — and the ranking inverts: C scores 80.0, A 74.6, D 71.0, B 70.3. Same evidence, different decision.

That is the single most useful thing a scoring matrix does. It shows you which criteria your decision actually rests on, while you can still argue about the criteria instead of arguing about the vendors.

What does the timeline look like in practice?

A procurement with an RFI, an RFP and an RFQ runs 10 to 14 weeks end to end. Compressing it below eight weeks usually means the evaluation is being done in evenings, which is where scoring discipline dies.

Two timing mistakes are common. The first is running demos before reading the written responses, which turns the process into a presentation contest. The second is leaving reference calls to the end; a bad reference at week seven is a gift, and the same bad reference at week twelve is a crisis.

How do you keep an RFI log during delivery?

An RFI log is a numbered register of every question raised during construction or delivery, with the date sent, the date the answer is due, the answer itself, and the cost or schedule impact if the answer changes the scope. It exists to answer one question after the fact: did we ask, did we get an answer, and did anyone act on it.

Three habits separate a log that works from one that becomes a second inbox. Number sequentially and never reuse a number, even for a withdrawn question. Enforce one question per RFI, so answers cannot be half-complete. And review the open list in the weekly site meeting, sorted by days overdue, not by date raised.

The numbers in a live log are more useful than the individual entries. A 240-RFI project with a median response of 4 days and nine items past 14 days is healthy. The same project with a median of 11 days and forty open items is showing you a design coordination problem, and the log is the evidence you need to raise it before it becomes a delay claim.

How do you avoid the common mistakes?

The expensive mistakes are structural, and they repeat across sectors.

Asking vendors to design your requirement for free. A long RFI question set with no stated intent reads as a free consulting request, and the strongest vendors decline. Say what you are buying and when.

Publishing criteria after the bids. Even when the outcome is fair, it looks rigged, and unsuccessful bidders have a legitimate complaint. Publish criteria and weights with the RFP, and record any change with a date and a reason.

Scoring on the demo. Demos reward presenters. Score the written response, use the demo only to confirm or challenge a specific score, and note which one changed and why.

Letting one person own the whole matrix. Single-evaluator scoring is fast and biased. Two evaluators per criterion, resolving gaps of more than one point in writing, costs about two extra hours and prevents most challenges.

Treating the RFQ as a formality. Unit price is not total price. A cable quote at $18.40 per metre plus $900 delivery is $22,980 for 1,200 metres; a quote at $19.10 with delivery included is $22,920. The higher unit price is $60 cheaper, and a straight unit-price comparison gets it wrong.

Forgetting the exit. Ask what leaving looks like: export formats, data deletion, notice period, and the cost of retrieval after termination. It is the cheapest question in the pack and the most expensive one to skip.

Where does Doitify fit?

Doitify is our product, so read this as disclosure. It is a project workspace where tasks, sub-tasks, checklists, owners, and due dates sit beside Kanban boards, Gantt charts, roadmaps, calendars, workload views, reports, automations, and project documents.

For procurement and RFI work, the practical value is that the register lives next to the project it affects. An RFI log becomes a task list with an owner and a due date, an overdue answer shows up in the workload view, and the weekly site meeting opens the same filtered list everyone else sees. When an answer changes scope, the variation is a linked item rather than a note in an email thread. Teams that run several tenders a year can also keep the evaluation matrix, the score sheet, and the award note in the same project, which is exactly what an auditor asks for eighteen months later.

What it will not do is write your requirement or decide your weights. Those remain judgement calls, and the matrix only makes them visible.

Conclusion

RFI, RFP and RFQ are three instruments for three different levels of certainty. The RFI reduces ignorance about the market, the RFP converts a requirement into a defensible choice, and the RFQ prices a scope you no longer need to debate. Most procurement failures come from using the wrong instrument with confidence rather than from picking the wrong vendor.

If you take one practice from this guide, take the published matrix. Criteria, weights, scale descriptions, and a price formula, all written before the first response arrives. It costs an afternoon, it survives an audit, and it turns a room of opinions into a number you can defend.

If this post on RFI vs RFP vs RFQ was helpful, you might also enjoy Free Communication Plan Template and Project Management Software for Nonprofits: 2026 Guide.