SaaS proof of concept: a practical trial checklist

Start with a decision, not a feature tour

Name one workflow the purchase must support and the person accountable for it. Describe the starting state, the users involved and the output the team needs. For a support service, an example might be receiving a request, assigning it across two teams, escalating it and exporting the resulting history. This is an illustrative task, not a universal requirement. Ask the owner which failure would prevent adoption. Put that uncertainty first, before optional features and visual polish. Write down when the trial ends and who will decide what happens next.

Define what passing looks like before testing

Make each mandatory requirement observable. Replace “easy reporting” with a specified report that a named role can produce from the sample records without manual correction. Record the expected fields, permitted access and acceptable completion time chosen by your team. Keep must-have conditions separate from preferences: averaging several pleasant features must not erase a failed essential workflow. If the expected result is unclear, resolve it before the vendor starts. The acceptance rule belongs in the same worksheet as the test, so it cannot drift after a convincing demonstration.

Prepare a small but difficult sample

Use synthetic or appropriately authorised sample records. Include the ordinary case and the edge cases your workflow depends on: a duplicate record, a restricted attachment, a reassigned owner or a record from another time zone. Document the initial state and the steps used to create it. Ask for the edition, permissions and integration access that will be available after purchase. If the trial has extra privileges or a different tier, record that difference and retest the relevant steps in the intended configuration. A result from a different plan leaves a question open.

Let the future users run the task

Ask a likely operator to follow the written steps while another person records the result. Note vendor assistance, manual workarounds, elapsed time and any setup that occurred outside the session. Preserve the output, not just a success message: an exported file, a reconciled report or an audit entry gives the next reviewer something to inspect. Repeat a failed step after a change and retain both observations. A vendor statement and a result your team reproduced should occupy different fields in the trial record. Neither should silently stand in for the other.

Test handover and failure as part of the workflow

Remove a test user, hand ownership to another role and repeat the essential task. Interrupt an integration in the test environment using an agreed procedure, then check how the team notices and recovers. Export the sample and inspect it outside the service. Record limits you could not exercise safely or within the trial. A small trial cannot prove performance at every future scale; ask for a separate scale test or documented evidence where volume is a purchase condition. Use the exit guide for a fuller portability rehearsal.

Close with an evidence-based next step

List the mandatory conditions as demonstrated, unresolved or not met in this trial. Record the exact scope and date of each result, the reviewer and any next action. A conditional decision needs a retest with a named owner and deadline. Update the cost scenario with the setup work and assistance actually observed, while keeping estimates for untested work labelled. Preserve the original brief and the final decision together. Public transparency evidence can support the review, but it does not replace these product-specific observations or determine which service you should buy.

Your working checklist

The download contains these questions plus blank fields for your answer, evidence URL, review date, owner, due date and decision. Complete it in your own spreadsheet.

1. Decision

   Which uncertainty must this trial resolve before we buy?

   Ask for: Trial brief and decision owner.

2. Workflow

   What starting state, roles and output will every candidate use?

   Ask for: Repeatable task description.

3. Acceptance

   What observable result passes each mandatory requirement?

   Ask for: Acceptance criteria agreed before testing.

4. Sample

   Which representative records and edge cases are included?

   Ask for: Sample inventory and setup steps.

5. Plan

   Does the trial use the edition and permissions we would purchase?

   Ask for: Plan scope and access record.

6. Execution

   Can a future user complete the task, and with what assistance?

   Ask for: Observed steps, output and time.

7. Recovery

   What happens when a user leaves or a test integration fails?

   Ask for: Agreed failure and handover test.

8. Export

   Can another person read and reconcile the exported sample?

   Ask for: Export files and reconciliation.

9. Decision record

   Which conditions remain unresolved and who owns the retest?

   Ask for: Result, reviewer, action and deadline.

Source and scope

The GOV.UK Service Manual describes testing risky assumptions before committing to a solution. Our SaaS trial brief applies that general principle to a purchasing workflow; the tasks and acceptance checklist are our editorial suggestions.

GOV.UK: How the alpha phase works. Reviewed 2026-10-02.