Agree what successful delivery means

Acceptance is the point where responsibility for a working automation passes from the builder to the business. It rests on evidence agreed in advance: criteria that describe correct behaviour, tests run against them and a record of who signed off. Without that evidence, "finished" means whatever the person speaking needs it to mean.

Write criteria before construction

Acceptance criteria written after the build tend to describe what was built rather than what was needed. Writing them during scoping, with the process owner, ties them to the discovery record and the exception log. Each criterion should be observable: someone who did not build the automation can run it and see whether it passes.

Criteria also need a tolerance where judgement is involved. If an automation reads supplier invoices, the firm should decide in advance how it wants misreads to be caught, for example by routing low-confidence results to a person, rather than discovering its tolerance in production.

Express criteria as worked examples

Behaviour-driven development, a practice described by Dan North and supported by tools such as Cucumber and its Gherkin syntax, frames requirements as Given–When–Then examples. The format suits SMEs because it reads as plain English and doubles as a test script. An illustrative criterion:

Given an invoice arrives with a purchase order number that matches an open order

When the totals agree within the agreed rounding rule

Then a draft bill is created against that supplier and the invoice file is attached

Given an invoice arrives with no purchase order number

When the automation processes the mailbox

Then the invoice is placed in the review queue and nothing is posted

Each entry in the exception log should have at least one example of this kind.

Test with realistic but safe data

Tests need data that looks like the real thing, including awkward formats and edge cases. Copying live customer or employee records into a test environment carries data protection risk. ICO guidance on anonymisation and pseudonymisation explains the difference between data that no longer identifies anyone and data that only hides identity behind a key. Where real data must be used, its use belongs in the scope statement and the firm's data protection records.

A steel ruler, a pencil and a blank checklist card on a dark desk under hard directional light
Illustrative image: measuring against an agreed standard.

Run user acceptance testing in a small team

User acceptance testing is carried out by the people who will use the result, not by its builder. A compact checklist suits teams without a test department:

  • Each criterion has a named tester and a recorded result: pass, fail or not run.
  • Failures are logged with what was expected and what happened.
  • Exception-log cases are tested, not only the routine path.
  • The process owner tries to pause, restart and roll back the automation.
  • Re-tests after fixes are recorded separately from first runs.

Expect different evidence for AI components

Rule-based automations behave the same way each time; components using machine learning or large language models may not. Acceptance for these parts usually relies on sampling: running a representative set of cases, reviewing outputs and agreeing an error tolerance and a human review step. The NIST AI Risk Management Framework organises this kind of work into four functions — Govern, Map, Measure and Manage — and its Measure function is a helpful prompt for what to test.

Where a system makes decisions about people, Article 22 of UK GDPR restricts solely automated decisions with legal or similarly significant effects, and the ICO's guidance on AI and data protection discusses meaningful human involvement. This is general information; specific cases call for professional advice.

Keep a sign-off record

What was accepted
The version, configuration and scope statement it was tested against.
Evidence
Test results, open defects and any agreed workarounds.
Who signed
The accountable person from the RACI, with the date.
Conditions
Anything accepted with reservations and the deadline for resolving it.

Firms working to ISO 9001 will recognise this as documented information; others simply benefit from being able to find it later.