Questions to Ask Software Vendors
Questions for evaluating a software vendor before signing, covering renewal pricing and exclusions, integration and migration cost, SLA and security detail, data export rights, and how much of the work lands on your own staff.
20 questions · each with the reason to ask it · conversation guide
The questions
Open any question to see why it works
- 01
What do customers usually buy this to solve, and where is it a poor fit?
Why ask it
Sales teams answer the first half readily and the second half rarely. A vendor who can describe a poor fit is describing a product with edges, which is more credible than one that suits everybody, and the description may turn out to match you.
- 02
Which of your customers closest to us in size and industry can I speak to?
Why ask it
Ask for a list you can choose from rather than accepting the single reference they nominate. The call worth having is with an organization your size that bought two years ago, not one that signed last quarter and is still in the honeymoon.
- 03
Which customers have left in the past year, and what did they move to?
Why ask it
Where departing customers went matters more than how many left: if they all moved to one competitor, that competitor does something this product does not, and you have just found the bid you are missing. Expect deflection, and note whether you get a name or only a category.
- 04
Can we run a pilot with our own data, and what does it cost?
Why ask it
A pilot on your own records exposes the gap between the demo and reality, which is where most disappointment comes from: odd field formats, duplicates, volumes nobody tested. Ask the price, since free pilots often come attached to a signature.
- 05
In that demo, what was configuration and what would need custom development?
Why ask it
Demos run in carefully configured sandboxes. Get the split in writing, item by item, because we can do that frequently means a services project priced separately from the license.
- 06
What does the integration with our existing systems actually consist of: a supported connector, an API, or a services project?
Why ask it
Integration is the largest hidden cost in most software purchases. Those three options differ by an order of magnitude in price, in timeline, and in who is responsible for keeping it working next year.
- 07
What are the API rate limits, and which objects are not exposed?
Why ask it
Limits and missing objects are where an integration quietly fails six months after launch. Ask for the published limits and the API documentation before signing rather than after.
- 08
How does data migration work, who performs it, and what usually goes wrong?
Why ask it
Migration is where timelines slip. Ask whether historical records come across, what happens to attachments and audit history, and how long the last three migrations of roughly our size actually took.
- 09
What will this cost in year three, and what caps the annual increase?
Why ask it
The first-year price is a negotiating position; the renewal is the real price. Ask for a written cap on annual increases and model the cost at the seat count you expect to have in three years.
- 10
What is not included in the quoted price?
Why ask it
Quotes routinely leave out sandbox environments, premium support, single sign-on, API access above a threshold, additional environments, and training. Ask for the exclusions as an explicit list, not a reassurance.
- 11
What does implementation cost, and do you deliver it or does a partner?
Why ask it
Implementation often costs a large fraction of the license, and partner delivery means two contracts and two escalation routes. Ask who is accountable if the partner underdelivers, and get that answer in writing.
- 12
How many of our people will this need, in which roles, and for how many weeks?
Why ask it
Vendors understate this because the cost lands on your staff rather than on the invoice. Ask for named roles and weekly hours, then put the same question to a reference customer.
- 13
What happens if we exceed our seat or usage limits mid-term?
Why ask it
Overage terms decide whether growth is a conversation or an automatic bill. Ask about mid-term true-ups, whether seats can be reduced at renewal, and what happens if your headcount falls.
- 14
What is in the SLA: what uptime, measured how, and what is the credit worth?
Why ask it
An uptime figure means little without the measurement window, the maintenance exclusions, and the size of the credit. Credits are usually small, so read the SLA as a statement of confidence rather than as compensation.
- 15
What was your worst outage in the past year, and is there a written postmortem?
Why ask it
Any vendor at scale has had one. Whether they will name it and point to a public writeup tells you how they behave on a bad day, which is the only day this will matter.
- 16
Which security certifications do you hold, what is in scope, and when was the last report issued?
Why ask it
A certification without scope and date is close to meaningless, since it may cover a different product line or be several years old. Ask for the current report under NDA and have someone read the exceptions section.
- 17
Who are your subprocessors, and where will our data be stored?
Why ask it
Subprocessors and storage locations determine your regulatory exposure and often trigger notice obligations in your own customer agreements. Ask for the list, how changes are announced, and whether you can object to one.
- 18
How do we get all of our data out, in what format, and how long does it take?
Why ask it
Exit terms are straightforward to negotiate before signing and impossible afterwards. Ask about the format, whether attachments and audit history are included, how long access continues after termination, and what an export costs.
- 19
How do upgrades and deprecations work, and can we defer one?
Why ask it
Forced upgrades break integrations and saved reports. Ask how much notice a breaking change carries, how long older versions stay supported, and whether a release can be deferred by a cycle.
- 20
Which roadmap items would you put in the contract, and who owns our account after the sale?
Why ask it
Roadmap slides are marketing until they appear in a contract with a date attached. The second half matters just as much: the attentive salesperson is usually replaced by someone carrying dozens of accounts.
Running a software evaluation
Practical guidance for the conversation itself
Before you talk to any vendor
Before you talk to any vendor
- Write down the five things the software must do and the two you would trade away. Without that list every demo looks impressive.
- Agree who makes the decision. Evaluations stall when nobody owns the choice, and vendors will find whoever is most likely to say yes.
- Collect your own numbers first: seat count, transaction volume, record counts, peak load. You cannot judge pricing or performance claims without them.
- Fix the date you need to be live and work backwards. It rules some vendors out before the first call.
Running the demo
Running the demo
- Send your own scenarios in advance and ask them to run those. A scripted demo only ever shows the product from its best angle.
- Have an end user do the clicking for ten minutes instead of watching a sales engineer navigate.
- Ask the same technical question of the sales engineer and later of support. Two different answers are informative in themselves.
- Write down every we can do that and ask whether it ships today, sits on the roadmap, or is a services project.
Checking references properly
Checking references properly
- Ask each reference what implementation actually took, in weeks and in their own staff time.
- Ask what they wish they had negotiated. Customers volunteer contract regrets far more readily than product complaints.
- Ask what support is like once the account is no longer new, and what happened at their first renewal.
- Find someone who left this vendor through your own network as well as asking the vendor, since no reference list will include them.
Contract points that matter later
Contract points that matter later
- A written cap on renewal increases.
- Data export rights, the format, and a defined period of access after termination.
- Notice periods for breaking changes and for subprocessor changes.
- An exit at the end of each term, without an auto-renewal that requires notice months in advance.
- Named implementation milestones and what happens if they slip.