Questions to Ask During Vendor Selection
Questions for evaluating suppliers before you sign, covering who does the work, what the price excludes, how data and exits are handled, and what their departing clients would say. Written for whoever runs the comparison.
The questions
Open any question for the note
Can you show me two projects like ours, including one that went badly?
Why ask it
Every vendor has a polished case study ready. Asking for the difficult one tests candour, and how they describe a project that went wrong tells you how they will describe yours if it does.
Who exactly will do the work, and are they your employees or subcontractors?
Why ask it
Pitch teams and delivery teams are often different people. Subcontracting is not a problem in itself, but it changes who you can hold to a deadline and whose insurance covers a mistake.
Who is our day-to-day contact, and what happens when they are away?
Why ask it
Ask for the named cover, not the concept of cover. Single-point relationships are the most common reason a working engagement stalls for a fortnight.
What is your timeline from signed contract to live, and what has to happen on our side?
Why ask it
The second half is the half that slips. Most missed launch dates trace back to client tasks nobody assigned, so get the list of what they need from you and who owns each item.
What does the quoted price include, and what will be billed separately?
Why ask it
Ask specifically about setup, data migration, training, integrations, support tiers and out-of-hours work. The gap between the quote and the first year's invoices lives in exactly these lines.
How do you price a change request, and who has to approve it?
Why ask it
A day rate with no approval step is how a fixed budget doubles. Ask to see the change control process rather than being told one exists.
Can we speak to three clients, including one who has left you?
Why ask it
Curated references say what you would expect. The former client is the informative call, and a vendor who cannot produce one is either very new or filtering hard.
Which clients have left in the past year, and why?
Why ask it
Some churn is normal and being able to describe it honestly is a good sign. Answers that blame every departure on the client's own failings describe a pattern rather than a coincidence.
Where do projects like this usually stall on the client side?
Why ask it
The best answer is specific, sign-off delays, missing data, an unavailable subject expert, and it doubles as a warning list for you. Vendors who say projects never stall have not run many.
What are your response and resolution commitments, and what is the remedy when you miss them?
Why ask it
A service level with no consequence is a statement of intent. Ask what was actually paid or credited to a client in the last year, which separates a real remedy from a clause.
Where is our data stored, who can access it, and what happens to it if we leave?
Why ask it
Ask for locations, subprocessors and the deletion timeline in writing. Vague reassurance about security here is the strongest single signal to slow the process down.
How would we get our data out if we terminated?
Why ask it
Ask what format, how long it takes, and what it costs. An export that arrives as a locked report rather than usable records is how a supplier stays after you have decided to leave.
What certifications, licences and insurance do you hold, and can we see the certificates?
Why ask it
The documents matter more than the logos on the website, because certifications lapse. Check the expiry date and the scope, since a certification can cover one product line and not yours.
How many clients does the team assigned to us support?
Why ask it
This is the question that predicts responsiveness once the contract is signed. A team already carrying twenty accounts will not treat yours as their most urgent one in month three.
What does support look like after go-live, and is it the same team?
Why ask it
Handover from implementation to support is where knowledge about your setup gets lost. Ask what is documented at handover and who you will be speaking to a year from now.
What training and documentation do we get, and who owns it afterwards?
Why ask it
Training that exists only as a session your staff attended once disappears with the first resignation. Written material you can keep and update is worth negotiating for explicitly.
What are the contract term, notice period and renewal terms?
Why ask it
Automatic renewal with ninety days notice is a two-year commitment with a one-year headline. Put the notice deadline in a calendar the day you sign.
Who owns the company, and how is the business funded?
Why ask it
Fair to ask of any supplier you will depend on. Recent acquisition or heavy outside investment often precedes price rises, product changes and staff departures during your contract.
What would make you turn down this project?
Why ask it
A vendor with real criteria will name something: a timeline that cannot work, a scope outside their competence. One who would take any work at all is telling you how they will handle a bad fit.
What do your clients most often complain about?
Why ask it
Every supplier has a known weakness, whether that is slow reporting, documentation or a thin support desk. Naming it is a sign they hear feedback; denying it means you will find out yourself.
Running a vendor comparison
Practical guidance for the conversation itself
Set criteria before you talk to anyone
Separate must-haves from preferences
Write the non-negotiables down first, in one page. Doing this after the demos means the criteria get shaped by whichever vendor presented most confidently.
Weight the criteria and score in isolation
Score each vendor as you finish with them, not in a group session at the end. Scores set side by side drift towards the most recent conversation.
Ask every vendor the same questions
Identical questions in the same order is the only way to get a comparison rather than a set of impressions. It also exposes who has not prepared.
Include the people who will use it
The team that will live with the tool notices things a buyer does not. Give them a session without the vendor present to say what they think.
Cost beyond the quoted price
- Implementation, configuration and data migration
- Training for the first cohort and for later joiners
- Integration work on your side, including your own staff time
- Support tier, out-of-hours cover and named contacts
- Licence growth as headcount or usage rises
- Annual uplift clauses and how they are capped
- Exit costs: data extraction, parallel running, replacement
Doing reference calls properly
Ask for a comparable client
Similar size, similar problem. A glowing reference from an organisation ten times your size tells you about their enterprise team, not the team you will get.
Ask what surprised them
More productive than asking whether they are satisfied. The answer is usually about timelines, an unexpected cost, or how much of the work fell to them.
Ask whether they would buy again today
It forces a verdict where general praise does not. Hesitation before a yes is worth following up on.
Listen for the lukewarm reference
A reference willing to take the call but reluctant to say much is giving you an answer. Ask directly what they would do differently.
Reasons to slow down
- A discount that expires at the end of the week
- A proposal with no named team, dates or deliverables
- Every question answered yes, including the ones that should trade off against each other
- Reluctance to name subcontractors or where data is held
- No former client they are willing to let you speak to
- Answers that change between the demo and the written proposal
- Contract terms sent only at signature, with legal review discouraged
Piloting before you commit
Define what a pass looks like first
Two or three measurable outcomes, agreed in writing with the vendor. Pilots without criteria almost always end in a decision made on how pleasant the vendor was to deal with.
Keep the scope small and real
One workflow, one team, real data if you safely can. Sandbox pilots with clean sample data hide exactly the problems a pilot exists to find.
Agree what happens if it fails
Who owns any configuration work, whether fees are refunded, and how the data is returned or deleted. Settling this at the start makes stopping a normal outcome rather than a dispute.