AI for the back office: how to pick your first process

Almost every enterprise now has an AI budget. Far fewer have AI adoption. The gap between the two is filled with pilots: demos that impressed a steering committee, proofs of concept that stalled in security review. Most of these pilots never reach production, and the reason is rarely the technology. It is the choice of process. Teams pick something visible instead of something suitable, and six months later they have a slide deck instead of a system.

If you run operations or finance, the back office is where your first real win lives. It is full of work that is repetitive, rule-shaped, and measurable, and it is far enough from your customers that a controlled rollout carries bounded risk. The question is not whether AI can help your back office. It is which process you should hand it first.

What makes a good first candidate

The best first process has four properties, and you should insist on all four.

It is repetitive. The same task arrives hundreds or thousands of times a month, and a trained person handles most instances the same way. Invoice coding, claims intake, supplier onboarding checks, expense audit, order entry from emailed purchase orders. Volume matters because it is what turns accuracy into savings. A process that runs forty times a quarter will never repay the effort of automating it properly, however elegant the demo.

It is document-heavy. Modern AI models are genuinely strong at reading messy documents: PDFs, scanned forms, email threads, attachments in inconsistent formats. If your team spends its day extracting fields from documents and keying them into a system, you are sitting on the canonical use case. The messier the inbound formats, the more a model outperforms the template-based tools you may have tried before.

It is measurable. You must be able to say, for any single instance, whether the AI got it right. Was the invoice coded to the correct account? If correctness is a matter of taste, you cannot compute an accuracy figure, and without one you cannot decide whether the system deserves more autonomy. Pick a process where right and wrong are checkable facts.

Its risk is bounded. Ask what the worst plausible error costs. A miscoded invoice caught at month end is an annoyance. A payment released to a fraudulent supplier is a crisis. Your first process should be one where a mistake is detectable, reversible, and cheap. You want the freedom to run the system at partial autonomy while it earns trust, and that only works when errors are survivable.

What makes a bad first candidate

The failure modes are just as recognisable.

Avoid anything customer-facing on day one. Support replies, collections calls, and renewal negotiations put the model's worst output in front of the people who pay you, before you know what that worst output looks like.

Avoid judgement-heavy work with no ground truth. Deciding which suppliers deserve better terms, or whether a borderline deal should be approved, involves context that lives in people's heads. The model will produce fluent answers you have no way to score.

Avoid processes that are currently broken. If two departments disagree about how the work should be done, or the procedure changes every month, automating it freezes the confusion. AI is an amplifier of process clarity, not a substitute for it. Fix the definition first, then automate the fixed version.

Avoid anything where the data does not exist yet. If the inputs live in one person's inbox and the outputs in a spreadsheet nobody else can open, you have a data plumbing project first. That is fine, but be honest about the sequencing.

Finally, avoid the everything-agent that promises to handle procurement, HR queries and finance close all at once. That is a pitch for a pilot that never ends. Narrow scope is what makes production possible.

Baseline before you build

Most teams skip this step, and it is the one that later determines whether anyone believes the results. Before a line of code is written, measure the process as it runs today. You need four numbers.

First, volume: how many instances arrive per week. Second, handling time: minutes per instance, measured rather than estimated, because self-reported figures are routinely off by half. Third, error rate: sample a few hundred recent cases and have someone senior re-check them; nearly every team discovers its human baseline is lower than assumed. Fourth, cycle time: how long an instance waits end to end, because the queue, not the work, is often what the business actually feels.

While you are there, collect the exceptions. Pull fifty of the strangest cases from the last quarter: the handwritten invoice, the purchase order in the wrong currency, the supplier whose name matches a sanctioned entity. This becomes your test set, worth more than any vendor benchmark because it is made of your reality.

The baseline does two jobs. It gives you an honest target, since beating your measured human error rate at a fraction of the cycle time is a success. And it gives you a defence when a sceptic points at one wrong answer, because you can point back at what the process produced before.

What production-grade actually means

This is where most pilots die, so it is worth being precise. A production-grade back office agent has three properties that a demo does not.

