How to Write Acceptance Criteria for an Automation Project

The awkward day almost nobody plans for

Every fixed-scope automation project has the same delicate moment: the day the vendor says "it's ready" and somebody on your side has to decide whether that's true. If the decision gets made in a meeting, with screenshots and goodwill, the project already went wrong — no matter how well the workflow is built. What follows is predictable: two weeks of emails, a list of "small details" that surface afterwards, and a commercial relationship that starts in distrust.

Acceptance criteria exist so that decision isn't an opinion. They are the list, written before work starts, of the tests the system has to pass to count as delivered. Written properly, they move the discussion out of perception and into fact: you run the test, you count the result, it passes or it doesn't.

This article is how you write them — the exact shape we use in the scope document that fixes every project before it is invoiced.

The three parts of a verifiable criterion

The acid test for a criterion is this: can the client verify it without the vendor in the room? If someone has to explain the result to you, the criterion doesn't work. Meeting that bar takes three things, and all three go in writing.

1. A number

Not "most of the invoices", but "the 20 invoices dropped in the folder on test day". The number does two jobs: it defines the sample size and it defines the threshold. Without a number, any result is defensible by both parties — which is another way of saying there is no criterion.

Watch out for the number that looks like a number and isn't: "under 5% error" on a sample nobody defined is still ambiguous. The percentage needs its denominator written down.

2. A source of truth

What is the result compared against? If the criterion says "the data must be correct", the essential half is missing: correct according to what. The source of truth can be the original PDF, your team's manual capture of the same sample, the bank statement balance, or the record in the ERP. What it cannot be is the judgment of whoever happens to review it that day.

Naming the source of truth has a valuable side effect: it forces you to discover, before building, that two areas of your company consider a different value to be the true one. That discovery costs one conversation at the start of a project and costs the entire project at the end.

3. A test that can only come out yes or no

The criterion has to end in a sentence that starts with "accepted if". Not "evaluated", not "reviewed": accepted if. If reading the test allows two readings of the result, it isn't a criterion yet — it's an intention.

Three worked examples

These three are written in that shape. They are deliberately drawn from different processes: the shape is what you reuse, never the content.

Example 1 — Expense receipt capture

Criterion. Of the 30 expense receipts uploaded by the admin team into the inbox folder on test day, the workflow writes 30 rows into the control sheet with supplier, date, subtotal, tax and total.

Accepted if all 30 rows match, across the five fields, the manual capture of the same sample done by the person who captures it today. One missing row, one duplicate, or one differing field fails the criterion.

Notice what that last sentence does: it turns "it's correct" into a comparison against work that already exists. The source of truth isn't an idea — it's a sheet somebody was already filling in by hand.

Example 2 — Collections reminders

Criterion. Every morning at 9:00, the workflow sends a reminder to the invoices that fell overdue the previous day according to the accounts-receivable report, and to no others.

Accepted if, across three consecutive test days, the list of emails sent matches exactly the list of overdue invoices for each day: no overdue invoice goes without a reminder, and no already-paid invoice receives one.

The second half is the one that matters. A criterion that only measures what the workflow does right leaves out the real risk in collections automation, which is not failing to chase: it's chasing a customer who already paid. When you draft criteria, always write the false-positive condition.

Example 3 — The rollback works

Criterion. The documented rollback procedure returns the system to the exact state preceding a run.

Accepted if, after running the workflow on a test sample and executing the rollback by following the delivered document — with no help from the vendor —, the affected records are identical to their prior backup, and the audit trail shows both the run and the rollback with user, date and time.

This criterion is the one almost always left out, and the one that protects you most. A rollback only the vendor knows how to run is not a rollback: it's an emergency call under a different name.

The three vague criteria that end in disputes

"That it works well"

The most common and the most expensive. "Well" is a word each party fills with its own expectation, and the two expectations only get compared on delivery day — when there is no room left to adjust anything without cost. The fix: replace "well" with the sample and the comparison. What goes in, what comes out, what it is checked against.

"That it's fast"

Fast for the person who lives the process today and fast for the person who built it rarely coincide. And "fast" without a sample ignores the case that matters: a workflow can answer in seconds with two cases and in twenty minutes with two hundred. The fix: a maximum time, over a named volume, measured by a named person.

"That it turns out like we discussed"

This is the most dangerous because it sounds reasonable. A conversation is not a verifiable artifact: nobody can reproduce two months later what was said on a 40-minute call, and both sides will honestly remember different versions. The fix isn't recording the call: it's making sure everything discussed that is meant to be enforceable appears in the scope document. What wasn't written down wasn't agreed.

The three fields almost nobody writes

A well-drafted criterion can still fail if the operational details of the test are missing. Write these three next to the list:

• Who verifies. A name and a role, not a department. Departments don't sign.
• On what sample. How many cases, where they come from, and who prepares them. A sample the vendor prepares proves less than a sample you prepare.
• On what date. The acceptance test is an appointment on the calendar, not a vague "whenever it's ready".

And one more, which prevents the worst conversation of all: what happens if a criterion fails. The healthy answer is simple and gets written at the start: it is corrected and the test is repeated on the same sample.

Why the criteria, not the invoice, close the project

In our model, payment splits in two: a 50% deposit to schedule the work and 50% against accepted delivery. The word doing all the work in that sentence is accepted. The final payment isn't released when the vendor considers the work finished, nor when the calendar date passes: it is released when the written criteria pass their test.

That inversion is deliberate, and it serves both sides. It serves you because the last payment is tied to a verification you can perform yourself. It serves us because it removes the open ending — the project that never finishes finishing because every week brings a new requirement that "was always implied". Any scope change is quoted separately; there are never surprise hours.

Where this lives in a fixed-scope project

The criteria aren't an appendix: they are the center of the scope document agreed before any payment link exists. That document describes the process as it happens today, the inputs and outputs, the access the workflow needs and who grants it, what we deliver, the acceptance criteria, what it explicitly excludes, the fixed price and the committed date.

Writing it takes a few hours of conversation and saves the weeks it costs to discover a disagreement at the end. If an automation vendor refuses to fix acceptance criteria in writing, that is all the information you need about that vendor.

In our custom automation offer, that document also fixes the price: USD $1,300 to $2,900 depending on the process — a written-quote range, not a list price — delivered in 1 to 3 weeks, training included, with 30 days of post-delivery adjustments.

Start by measuring

Before drafting criteria you need to know which process deserves them. Our free assessment takes 3 minutes and returns a maturity score with recommendations prioritized by impact — no card, no mandatory call.

Take the free assessment →

And if you already have the process identified, the full offer — fixed scope, approval gates, audit trail and rollback — is at simiriki.com/automatizacion.

---

Sourcing note: this article cites no third-party statistics — the argument is mechanism-based and verifiable by the reader. Price ranges, timelines and payment terms match the current offer at /automatizacion and are written-quote ranges.