The demo is a performance, and you are the intended audience
A vendor demo compresses months of configuration into forty scripted minutes, run by the person in the company best at running it, on data chosen to flatter the product. Nothing about that is dishonest; it is selection pressure, because the vendors that survived are the ones that demo well. The correction is to take control of the session: supply your own scenario in advance, ask the presenter to deviate from the script live, and insist on watching an administrator perform an everyday task (build a report, add a field, change a permission) at normal speed. Products that are easy to live with survive that treatment. Products that are merely easy to buy often do not.
Requirements documents describe the past. Working sessions test the future.
The standard requirements exercise produces a spreadsheet with hundreds of rows, most marked critical, assembled by asking every team what it needs. What that method captures is the current process, workarounds included, so the evaluation ends up rewarding whichever product best imitates the system being retired. A working session inverts this: put the people who will use the product in front of each candidate for half a day and have them attempt next quarter's real tasks rather than a feature checklist. Two or three sessions of that kind eliminate more candidates, faster, than any scoring spreadsheet, and they surface the objections of the users whose adoption will decide whether the purchase pays.
The number to compare is the five-year one
Subscription pricing has trained buyers to compare monthly rates, which is exactly the comparison vendors want. The cost that should decide the selection includes implementation and configuration, integration with the systems that feed and consume the data, migration of whatever the old tool holds, training and the productivity dip after go-live, the admin capacity needed to keep the product useful, and the cost of leaving when the tool is outgrown. Build that picture over five years for each finalist, and the cheapest licence is regularly not the cheapest system. If a vendor makes exit pricing or data export hard to establish, weight the difficulty as information rather than as an inconvenience.
Reference diligence beyond the happy customers
- Ask each vendor for a customer that stopped using the product within the past two years, and note whether the request is treated as reasonable or outrageous.
- Speak to a customer at your scale that went live twelve to eighteen months ago: recent enough to remember implementation, far enough in to know the product's ceiling.
- Ask references what they budgeted against what they spent, and which cost they failed to anticipate.
- Ask what they use the product for now versus what they bought it for; the distance between those answers is the honest capability statement.
- Find one user-community thread about the product's worst limitation and read the vendor's response to it.
Where an outside operator changes the outcome
The selection team is usually closest to the current tool's frustrations, which makes it a poor judge of whether those frustrations are the product's fault or the process's. Operators who have bought and retired several systems in a category ask a colder set of questions: whether the problem justifies a purchase at all, whether the organisation has the administrative capability the shortlisted products assume, and whether the favourite is winning on capability or on familiarity from someone's previous company. That challenge costs days. Choosing the wrong system and discovering it after migration costs quarters, and the gap between those two prices is the whole case for asking.
