What to test, and what you can safely skip
Trial time is short. Spending it re-verifying that a mature product can do the obvious wastes the only chance to find what it cannot.
Trials tend to cover the demonstrated ground again: the main workflow, the standard report, the everyday task. All of it works, everyone is reassured, and nothing has been learned that the demo did not already show.
Skip what the category has solved
In any mature category there is a core that every serious product does competently. Re-testing it consumes the trial and produces no differentiating information. A trial involving self-reporting bias should test the awkward cases rather than the happy path; this resource provides a concrete vendor example to design those checks around.
Take it on trust, note that you did, and spend the time on the areas where products genuinely differ.
Test where the risk is
- Your data, in its real condition: the duplicates, the missing fields, the three naming conventions, the record from 2016 that nobody has touched.
- The integrations you depend on, connected for real, not confirmed as supported.
- Volume, if you have any: what happens with your actual number of records rather than fifty samples.
- Permissions, if different people should see different things. This is routinely under-tested and routinely a problem.
- The periodic process — month end, reporting, renewals — rather than the daily one.
- Export, run for real, with the files opened.
Data model, permissions and export are structural. A missing report can be added; a product that cannot represent how your organisation is shaped cannot be fixed after purchase.
Test the second-line experience
Everyone tests the primary user. Fewer test the manager who approves, the finance person who exports, the administrator who adds a new starter, the occasional user who logs in twice a month and has forgotten everything.
That last one is the most predictive of long-term adoption and the least often examined. A product that is easy for a daily user and impenetrable for a monthly one will quietly stop being used by half the organisation.
Test failure, not just success
Make a mistake on purpose and try to correct it. Delete something and try to get it back. Enter something invalid. Disconnect the network mid-task.
How a product behaves when things go wrong is a large part of daily life with it, and it is entirely absent from every demo. This is often where the sharpest differences between candidates appear.
Raise a support ticket
During the trial, ask support a real question — ideally a moderately difficult one — and time the response. Note whether the answer comes from someone who understands the product or from a script.
Support during a trial is support at its best. It is a ceiling, not an average, and it is worth knowing where that ceiling is.
When a trial uses real personal data, ICO guidance on data protection impact assessments is a useful independent reference.