It writes back to systems of record. A tool that reads an invoice and displays a suggestion in its own dashboard has moved the work, not removed it. Someone still has to key the result into the ERP. Production means the agent posts the journal entry, updates the CRM record, or creates the ticket in the same systems your auditors and your reports already trust. Integration is unglamorous and it is most of the engineering, which is exactly why so many pilots stop short of it.

It hands off below a confidence threshold. No model is right every time, and a production system is built around that fact rather than in denial of it. Every case the agent handles carries a confidence assessment, and below an agreed threshold the case routes to a named owner: a specific person with the queue on their screen and the authority to decide. Not a shared mailbox, not a committee. The threshold is a dial you control: start conservative, with the agent completing perhaps half of cases on its own, and raise autonomy as the accuracy evidence accumulates.

It leaves an audit trail. For every instance, the system records what came in, what the agent extracted, what it decided, what confidence it assigned, what it wrote where, and who touched the case afterwards. Your internal audit team should be able to reconstruct any decision months later. This is not compliance decoration. It is the mechanism by which finance leadership, risk, and external auditors come to accept the system, and their acceptance is what stands between a pilot and a rollout.

Measure accuracy on your contested cases

Aggregate accuracy numbers flatter every system, because most back office volume is easy. If ninety percent of your invoices are clean PDFs from ten large suppliers, a mediocre system scores well by cruising through the easy majority while failing on everything hard.

So split your measurement. Score the routine cases and the contested cases separately, using the exception set you collected during baselining. The contested set is where the honest conversation happens: it tells you what the agent cannot yet do, which cases must keep routing to people, and where the confidence threshold belongs.

Review this regularly with the process owner in the room. Sample cases the agent completed autonomously, not just the ones it escalated, because silent errors are the ones that erode trust. And when the agent and the human disagree, resist the assumption that the human is right. In our experience a meaningful share of disagreements, once traced, turn out to be human error or ambiguity in the process definition itself.

Where to start this quarter

You can go from nothing to a defensible decision in a single quarter without buying anything.

Spend the first few weeks listing candidate processes and scoring each against the four properties. Involve the people who do the work; they know where the volume and the pain sit, and their early involvement decides whether the system gets used or quietly bypassed.

Spend the middle of the quarter baselining the top one or two candidates. Spend the final weeks defining production for the winner, in writing: which system of record it writes to, who owns escalations, the starting confidence threshold, and what the audit trail must contain. That one-page definition is the difference between commissioning a production system and commissioning another demo.

One process, done to production grade, beats five pilots. It creates the pattern, the evidence, and the internal credibility that make the second and third processes fast.

Where AI fails here

Being honest about the limits is part of picking well.

Models still misread documents, especially low-quality scans, dense tables, and handwriting, and they occasionally do so confidently. That is why the confidence threshold and the named owner are structural requirements, not optional safeguards. Accuracy also drifts: a new supplier format or a changed regulation can degrade a system that was performing well, which is why measurement is a permanent activity, not a launch gate.

AI will not fix a process your organisation cannot describe, and it will not resolve a disagreement between departments about how the work should be done. It struggles wherever ground truth is genuinely ambiguous. And the hardest problems in a deployment are usually not model problems at all: access to systems, data quality, and the question of who owns an exception at 4pm on the last day of the quarter. Expect the organisational work to take longer than the technical work, and plan for both.

None of this argues for waiting. It argues for choosing a process where these failure modes are survivable, instrumenting it honestly, and keeping people in the loop where the system is weakest.

The playbook is not complicated: pick a process that is repetitive, document-heavy, measurable, and safe to get wrong occasionally; baseline it before you build; hold out for production grade, meaning real writebacks, a named owner for the hard cases, and an audit trail; and score the contested cases separately so you always know where the edge of the system's competence sits. We build production AI agents inside enterprises, and this is the pattern that survives contact with auditors, sceptics, and quarter end. If you have a back office process in mind, describe it to Adopt AI Partners and we will tell you honestly whether it is a good first candidate.