The risk is not vendor selection. It is what comes after signature.
Most vendor evaluations concentrate on the wrong period. The comparison happens across features, licence prices and implementation quotes, but the money and the pain sit in years two to five: the integration nobody scoped, the price uplift at first renewal once switching has become impractical, the module you were told was on the roadmap that arrives two years late, and the professional-services dependency that turns every change into an invoice. A vendor decision is an execution-dependency decision. The contract you sign determines how much negotiating power you will have at every future point of friction.
Blind spots that recur at the shortlist stage
- The demo is a curated environment. Nobody on the evaluation team has used the product configured with your data volumes, your permissions model and your edge cases.
- Reference calls are supplied by the vendor, which means they are sampled from the satisfied end of the customer base and often from organisations unlike yours.
- The scoring matrix was weighted after preferences formed, so the weights encode the answer the team already wanted.
- Licence price is compared line by line while migration cost, internal effort, training and exit cost are left as footnotes.
- The salesperson making the promises will have no role in delivery, and the roadmap commitments that shaped the decision appear nowhere in the contract.
- Requirements were written around the incumbent process, so the evaluation rewards the vendor that best replicates what you already do, including the parts that do not work.
Six questions worth an awkward meeting
Ask each finalist what their average price movement is at first renewal for customers of your size, and watch whether the answer is a number or a deflection. Ask which customers of comparable complexity have left them in the past two years, and whether you may speak to one. Ask what a full data export looks like at termination: format, completeness, cost, and how long it takes. Ask which parts of the demo relied on functionality that is roadmap rather than release. Ask who owns the configuration IP that will be built during implementation. And ask your own team a harder one: if the preferred vendor were removed from the shortlist tomorrow, would the second choice genuinely be unacceptable, or merely unfamiliar?
What deserves a genuine stress test before the contract
Three things repay proper testing. First, the total cost model: build the five-year figure including internal effort, integration, uplifts and exit, and see whether the ranking of the finalists survives. It frequently reverses. Second, the failure scenario: assume the implementation runs six months late and the executive sponsor has left. Which contract clauses protect you, and which protect the vendor? Third, the reference base you were not shown: former customers and mid-implementation customers describe a different product from the ones on the vendor slide, and finding two of them is usually possible within a week.
The pattern independent reviewers keep finding
When operators who have run comparable selections review a shortlist decision, the most common finding is not that the wrong vendor won but that the requirements were never seriously contested, so the whole evaluation optimised for the wrong things: replicating the current process, satisfying the loudest stakeholder, or minimising the visible price rather than the five-year cost. The second most common finding is contractual: the terms as drafted give away the leverage the buyer will need at renewal. Both findings are cheap to act on before signature and nearly impossible to act on after.
