Request for Information Template: How to Build It

Don't add more questions to fix a weak request for information template. That's the most popular advice on this topic, and it's backwards. More questions usually means more brochures, more incompatible answers, and a later specification that copies one supplier's language.

What works is fewer, tighter questions. Give every question an ID, a response type, and an evidence ask. Then suppliers can't hide a no inside a paragraph, you can compare answers side by side, and you keep a traceable record from each answer to the line it eventually shapes in your specification. The RFI stays what it should be, market research before a competition, not a short RFP in disguise.

Table of Contents

• Sections Every Request for Information Template Needs

  • The Eight Blocks in Document Order

  • A Copyable Skeleton You Can Draft Today

• How to Draft the RFI Before You Send It

  • The Six Moves

• Questions and Answer Formats That Compare

  • Pair Every ID With a Response Type

  • Two Worked Questions for the PC Refresh

• Pre-Send Gate and Response Scoring

  • Five Checks Before Release

  • Score the Information, Not the Supplier

• Move From RFI Answers to a Traceable Spec

  • Where Tools Earn Their Place

  • Test It on One RFI Before You Roll It Out

Sections Every Request for Information Template Needs

Put the line most templates bury on page one. An RFI is not a bid and not an award. The U.S. National Institutes of Health NITAAC request for information template states an RFI is generally used when the solution to a business problem is not yet evident or clearly defined, and its purpose is to gather information rather than select a supplier or make a contract award. Nevada's template says no contract award results from it, and Arkansas guidance says an RFI is not itself a procurement method.

That boundary decides everything else in the file. You're testing whether the market can meet an emerging need, what approaches exist, and what a later specification should say. Aggregated answers may support a budget justification or help you draft a later solicitation. They don't pick a winner.

The Eight Blocks in Document Order

Government templates in Massachusetts, Colorado, and New Zealand converge on this same shape for a reason. Administrative controls, context, structured questions, response rules, and a non-award disclaimer turn open-ended research into evidence you can file and defend later.

A Copyable Skeleton You Can Draft Today

Say you're refreshing servers or facilities equipment and you don't yet know whether to buy hardware, a managed service, or both. Don't write the specification first. Use this order:

• Header line: RFI [reference] | Released [date] | Respond by [date] | Contact [name]

• Purpose: State the problem in plain language, then add the disclaimer. No obligation to buy, responses aren't offers, participation creates no advantage later.

• Background: Give only the constraints a stranger needs. Site count, user range, existing systems that can't change. Skip the internal history.

• High-level requirements: Write needs more generally than a final spec, so a supplier can still propose a different architecture.

• Questions Q1 to Q10: Each with an ID, a response type, and an evidence ask.

• Response rules: Channel, format, and limit. One place to submit, one contact for clarifications.

• Confidentiality and publication: What you'll share, what stays private, where answers to clarifications will be posted.

• Later use: Answers may shape a later solicitation. Non-respondents stay eligible.

Practical rule: If a supplier needs a call with you to understand the purpose, the background block has failed. Rewrite it before you send anything.

Build this as a one-page cover plus a response form. Label the file informational on the cover, not in a footnote. Give suppliers at least a month to reply, because a rushed window gets you recycled sales material instead of a relevant answer. I'd rather wait and get three comparable responses than move fast and get ten brochures I can't use.

How to Draft the RFI Before You Send It

An RFI can shape a specification without becoming a disguised bid. Keep its questions focused on what you still need to learn, and make each answer traceable to the requirement it may inform.

Consider a business PC and network refresh. Devices age at different rates across sites, support costs are rising, and the buying unit is still unclear. The organization might purchase equipment, a managed service, or both. The RFI should help resolve that uncertainty rather than steer suppliers toward a predetermined solution.

The Six Moves

1. State the objective and current problem. Use a few plain sentences: devices age at different rates across sites, support costs are rising, and the organization needs to understand which service model fits. If the problem is vague, suppliers will make different assumptions and their answers will be harder to compare.

2. Give suppliers the context they need. Include relevant details such as user and site ranges, along with constraints like existing identity tools. Leave out internal history and preferred brands. The goal is to describe the operating conditions without implying the answer.

