How many customers do you currently have at roughly our size, in our industry, and in our region?

Ask for counts, not logos. A vendor with two hundred customers and none at your scale will be learning on your account, and the logo wall in a deck usually includes pilots that never went into production.

Which parts of what we described do you do yourselves, and which parts are subcontracted or resold?

Resold components change who you escalate to and who carries liability when something breaks. Vendors rarely volunteer this, and it explains delays later that look inexplicable from your side of the relationship.

How long have you offered this specific product, and what release are your customers actually on?

A product where everyone runs the current release behaves very differently from one where half the base is stranded on an old version. The spread across versions tells you how painful their upgrades are in practice.

Who owns the company, and have ownership or senior leadership changed in the last three years?

A recent change of owner or a replaced leadership team often comes before price increases and thinner support. Much of this is a matter of public record, so an evasive answer carries information of its own.

How many people work on delivery for this product, and how many are dedicated to support?

Headcount is what the roadmap and the support promises are actually backed by. A company where the sales team outnumbers delivery and support combined tends to show it in response times within the first year.

Practical & Life Logistics

RFI Questions to Ask Vendors

Questions for a request for information sent to vendors early in a selection process, covering capability, subcontracting, certifications, data handling, support, and exit terms. Includes what to hold back for the RFP stage.

20 questions, each with the reason to ask it · includes a conversation guide

Open any question to see why it works.

1
How many customers do you currently have at roughly our size, in our industry, and in our region?
Ask for counts, not logos. A vendor with two hundred customers and none at your scale will be learning on your account, and the logo wall in a deck usually includes pilots that never went into production.
2
Which parts of what we described do you do yourselves, and which parts are subcontracted or resold?
Resold components change who you escalate to and who carries liability when something breaks. Vendors rarely volunteer this, and it explains delays later that look inexplicable from your side of the relationship.
3
How long have you offered this specific product, and what release are your customers actually on?
A product where everyone runs the current release behaves very differently from one where half the base is stranded on an old version. The spread across versions tells you how painful their upgrades are in practice.
4
Who owns the company, and have ownership or senior leadership changed in the last three years?
A recent change of owner or a replaced leadership team often comes before price increases and thinner support. Much of this is a matter of public record, so an evasive answer carries information of its own.
5
How many people work on delivery for this product, and how many are dedicated to support?
Headcount is what the roadmap and the support promises are actually backed by. A company where the sales team outnumbers delivery and support combined tends to show it in response times within the first year.
6
What does a typical implementation take, in weeks, and what was your longest one this past year?
The typical figure is marketing. The longest one is the useful number, and the reason it ran long is usually structural rather than one difficult customer, so ask what caused it.
7
For each requirement we listed, can you meet it today, is it on the roadmap with a date, or not at all?
Forcing three buckets stops the response arriving as an undifferentiated wall of yes. Treat anything placed on a roadmap without a named quarter as unavailable when you score vendors against each other.
8
What drives your pricing, and what typically gets billed on top of the headline number?
At this stage you want the shape of the pricing, per seat, per transaction, per site, per gigabyte, rather than a quote. The add-on question matters more, because implementation, training, sandbox environments, and premium support are where budgets break.
9
Which certifications or audits do you hold, and can you send the most recent report with its scope?
A certification claim and a current report are different things, and reports expire. Scope is where this usually falls apart, since a certificate covering a different product line than the one you are buying is common.
10
Where would our data be stored and processed, and which subprocessors would have access to it?
Storage location determines which laws apply and which internal reviews you will have to pass. A vendor who cannot produce a subprocessor list has not been asked for one by a serious buyer before.
11
What has your uptime been over the last twelve months, and where is that figure published?
Where it is published matters more than the number. A vendor with a public status page and a visible incident history can be held to a figure, while one quoting availability from a slide cannot.
12
How do you handle security incidents, and have you had a reportable breach in the last three years?
The process answer matters less than the actual history. A vendor claiming no incidents at all is either very new, very lucky, or not counting the same events you would count.
13
Which of the systems we listed do you already integrate with, and who builds and maintains those connectors?
An integration that exists as a partner-built connector or as a professional services project is not the same as one the vendor maintains. Ask specifically who fixes it when the other system ships a breaking change.
14
How does support work: hours, channels, response commitments, and who answers first?
These four are separable, and the weak point is nearly always the first responder. A front line that can only escalate on the vendor's own schedule is where most support frustration actually originates.
15
What is your standard contract length, and what notice do we have to give to leave?
Term and notice period together decide how much leverage you hold later. Automatic renewal with a ninety-day notice window is common and quietly removes your chance to renegotiate at all.
16
If we leave, how do we get our data out, in what format, and what would that cost?
Ask about leaving before you sign, because that is the only moment you have leverage over the answer. Format, timeline, and any extraction fee should appear in writing rather than as something to be worked out later.
17
Who would our day-to-day contact be, and how many other accounts do they carry?
The named person and their account load predict your real service level better than any commitment in the document. Someone carrying forty accounts will not know your configuration when you call.
18
Which three customers most like us could we speak with, and could we also speak with one that left?
Asking for comparable customers filters out the flagship reference every prospect gets shown. The departed customer is the part that separates confident vendors from careful ones, and a refusal is worth recording even if you accept it.
19
What kind of customer are you a poor fit for?
A vendor who can describe where their product does not work has the self-knowledge to be trusted elsewhere in the response. One who insists they suit everybody will discover mid-implementation that you were the exception.
20
What went wrong on a recent implementation, and what changed as a result?
Few sales teams have a prepared answer for this, which is why it is worth asking. Listen for whether a process actually changed, because that is the difference between a lesson and an anecdote.

