RFI Template (Free, Word): Request for Information

How to adapt this RFI to your category (delete this note
before sending)

This template is written for a generic software or technology
purchase. To fit it to yours:

1. Replace every [square-bracket placeholder]. Search the document for
   “[” to find them.
2. Describe your problem in Section 3 in your own words and fill in the
   scope table. Without your user numbers, systems and data volumes,
   vendors can’t give useful answers or indicative prices.
3. Replace [Key need 1] to [Key need 5] in Section 8.3 and Section 9
   with the things the product must do for you. For a CRM, that might be
   pipeline management, email and calendar sync, and service cases. For a
   service desk tool, incident and request workflows and a self-service
   portal. For an ERP system, multi-entity accounting, purchasing and
   inventory.
4. Add two or three questions where your category’s decision is really
   made. For a security product, expand Section 8.5. For an AI product,
   expand question E7 to cover where prompts and outputs are stored and for
   how long.
5. Delete questions whose answers won’t change who goes on your
   shortlist. Every question you keep is work for the vendor and for your
   reviewers.
6. Have your procurement office or legal counsel check Section 4 before
   you send it. This matters most for public bodies, because the rules on
   RFIs, public records and vendor contact vary by jurisdiction.
7. Delete this note and the italic instructions addressed to buyers.
   Keep the italic notes addressed to respondents.

1. Purpose of this RFI

[Organization name] is issuing this request for information (RFI) to
learn about [software category, e.g., “customer relationship management
(CRM) software”] and the vendors that provide it.

We are at an early stage. We want to understand the products and
approaches available, how they are usually implemented and priced, and
which vendors work with organizations like ours. We will use responses
to:

• improve our understanding of the market and refine our
  requirements;
• estimate the budget and internal effort a project would need;
• decide whether to go ahead and, if we do, which vendors to invite to
  a later stage, such as a request for proposal (RFP) or product
  demonstrations.

This RFI is for information and planning only. It is not a request
for proposal or a request for quotation. Section 4 explains what it does
and does not commit us to.

2. About our organization

Buyers: give vendors enough context to tailor their answers. A
short paragraph and the table below are enough.

[Organization name] is a [type of organization, e.g., “regional
healthcare provider” or “business-to-business software company”] based
in [location]. We [one sentence on what the organization does and who it
serves].

3. Background and
the problem we’re exploring

3.1 Current situation

[Describe how the work is done today: the systems, spreadsheets or
manual processes in use, roughly how long they’ve been in place, and who
uses them.]

3.2 The problem

[Describe the problems you want to solve, in business terms. For
example: “Sales and service teams keep customer records in separate
systems, so no one has a complete view of an account,” or “Our current
system reaches end of support on [date].”]

3.3 What we want to achieve

[List three to five outcomes. For example: “One customer record
shared by sales and service” or “Month-end reports without manual
spreadsheet work.”]

• [Outcome 1]
• [Outcome 2]
• [Outcome 3]

3.4 Scope as we understand
it today

Buyers: these figures help vendors give realistic answers and
indicative pricing. Estimates are fine; mark them as estimates.

3.5 Questions we haven’t
settled

Buyers: list the open questions you want the market to help you
answer, so vendors address the questions you actually have.

• [e.g., Whether a cloud service or a self-hosted product suits us
  better]
• [e.g., Whether one platform can replace several of our current
  tools]
• [e.g., Whether to replace our current system or upgrade it]

4. What this RFI is and is
not

Buyers: check this section with your procurement office or legal
counsel before you send it, especially if you are a public body. The
rules that apply to RFIs, confidentiality and public records vary by
organization and jurisdiction.

No commitment to buy. This RFI is issued for
information and planning purposes only. It is not a request for
proposal, a request for quotation or an invitation to submit offers.
[Organization name] is not obliged to issue an RFP or to buy anything,
from any respondent.

No contract. Responses to this RFI are not offers,
and no response will be accepted to form a contract. Any purchase would
follow a separate process and a written agreement signed by both
parties.

Indicative information only. We will treat pricing,
timelines and similar information in responses as indicative and use it
for planning only. It will not bind the respondent.

Costs borne by respondents. Each respondent bears
its own costs of preparing and submitting a response, and of any
follow-up such as meetings or demonstrations. We will not pay for
information provided in response to this RFI.

Future eligibility. [Choosing not to respond to this
RFI will not, by itself, exclude a vendor from any later RFP.]
Buyers: delete or change this if your rules differ.

Our confidentiality. The information about
[Organization name] in this RFI is confidential. Use it only to prepare
your response, and share it only with employees and partners who need it
for that purpose. [Optional: Respondents must sign the attached
non-disclosure agreement before responding.]

Your confidentiality. Mark any part of your response
that is confidential or commercially sensitive, but don’t mark the whole
response. We will take reasonable steps to protect marked information,
share responses only with the people involved in this review [and our
advisers], and not disclose one respondent’s confidential information to
another. [Public bodies: replace this paragraph with your jurisdiction’s
public-records wording, including whether responses may be disclosed if
the law requires it.]

Use of responses. We may use what we learn from
responses to plan our project and write requirements for any later RFP.
We will keep responses for our records and will not return them.

Changes and cancellation. We may change the
timeline, issue written addenda or cancel this RFI at any time. We will
send any change to every recipient [or: post it at [location]].

5. Instructions and response
format

1. Follow our structure. Answer the questions in
   Section 8 in order, using our question numbers (A1, A2 and so on). If a
   question doesn’t apply to you, say so and explain why.
2. Complete the capability checklist in Section 9 and
   the response cover sheet in Section 10. Put the cover sheet at the front
   of your response.
3. Be specific. We prefer short, direct answers to
   marketing copy. Keep each answer to [300] words or fewer unless the
   question asks for a list or a table.
4. Say who provides what. If any part of an answer
   depends on a partner, reseller or third-party product, name it.
5. Separate today from the future. Describe a feature
   as available only if it is in a generally available release today. Mark
   anything in beta, preview or on the roadmap, and give an expected
   release date.
6. Length and attachments. Keep the main response to
   [25] pages or fewer, excluding attachments. You may attach material such
   as [a product overview or a security summary], but don’t answer a
   question only by pointing to an attachment.
7. How to submit. Email your response as [one PDF or
   Word file] to [email address] with the subject line “RFI [reference]
   response – [Vendor name]” by the deadline in Section 6. [Or: upload it
   through [portal name and URL].] We will confirm receipt by email.
8. Late responses. [We may decline to review responses
   received after the deadline.]
9. Intent to respond (optional). Please tell the
   contact in Section 7 by the date in Section 6 whether you intend to
   respond.

6. Timeline

Buyers: the dates below are an example schedule that gives
vendors two weeks to respond. Adjust them to suit your purchase and your
organization’s rules.

All dates after the response deadline are indicative and may
change.

7. Contact point and
rules of communication

All communication about this RFI must go through one contact:

• Name: [Name]
• Title: [Title]
• Email: [Email address]
• Phone: [Phone number, or “Please use email”]

These rules apply from the issue date until [the decision on next
step / a date]:

• Send questions in writing to the contact above by the question
  deadline in Section 6.
• We will answer in writing and send every question and answer to all
  recipients, without naming the vendor who asked. If your question would
  reveal confidential information about your product, say so, and we will
  decide whether we can answer it privately and still be fair to other
  respondents.
• Do not contact other employees, board members or advisers of
  [Organization name] about this RFI. Existing business contacts on other
  matters can continue as normal. [Contact outside these rules may lead us
  to set a response aside.]
• Only written addenda from the contact above change this RFI. Spoken
  comments from any of our staff do not.
• We may contact respondents to clarify their answers or to arrange
  follow-up calls or demonstrations.

8. Questions for respondents

Answer every question that applies to you. Where a question
refers to “our needs” or “our scope”, see Section 3.

8.1 Company profile

A1. Give your company’s legal name, headquarters
location, year founded and ownership (for example, publicly listed,
privately held, investor-backed or part of a larger group).

A2. How many people do you employ in total, and how
many work in product development, customer support and implementation
services?

A3. Where are the staff who would sell to, implement
for and support us? Do you have a presence in [our countries or
regions]?

A4. How long has the product you’re describing been
generally available, and roughly how many organizations use it
today?

A5. Describe any recent or planned acquisition,
merger, change of ownership or end-of-life announcement that affects
this product.

A6. If we go ahead to an RFP, could you provide
evidence of financial stability, such as audited accounts or a credit
report?

8.2 Product or service
overview

B1. Summarize the product or service you would
propose for the needs in Section 3, in no more than [one page]. Name the
editions, modules or tiers involved.

B2. What types and sizes of organization is the
product designed for? Where is it not a good fit?

B3. Which deployment models do you offer (for
example, multi-tenant cloud, single-tenant hosted or installed on our
own infrastructure)? Which would you recommend for us, and why?

B4. Which parts of the solution do you build and
operate yourselves, and which come from partners or third parties?

B5. Describe your roadmap for the next [12 to 24]
months where it touches our needs. Which items are committed, and which
are under consideration?

8.3 Capabilities against our
needs

Buyers: replace the placeholders with the key needs from Section
3. Keep the list short, and use the same list in Section 9.

C1. For each need below, explain how your product
meets it, and say whether that is standard functionality, configuration,
custom development, a partner product or a roadmap item.

• [Key need 1, e.g., “Track every customer interaction across sales
  and service in one record”]
• [Key need 2]
• [Key need 3]
• [Key need 4]
• [Key need 5]

C2. Walk us through how a user would complete [our
most important scenario, e.g., “a new customer order, from quote to
invoice”] in your product, step by step.

C3. What can our own administrators configure
without code (for example, fields, forms, workflows, approval rules and
reports), and what needs your team, a partner or a developer?

C4. What reporting and analytics are included? What
needs an add-on module or a separate tool?

C5. What practical limits apply, for example to
users, records, storage, file sizes or transaction volumes? What happens
if we exceed them?

C6. How do users work on mobile devices: a native
app, a mobile browser or both? Do you publish an accessibility
conformance report, and which accessibility standard and level does the
product meet (for example, WCAG 2.1 Level AA)?

C7. Based on what you know of our situation, what
are the main limitations or risks of your product for us?

8.4 Technical and integration

D1. Where would our data be hosted and processed?
Name the hosting provider and the countries or regions available, and
say whether we can choose.

D2. Which integration methods do you support (for
example, REST APIs, webhooks, file import and export, and prebuilt
connectors)? Is your API documentation publicly available?

D3. Do you have prebuilt integrations with [our
systems, e.g., our ERP, identity provider and HR system]? Who builds,
supports and updates them?

D4. Do you support single sign-on through SAML 2.0
or OpenID Connect, multi-factor authentication and automated user
provisioning (for example, SCIM)? How are roles and permissions
managed?

D5. How would you migrate our data from [current
system]? Which tools do you provide, and what work would fall to us?

D6. Can we export all of our data, including
attachments and history, at any time and at the end of the contract? In
which formats?

8.5 Security and compliance

E1. Which independent security reports or
certifications cover this product (for example, a SOC 2 Type II report
or ISO/IEC 27001 certification)? Give the date of the most recent report
or audit, and say whether you can share it under a non-disclosure
agreement.

E2. How is our data protected in transit and at
rest? What options do we have for managing encryption keys?

E3. How do you detect and respond to security
incidents, and how quickly would you notify us of an incident that
affects our data?

E4. Will you sign a data processing agreement?
Describe your list of sub-processors and how you support [the privacy
laws that apply to us, e.g., GDPR or US state privacy laws].

E5. Describe your status against [the sector
frameworks that apply to us, e.g., HIPAA, PCI DSS or FedRAMP], or say
that they do not apply to your product.

E6. Describe your backup and disaster recovery
arrangements, including the recovery point and recovery time objectives
you commit to and how often you test them.

E7. Does the product include AI features that
process our data? If so, which models or providers do they use, is our
data used to train models that serve other customers, and can we turn
the features off?

8.6 Implementation and
support

F1. Describe a typical implementation for an
organization of our size and scope: the phases, the main tasks and a
typical duration range.

F2. Who would deliver the implementation: your
company, a partner or both? If partners, name those that work in [our
region or industry].

F3. What staff and time would we need to commit
during implementation, and in which roles?

F4. Describe your support model: hours, channels,
severity levels and response-time targets. What is included as standard,
and what costs extra?

F5. What availability do you commit to in your
service level agreement? How is it measured, and what remedies apply if
you miss it?

8.7 Pricing model (indicative
only)

We are asking for indicative pricing to help us plan a budget. It
is not a quote, it will not bind you, and we will not treat it as an
offer. Base it on the scope in Section 3.4 and state your
assumptions.

G1. Describe your pricing model. Which metric drives
the price (for example, per named user, per module, by usage or a flat
subscription), and how do you define it?

G2. Complete the table below with indicative ranges
for our scope.

G3. What is included in the subscription or license,
and what is charged separately (for example, extra environments, premium
support, additional storage or API usage)?

G4. Which contract terms do you usually offer, and
how are prices set at renewal?

G5. What else commonly affects the total cost over
[three to five] years for an organization like ours?

8.8 References and customer
base

H1. Describe up to [three] customers similar to us
in size, industry or scope. For each, give the industry, approximate
size, what they use the product for and when they went live. You may
leave out their names at this stage, and you may attach a case
study.

H2. If we go ahead to an RFP, could you provide [two
or three] references we can speak to, ideally organizations that moved
from [our current system or approach]?

9. Capability checklist

Buyers: replace rows K1 to K5 with the key needs from Section
8.3, edit or delete the other rows, and mark each row Must-have or
Nice-to-have.

Respondents: complete the Response and Comment columns for every
row.

Use one of these response codes for each row:

• Yes: available today in a generally available
  release, as standard or through configuration.
• Partial: partly met, or met only through custom
  development, a partner product or a workaround. Explain in the Comment
  column.
• Roadmap: not available today but planned. Give the
  expected release date in the Comment column.
• No: not available and not planned.

10. Response cover sheet

Respondents: complete this sheet and put it at the front of your
response.

Confirmation. We have read Section 4 of this RFI. We
understand that this RFI is not a commitment to buy, that our response
is not an offer and will not form a contract, and that we bear our own
costs of responding. To the best of our knowledge, the information in
our response is accurate on the date above.

End of RFI.