A feature comparison is the least useful part of a software evaluation, because every vendor can tick every box. The differences that matter show up months later, in how the system behaves under your specific conditions and how the supplier behaves when something is wrong.

You can probe both of those without being a specialist.

Test with your own data and your own case

A demonstration is a rehearsed performance on curated data. Insist on a trial with a real extract of your records, including the messy historical ones, and drive it yourself rather than watching.

Most systems handle the clean case. The question is what happens to the twelve percent of your data that has never quite conformed.

Ask what it is bad at

A supplier who cannot name a weakness either does not know their product or is not being straight with you. Good answers are specific: this is not suited to that volume, this workflow needs a workaround, this integration is on the roadmap rather than in the product.

That answer is more informative than any feature list, and the willingness to give it predicts a great deal about the relationship.

Find out how you would leave

Ask exactly how your data comes out, in what format, how complete it is, and what it costs. Then ask for a customer who has done it.

Exit terms are the clearest available proxy for confidence. A supplier who expects to keep you by being good makes leaving easy; one who expects to keep you by being difficult to leave does the opposite.

Talk to a customer they did not select

Reference customers are chosen for a reason. Ask instead for someone who implemented in your sector at your scale, or find a user independently. The question worth asking is not whether they are happy but what surprised them after signing.

Cost the whole thing, not the licence

Implementation, migration, integration, training, and the internal time to run it usually exceed the licence fee, often by a multiple. A cheaper product with a harder implementation is frequently the more expensive option.

Insist on a five-year total, with the assumptions written down and the growth path priced.

None of this requires technical depth. It requires asking questions whose answers are hard to fake, and treating evasion as data.

Written by the Global IT Solutions engineering team. Have a project this touches on?

Start a conversation