Running an RFI That Produces Comparable Answers

Practical guidance for the conversation itself.

Using an RFI rather than an RFP

An RFI is for narrowing a field and learning what the market can do. Keep firm pricing, service levels, and contract terms for the RFP, where the answers can be made binding.
Send identical questions in the same order and require the same format. Free-form responses are nearly impossible to compare and quietly favor whoever has the largest proposal team.
Include your own context: rough scale, existing systems, timeline, constraints. Vendors given nothing to work with write generic answers, which wastes both sides' time.
Set a word limit per answer. The limit is what forces specificity, and it also tells you who can follow instructions.
State plainly that this is not a commitment to buy, and say when you expect to move to the next stage. Vendors who know the timeline invest proportionately.

Reading the responses

Answers that restate the question

A response that reuses your wording without adding a number, a name, or a date has not answered you. Score it as a non-answer rather than a partial one, or you will end up rewarding fluency.

Two voices in one document

Capability answers usually come from marketing and delivery answers from operations. Where the two halves of a response disagree in tone or detail is exactly where implementation surprises tend to come from.

Roadmap language

Planned, on the roadmap, and in beta are three different states, and in a buying decision all three mean not available. Ask for a quarter, then ask a reference customer whether the last roadmap promise arrived on time.

Length as evidence

A two hundred page response is not a strong one. Long documents usually indicate a dedicated proposal team, and that team is the part of the company you will never deal with again after signing.

Follow up before you shortlist

Send one round of clarifying questions on the three weakest answers, and hold every vendor to the same deadline.
Verify anything you would rely on: certification dates, insurance limits, published uptime, named subprocessors.
Ask references about the claims the vendor answered well rather than badly. Those are the claims you would be depending on.
Ask each reference what they would do differently in their own implementation. It reliably produces more usable detail than asking whether they are satisfied.
Note who missed the deadline, who ignored the format, and who never replied. Behavior during an RFI predicts behavior during a project.

What to hold back for the RFP

Firm pricing tied to your actual volumes, with a rate card for anything billed hourly.
Service level commitments with remedies attached, because a target with no consequence is only a preference.
An implementation plan naming roles on both sides, including what you are obliged to provide and by when.
Contract terms: liability caps, indemnities, notice periods, price escalation limits, and data deletion on exit.
Security artifacts, including penetration test summaries and a completed copy of whatever questionnaire your own security team requires.

The questions

How many customers do you currently have at roughly our size, in our industry, and in our region?

Which parts of what we described do you do yourselves, and which parts are subcontracted or resold?

How long have you offered this specific product, and what release are your customers actually on?

Who owns the company, and have ownership or senior leadership changed in the last three years?

How many people work on delivery for this product, and how many are dedicated to support?

What does a typical implementation take, in weeks, and what was your longest one this past year?

For each requirement we listed, can you meet it today, is it on the roadmap with a date, or not at all?

What drives your pricing, and what typically gets billed on top of the headline number?

Which certifications or audits do you hold, and can you send the most recent report with its scope?

Where would our data be stored and processed, and which subprocessors would have access to it?

What has your uptime been over the last twelve months, and where is that figure published?

How do you handle security incidents, and have you had a reportable breach in the last three years?

Which of the systems we listed do you already integrate with, and who builds and maintains those connectors?

How does support work: hours, channels, response commitments, and who answers first?

What is your standard contract length, and what notice do we have to give to leave?

If we leave, how do we get our data out, in what format, and what would that cost?

Who would our day-to-day contact be, and how many other accounts do they carry?

Which three customers most like us could we speak with, and could we also speak with one that left?

What kind of customer are you a poor fit for?

What went wrong on a recent implementation, and what changed as a result?