The demo works. Is the software ready for approval?

“Order processing must work” leaves room for several interpretations. One person means saving a record. Another expects the correct customer price. A warehouse colleague needs an unambiguous instruction to prepare the goods. Agreeing on an outcome before development helps those expectations meet.

The GOV.UK Service Manual describes acceptance criteria as outcomes used to check whether a service meets a user need. This is a useful design principle for business software too. It does not determine the contractual acceptance arrangements for your project.

Imagine a fictional wholesaler introducing a new order feature. A meaningful outcome would be that a sales employee can confirm an order at the agreed customer price, after which the warehouse receives exactly the confirmed quantities. “Add a confirmation button” describes a feature; the outcome explains what the business needs to achieve with it.

Keep the criterion understandable to the people approving the work. You can reference detailed rules where necessary, but the central decision should not depend on someone interpreting a technical specification during the review meeting.

Start with the normal journey, then add situations where an error would matter. Involve the colleagues who regularly deal with unusual orders or missing information. Their experience helps identify what a polished demonstration can leave out.

For the fictional wholesaler, an initial set might include:

Situation	Evidence to look for
Existing customer with an agreed price	The confirmed order uses the correct agreement and quantities.
Employee without confirmation authority	The employee cannot make the order final through another route.
Quantity changed before confirmation	The warehouse receives the version that was finally confirmed.
Warehouse handover fails	The employee can recognise the problem and identify who follows it up.

This is a starting point, not a complete test plan. Financial consequences, sensitive information and actions that are difficult to reverse deserve more scrutiny than a minor wording change. Ask the technical team which rules are covered by automated checks and where other evidence is still needed.

Avoid turning the exercise into a long list of easy checks simply to produce an impressive pass rate. A single unresolved problem can matter more than dozens of successful demonstrations of low-risk behaviour.

Ask a colleague to carry out a recognisable piece of work. Provide the customer request and relevant information without prescribing every click. Watch where the person hesitates, searches for information or needs help. Those observations reveal whether the proposed design supports the work.

Agree what support is part of normal use. Referring to a planned work instruction may be appropriate. Having a developer repeatedly explain an obscure field is different. Record that assistance rather than allowing it to disappear from the result.

Follow the work into the next person's hands. Can the warehouse colleague proceed without a separate verbal explanation? Is the confirmed version clear? Are outstanding decisions visible? A success message on one screen should not end the assessment if another person still cannot act.

Our article on introducing software with employees considers the wider working method and support people need. Acceptance testing addresses a narrower question: what evidence supports approval of this particular delivery? Employees contribute operational judgement; they do not take over responsibility for every aspect of technical quality.

Record the version, environment and data used. Arrange suitable test data and prevent the exercise from sending real orders, invoices or messages to customers. Discuss with the developer how external effects are contained in the test environment.

Use accounts with the roles employees will actually have. Testing everything as an administrator does not demonstrate that everyday permissions work. Include the relevant devices and working conditions. A task completed comfortably on a large office monitor may be awkward where the employee normally uses it.

For each finding, capture the starting position, action, expected outcome and observed outcome. Add an example where useful, without unnecessary personal information. This allows the developer to reproduce the problem and someone else to verify the correction. “It sometimes fails” gives neither person enough to work with.

If the test environment differs from production, make that difference explicit. A simulated handover can establish how the application handles a response. It does not by itself demonstrate that the real connected system will receive the right information after release.

A wrong price may prevent release. An inconvenient but understandable field order may justify a different decision. Set the boundaries before the final review so that delivery pressure does not quietly redefine acceptable behaviour.

For each open finding, identify the people affected, the operational consequence and any temporary arrangement. The arrangement must be workable for the employees who will use it. Give it an owner, a review date and a clear point at which the correction will be checked. An indefinite promise to fix something later leaves the business carrying an unclear commitment.

Keep untested situations separate from passed tests. Missing data or an unavailable integration means evidence is absent. Decide whether that evidence is essential before proceeding. If approval covers only a limited group or type of order, record the boundary clearly.

Acceptance is one part of quality assurance. GOV.UK's guidance on testing services regularly distinguishes usability from technical checks and describes different testing approaches. An employee completing an order does not establish that the system will remain responsive under heavy demand.

Agree who authorises technical release, what will be checked after deployment and how problems will be handled. If the software changes after the acceptance exercise, identify which scenarios need to be repeated. The decision belongs to the assessed version and its recorded conditions.

For your next delivery, choose a few decisive work situations before development starts. Have the business owner, employee and developer agree what a satisfactory outcome looks like, then review the evidence together. Our approach to quality and operations connects these checks with development, release and ongoing support. That gives approval a practical meaning for everyone who must rely on it.