The Three-Task Test: A Scored Evidence Approach to UK Software Selection

Most software demonstrations are designed to reduce risk for the seller and increase it for the buyer. The interface is clean, the data is curated, and the presenter knows where every click leads. For a UK decision-maker, the question is not whether the software can perform under stage conditions. It is whether it can perform on a Tuesday afternoon with a half-migrated dataset, an absent specialist and a support queue that has not yet been tested.

The alternative is not to abandon demonstrations. It is to convert them into structured evidence. Give every shortlisted supplier the same three tasks, drawn from your own operations and deliberately imperfect data, and score the responses on one page. The method is unglamorous, repeatable and considerably more informative than a beauty parade.

Why polished demonstrations favour the presenter

A conventional demo tells you that the supplier can prepare for a meeting. That is not a trivial skill, but it is not the skill you are buying. The commercial risk sits in the exceptions: the duplicate record, the missing field, the permission that behaves unexpectedly, the report that depends on a manual workaround nobody mentioned. Sales engineers are adept at steering around these edges. A scripted task makes the edges part of the test.

There is also a governance argument. In 2026, UK buyers are under pressure to show that software selection was evidence-led, not personality-led. A scored test produces a defensible record for procurement, audit and, where relevant, the board. It does not eliminate judgement, but it gives judgement something firmer to stand on.

Designing three tasks with your own untidy data

Three tasks are enough to separate substance from theatre, provided each one maps to a real operational need. Resist the temptation to test every feature. Choose tasks that represent the work the software must do in its first ninety days.

A useful pattern is: one routine task, one exception task and one reporting or governance task. The routine task might be onboarding a new supplier record with incomplete bank details. The exception task might be resolving a duplicate customer entry where two departments disagree about the golden record. The reporting task might be producing a monthly exception report for a finance or compliance audience.

The data matters as much as the task. Use anonymised extracts from your own systems, including the inconsistencies that annoy your team. If you cannot share live extracts, construct a realistic sample with missing values, inconsistent formats and at least one record that breaks the obvious pattern. A supplier that can only work with tidy sample data is telling you something important.

Briefing suppliers without giving the game away

Brief suppliers in writing and give every shortlisted vendor identical instructions. State the three tasks, the time allowed, the data you will provide and the evidence you expect to see. Ask for the session to be led by the person who would implement the solution, not solely by a sales specialist. If a sales engineer attends, that is acceptable, but the implementation lead should answer questions about configuration and support.

Be explicit about what is not permitted. Suppliers should not use pre-built demonstration tenants that have been tailored to the tasks, unless they can show how that configuration would be reproduced in your environment. They should not substitute curated data for the sample you provided. They should not skip an error state because it is difficult to reproduce.

Send the tasks at least five working days ahead. This is not a trap; it is a fair test. You want to see preparation, not improvisation. But you also want to see how the supplier handles the parts of the data you deliberately left messy.

The one-page scorecard: what to score

A scorecard is only useful if it is short enough to be completed consistently by different assessors. One page, five or six criteria, and clear anchors for each score. A five-point scale is usually sufficient: one means absent or misleading, three means adequate with caveats, five means demonstrated with evidence and no material caveat.

Score the tasks on completion, accuracy and transparency. Completion asks whether the task was finished within the time allowed. Accuracy asks whether the result was correct against your expected outcome. Transparency asks whether the supplier explained workarounds, limitations and manual steps rather than hiding them.

Add two cross-cutting criteria: security evidence and support evidence. These should not be scored on presentation alone. Ask for written answers before the session and use the demonstration to probe them. Security questions should cover data residency, sub-processors, access control, encryption, incident notification and how the supplier supports UK GDPR obligations. For UK buyers, evidence of Cyber Essentials or equivalent controls can be relevant, but certification is not a substitute for understanding the specific data flows.

Support questions should cover severity definitions, response and resolution targets, escalation routes, maintenance windows, status communication and the named contact you would receive in the first month. A supplier that cannot describe its support model without referring to a sales colleague has not yet demonstrated a support model.

Comparing results without rewarding showmanship

Score immediately after each session, independently, before discussion. Use two assessors with different perspectives: one operational, one technical or risk-focused. Where scores diverge by more than one point, record why. The disagreement is often more useful than the average.

Do not compare suppliers on the charisma of the presenter. Compare the artefacts: the completed task, the error messages, the written security answers, the support commitments, the workarounds disclosed. If a supplier produced a clean result only by avoiding the messy data, score the avoidance, not the polish.

Finally, keep the scorecard with the tender record. In 2026, the ability to show that you tested software against your own conditions is a practical form of due diligence. It will not guarantee a successful implementation, but it will make the selection conversation considerably more honest.