3. Organize questions around decisions. Group them by capability, assumptions, timeline, indicative commercial basis, dependencies, standards, and exceptions. Give each question an ID, response type, evidence request, and intended use, such as specification refinement or supplier discovery. If stakeholder needs are still unclear, use a requirements-gathering template that feeds into procurement specifications before asking suppliers to fill those gaps.

4. Set clear submission mechanics. Name the response channel, required file or form, contact, deadline, and process for asking and sharing clarifications. A structured form makes answers easier to compare than free-form submissions.

5. State the informational purpose plainly. Explain that the RFI creates no obligation to buy, responses are not offers, and the process will not produce an award. FAR Part 15 says an RFI has no mandatory format and that responses are not offers. That gives buyers room to design a response form around the information they need.

6. Explain how answers may be used. Responses may inform a later solicitation. Suppliers that do not respond remain eligible to participate. Put both points in the document so the purpose and limits are clear.

Harvard Kennedy School's Government Performance Lab recommends plain language, logical order, easy submission, and at least one month for responses. For a technical market inquiry, allow enough time for suppliers to prepare specific answers rather than send generic sales material.

Keep the commercial request at the level of pricing structure, not a line-item price schedule. Detailed pricing can make an information-gathering exercise feel like a competition and encourage defensive bids. Buyers may, for example, choose kitchen equipment for better food by first identifying the operational need; an RFI similarly clarifies the need before requesting a priced solution.

When a later RFP is possible, set the RFI schedule to leave room to review responses and translate relevant findings into neutral requirements. Keep an untouched copy of the issued RFI. It preserves the baseline for tracing how supplier answers informed the eventual specification.

Questions and Answer Formats That Compare

A useful RFI answer is easy to compare without turning the request into a bid. Give each question a unique ID and a required response type. That way, suppliers answer the same point in a consistent format, and the buyer can trace each response to a later specification decision.

Keep the questionnaire focused. A practical set is approximately 5 to 12 questions, a range the human-services RFI guide from Results for America suggests for keeping an RFI concise. Each question should address one decision or information gap. If an answer will not help shape the specification, remove the question.

Pair Every ID With a Response Type

For capability questions, require both a status and a delivery tag. “Yes” could mean standard functionality, configuration, a partner, custom work, or a roadmap item. Those answers have different implications for the specification, so capture the distinction in the form rather than relying on follow-up emails.

Ask about the commercial basis, not a line-item price. A supplier can describe whether cost is driven by users, devices, or a bundled service, and what changes the pricing structure. That gives the buyer useful context for later planning without requesting a bid.

Two Worked Questions for the PC Refresh

• Q3, capability: Can you support mixed laptop and desktop images across 40 sites? Answer yes, no, or partial, add the delivery tag, and cite the admin guide page that describes image deployment. Downstream use is specification refinement.

• Q7, commercial basis: What drives indicative cost, device, seat, or bundled service? Answer with the pricing structure and what pushes a buyer from one tier to the next. Downstream use is benchmarking.

Both questions produce answers that can be placed side by side. Neither asks for a bid.

A narrative answer that never says yes, no, or partial has not answered the question. Record it as incomplete rather than interpreting it for the supplier.

For example, government attachments often separate questions into questionnaires for technical environment, implementation and support, and assumptions. Use separate tabs in one form if that makes the response easier to complete. Allow a short custom note, but require suppliers to provide the stated response type so the answers remain comparable.

Keep commercial questions focused on pricing structure rather than line-item prices. For background on why the pricing unit matters, see this Freshservice licensing costs breakdown.

Pre-Send Gate and Response Scoring

Most RFIs fail before they're sent. The document mixes exploration with solicitation, asks for material you don't need, and collects answers you can't legally or practically use. A pre-send gate catches that while fixing it is still cheap.

Five Checks Before Release

1. Map every question to a decision. Write the procurement decision next to each ID. If no decision depends on the answer, cut the question.

2. Remove confidential asks you don't need yet. Don't request proprietary designs or detailed architectures at this stage. The Harvard Government Performance Lab guide on writing an RFI warns against asking inadvertently confidential questions and against setting an unreasonable response timeline.

