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.

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.