Start with three problems, not a requirements list
Before you speak to anybody, write down the three problems that made you start looking. Not categories - problems. "Renewals get missed" is a problem. "Contract management" is a category, and categories are what let every vendor say yes.
Then, for each one, write what success would look like as a number or an observable event. This does two things: it gives you something to evaluate demonstrations against, and it lets a supplier tell you early if their product does not solve it.
If a supplier cannot tell you which of your three problems they solve least well, they either do not know their own product or are not being straight with you. Either is worth knowing before you sign.
Find the two or three things that are unusual about you
Every provider has a handful of things they do differently. A commercial model nobody else uses. A client with contractual reporting requirements far beyond the rest. A vertical specialism with its own compliance demands. Multiple trading entities. A shared arrangement with another provider.
These are what break implementations, and they are almost never on a requirements list because they are so familiar internally that nobody thinks to mention them. Identify them, write them down, and make each supplier show you specifically how they would be handled - not tell you, show you.
The questions that actually predict the outcome
- How long from contract to a technician doing real work in the system? Ask for the range, not the best case.
- Who does the implementation - the vendor, a partner, or us? If it is a partner, evaluate the partner as carefully as the software, because they are what you will experience.
- What does our ticket history migration include, and what does it cost? History drives knowledge features, and vendors vary enormously here.
- What is the total three-year cost including implementation, every module we need, and any per-connector or portal charges?
- What is the notice period, and what does data export look like on the way out? Ask for the format, not a reassurance.
- Which of our three problems does your product solve least well?
- Can we speak to a customer of roughly our size who implemented in the last year - not a reference from four years ago?
Run the demonstration, do not watch it
A vendor-led demonstration shows you the paths the product is best at. That is what a demonstration is for, but it tells you very little about your own workload.
Send your three problems and your unusual bits in advance and ask them to be demonstrated with your data or something closely resembling it. Then ask a technician from your team - not a director - to sit down and log an incident, book time and resolve it while you watch. How long that takes, and how much prompting it needs, predicts adoption more reliably than any feature list.
Work out the real three-year cost
Licence cost is the part everybody compares and frequently the smallest part of the difference. The full picture includes implementation, data migration, any tier upgrade you will need within two years, per-connector or integration licensing, client portal seats, training, and the internal time your own people will spend on the project.
Ask for all of it in a single document from each supplier, covering three years. Suppliers who resist this are telling you something useful. So are suppliers whose implementation estimate is conspicuously lower than everybody else’s - it usually reappears later as change requests.
Check the exit before you commit to the entrance
Ask precisely what you get if you leave: which entities, in which formats, at what cost, and how quickly. "You can export your data" is not an answer; a list of entities and file formats is.
This matters more in this market than most, because your client book, your contracts and your incident history are the business. A supplier who has made leaving expensive has told you how they intend to keep you.