AI automation for back office processes: what you test before you build

Most articles on this subject compare tools. None of them state a pass threshold.

That omission is why so many of these projects die the same way: a demo that works beautifully on five hand picked examples, then a pilot that falls apart against real inputs, then a quiet abandonment that nobody writes a post mortem for.

The fix is not a better model. It is deciding what "working" means before you build anything.

Start with the evaluation set, not the prompt#

Collect 100 to 300 real past cases with the correct answer attached. Real ones, from your actual process, including the messy examples people remember complaining about.

This is the deliverable that makes everything after it possible, and it is the one clients most often want to skip. It is also the most useful artifact of the entire project, because it outlives any particular model or vendor. When something better ships in eight months, you re-run the set and get a number instead of an opinion.

Build the set from the distribution of work as it actually arrives, not from clean examples. If 12% of your invoices are photographs of paper, 12% of the evaluation set is photographs of paper.

Agree the pass threshold with the process owner#

Then the question almost nobody asks out loud: how accurate does it have to be to be worth using?

The answer is not 100%. It is also not "better than a human", because that framing hides the real comparison. Humans in a repetitive back office process are typically somewhere in the 92 to 98% range and their errors are distributed differently.

What you need is three numbers, agreed in writing with whoever owns the process:

• The accuracy target. On the evaluation set, split by case type.
• The cost of a false positive. What happens when it acts and is wrong.
• The cost of a false negative. What happens when it escalates something it could have handled.

Those two costs are almost never symmetrical, and the asymmetry determines the whole design. An automation that misroutes an invoice costs a correction. An automation that approves a payment incorrectly costs the payment.

Design the escalation before the happy path#

The part that makes automation safe is the part that refuses to act.

Every decision comes with a confidence score, and every confidence band has a defined behaviour: act, act and flag for review, or escalate to a human with the reasoning attached. The threshold comes from the costs above, not from a default.

Escalation has to be genuinely usable. A queue nobody owns is a queue that grows until someone turns the automation off. Name the owner, set a response expectation, and make the escalation carry enough context that resolving it takes a minute rather than a reinvestigation.

Keep an audit log of every decision, its confidence, its inputs and its outcome. You will need it the first time someone asks why the system did something, and you will need it for the next round of evaluation.

Make the deterministic parts deterministic#

The most common design error is asking a model to do work that is not a judgement call.

Arithmetic, lookups, validation rules, routing by a field value, date parsing: all of these belong in code. They are faster, free, and correct every time. Reserve the model for the part that genuinely requires reading unstructured input and forming a judgement.

A pipeline where deterministic steps do the deterministic work is cheaper, easier to debug, and fails in ways you can predict. It is also the same discipline as a well built integration: put the rules where rules belong.

Run it in shadow for a week#

Before it touches anything, run the automation against live work in parallel with the humans doing the job. It produces output, the output goes nowhere, and you compare.

A week of shadow running tells you three things the evaluation set cannot:

1. Whether the real input distribution matches your set. It usually does not, and the gap is the cases nobody thought to collect.
2. How often it escalates in practice. If it escalates 40% of the time, it is not an automation, it is a second queue.
3. What it costs to run. Tokens, latency, and the retrieval layer, against real volume.

Shadow running is cheap and it is the step that converts a demo into a decision.

Then decide whether to build it at all#

The honest output of this process is sometimes no.

If the volume is low, the automation is a rounding error on someone's week and the maintenance will cost more than it saves. If the pass threshold cannot be met, say so and stop. If the process is a mess, automating it produces a faster mess, and the right fix is upstream.

We would rather run the evaluation and tell you the number is small than build something that gets switched off in month three.

What this costs#

AI automation starts at $12,000 and runs 4 to 8 weeks, fixed after a paid scoping week. The evaluation set and the shadow run are inside that, not extras. They are the parts that make the rest defensible.

Frequently asked questions#

How accurate does an AI automation need to be?#

There is no universal number. Derive it from the cost of a wrong action against the cost of an unnecessary escalation, agree it with the process owner in writing, and measure against a labelled set of real cases rather than a demo.

What is a shadow run?#

Running the automation against live work in parallel with the humans, where its output is recorded and compared but not acted on. A week of it reveals input distribution gaps and the real escalation rate before anything is at risk.

Should AI handle the whole process or part of it?#

Almost always part. Put arithmetic, lookups, validation and rule based routing in code, and reserve the model for judgement on unstructured input. Mixed pipelines are cheaper and fail predictably.

What if our process is not documented?#

Then documenting it is the first deliverable, and it is worth doing regardless. Automating an undocumented process means encoding whatever the last person did, including the parts that were mistakes.