Making the decision once the trial is over
The hardest outcome to act on is a trial that produced no clear winner, which is the most common outcome.
Trials rarely produce a decisive result. Two products both work, each is better at something, and the group is split. At this point the decision is usually made by whoever is most senior or most tired.
Go back to what you wrote at the start
The pass conditions were written before anyone had a preference. Read them again and check them off literally. A trial involving time-tracker evasion should test the awkward cases rather than the happy path; read more provides a concrete vendor example to design those checks around.
Often this resolves it immediately: one candidate failed something that was agreed to be essential, and the group has been discussing other things for a week. Where both pass, you have a genuine choice rather than an unresolved evaluation, which is a much easier position.
Weight the things that are hard to change
When candidates are close, prioritise the structural over the featural. Data model, permissions, export, pricing model, and the vendor's viability are difficult or impossible to change after purchase.
Missing reports, interface annoyances and absent integrations are the things most likely to change on their own, in your favour, over the life of the contract.
Where two candidates are genuinely comparable, take the one that is cheaper to leave. It is the only part of the decision that protects you from being wrong.
Ask what the reluctant person is worried about
In a split group, the dissenter usually has a specific concern that has not been articulated because the conversation is about totals.
Asking directly — what specifically worries you about this — surfaces it, and it is frequently something concrete that can be checked with one question to the vendor. It also matters for adoption: an internal sceptic whose concern was heard behaves very differently afterwards from one who was outvoted.
Write the decision down, with the reasons
A short record: what was chosen, against what alternatives, on what grounds, and what the known trade-offs are.
This takes fifteen minutes and pays back repeatedly. It answers the question a year later about why this was chosen. It gives the review something to check against. And it records what you knowingly accepted, so that a known limitation surfacing later is not mistaken for a mistake.
Say no properly to the others
Tell the unsuccessful vendors promptly, and tell them why in one sentence. It costs nothing, it is decent treatment of people who spent time on you, and it keeps a relationship you may need — the winner might not work out, and the runner-up is who you will call.
Set the review date now
Put a date twelve months out in the calendar to review whether the decision worked, measured against the success criteria written at the start. Booked now, it happens. Booked later, it does not.
When a trial uses real personal data, ICO guidance on data protection impact assessments is a useful independent reference.