3. Test the objective on an outsider. Give the draft to someone outside the project. If they need a call to understand it, rewrite until they don't.

4. Check the calendar. Allow at least one month for a reply, and publish at least three months before any planned RFP. Advertise the RFI widely, not just to suppliers you already know.

5. Get procurement or legal review. Have them read the disclaimer, disclosure terms, and future-solicitation language specifically. Those three paragraphs carry the legal weight of the file.

Add three fields most templates skip. A requirement-origin log records whether a line came from your team, one supplier, or several. An industry input versus buyer-owned field keeps that distinction visible as drafting moves on. A supplier-neutrality check flags any line only one known supplier could meet, so you generalize it or drop it. The NITAAC request for information template guidance sits within public-procurement practice that treats an RFI as market research which must not select or shortlist suppliers. Publish clarification questions, answers, and amendments in one place so every respondent works from the same file.

Hold or send: Send only when every question has a decision, a response type, and no single-bidder lock. Otherwise hold it, however urgent the timeline feels.

Score the Information, Not the Supplier

Say three PC suppliers all answer yes to imaging. One cites a current admin guide. One says partial because imaging is partner-delivered. One gives no source at all. Your matrix records three different evidence positions, which is useful for drafting the specification. It doesn't rank them, and it doesn't drop the third supplier from a later competition.

Never total the scores to crown a vendor. Never exclude a supplier for a low score or for silence. Those moves turn research into prequalification, and they're the fastest way to make the whole exercise challengeable. If you need genuine supplier assessment later, that's a separate step with its own criteria, covered in this supplier evaluation template and criteria weighting guide.

Log receipt timestamps. Preserve each original response exactly as received. Keep what a supplier asserted in a separate column from what you independently verified. That separation sounds fussy until audit asks which specification lines rest on evidence and which rest on a sales claim.

Move From RFI Answers to a Traceable Spec

The matrix isn't the end product. After scoring, write a short decision record. Note which supplier suggestions you accepted, which you rejected, and which you generalized so more than one firm could meet them. Note which lines risked a single supplier and what you changed. Note which requirements stay open to firms that never replied.

That record is what finance or audit asks for when the later solicitation differs from your first draft. One customer put it plainly. "When our CFO challenged the pick, the whole decision was one record. No week of digging through email, every requirement signed off, compliant and audit-ready." That's the standard to build toward, and it starts at the RFI, not at award.

Where Tools Earn Their Place

A spreadsheet handles a small RFI fine. Volume breaks it. When ten suppliers answer twelve questions each with evidence attached, someone has to read every cell, chase missing response types, and check whether a cited page supports the claim.

Automated procurement tools help at that point in specific ways. Our AI assistant asks clarifying questions and fills in missing requirements during intake, so gaps surface before you send anything. Vendor Responses lets you send invitations, track which suppliers have responded, and manage the forms in one place. Each answer gets read as yes, no, or partial with a source, never a vague mostly. Supplier files stay confidential to your organization.

The same habit applies whatever you buy. Name the requirement, demand evidence in a fixed format, and keep the source next to the claim. Category changes, traceability doesn't.

When you're ready to turn answers into a draft specification, this specification document template for building a verified requirement set gives you the structure to carry question IDs forward instead of starting from a blank page.

Test It on One RFI Before You Roll It Out

Don't rebuild your whole process on a promise. Run a bounded test on the RFI you're drafting now. In our free test run, you choose between end-to-end sourcing, where we draft the specification, scan the market, and compare options side by side, and gap analysis, where we flag gaps, single-bidder lines, and skipped items in a draft you already have. We reply with scope and timing, usually the same day. A non-disclosure agreement is signed before any file is shared with us, so confirm scope, timing, and confidentiality terms before you send a document.

Send the RFI only after the decision trail is designed, not after the inbox fills. If you build the record first, the answers have somewhere useful to land.

Start your next RFI with the decision record already designed, and let Procright draft the question set, track supplier responses, and read every answer as yes, no, or partial with its source attached. Bring one live RFI, choose end-to-end sourcing or gap analysis for a free test run, and you'll get scope and timing back usually the same day.