AI Business Process Automation: Which Processes Actually Qualify

---

The Problem

01

Why the usual advice picks nothing

Every guide to AI business process automation says the same thing. Look for work that is high volume, repetitive and rule governed. Then it lists invoices, onboarding and customer queries.

That describes most of an operations department. It cannot tell you which of thirty candidate processes to fund this quarter, and it quietly points you at the cases where AI is the wrong tool.

A purchase approval that follows fixed thresholds is high volume, repetitive and rule governed. It is also a workflow problem that a form and a routing rule solve better, cheaper, and with an audit trail somebody can read.

---

The Frame

02

Two questions that sort any process

Ask these about the process, not about the technology. The answers put it in one of four boxes, and each box has a different right answer.

Most disappointment comes from putting a process in the top right box when it belongs in the bottom left. The technology works and the problem never needed it.

We built one of these for ourselves, which is the clearest way to show what the top right box looks like in practice. Sales OS takes a single prospect domain, reads what is public about that company, and returns an account brief that ends in a grade from A+ down to D.

It lands in that box for three reasons. The input is unstructured, the call it makes is a judgement rather than a rule, and a salesperson can agree or disagree with a grade in seconds. The question it settles, whether a company owns the equipment being inspected or sells inspection as a service to somebody else, used to cost our own team around forty minutes an account.

Note what it does not do. It does not contact anyone and it does not decide who to drop, because a wrong grade should cost a wasted call and nothing more.

---

The Trap

03

The exception path is the project

Pilots run on the clean cases. Production runs on everything.

Take a process handling a hundred items a day. Suppose the automation handles eighty five of them cleanly and fifteen come out awkward: a scan nobody can read, a supplier whose format changed, a case the rules never anticipated.

Those fifteen now need a designed path. Who sees them, in what queue, with what context, and how does the result rejoin the main flow. Skip that design and the fifteen land on whoever used to do all hundred, except now they arrive stripped of context and interleaved with other work.

This is why a process with a few awkward cases is sometimes harder to automate than one with many. At thirty per cent exceptions everyone accepts that the exception path needs building. At five per cent it gets waved through, and five per cent of a high volume process is still a lot of unhappy people.

---

Where To Look

04

Where the candidates usually hide

In inspection and field operations, the same four keep surfacing.

1. Turning notes into a report. An engineer captures findings in the field and spends the evening writing them up. Unstructured input, judgement, and the output is a draft a person edits and signs. The strongest first candidate most operations have.
2. Reading documents somebody else formatted. Certificates, test results, supplier declarations arriving as scans. Extraction then your existing rules, and the accuracy target is per field.
3. Triaging what arrives. Sorting incoming defects, queries or jobs by urgency so the right person sees them first. Often solvable with rules, so test that before training anything.
4. Spotting what repeats. The same fault across sites, the same supplier recurring in failures. Structured input and judgement, built on history you already hold.

Notice what is missing from that list. Anything that ends in an automatic sign off, an automatic payment or an automatic pass, because those fail on consequence rather than on capability.

---

Action

05

From candidate to decision

Sorting a process into a box tells you what kind of system it needs. It does not yet tell you to build it.

Run each surviving candidate through the four gates in the AI readiness assessment: the data exists, a person can check the answer quickly, being wrong is cheap, and the record shows who decided. Candidates that clear the matrix and fail a gate are worth revisiting later rather than arguing about now.

Where the input is images rather than text, the task families are set out in computer vision applications, and the agent pattern for multi step work sits in AI agent development.

Dev Station builds these into inspection and field data systems, where the automated step has to leave a record somebody can audit. Much of our work is for operators in the United States and the United Kingdom, so retention and audit trail questions are settled before the first sprint.

Our engineers work from Vietnam with overlap into US Eastern, US Pacific and UK GMT hours, and we invoice in USD or GBP. Send us the process you want automated and we will tell you which box it lands in. The build side sits in AI and ML development.

---

FAQ

06

Frequently asked questions

Which business processes should be automated with AI first?

The ones where the input is unstructured, a person can check the output in seconds, and a wrong answer is cheap to correct. In most operations that is report drafting and document extraction, not approvals or sign offs.

What is the difference between AI automation and RPA?

Robotic process automation repeats a fixed sequence of steps against predictable screens and fields. AI handles input that varies, such as free text, photographs and scanned documents, or decisions that need judgement rather than a rule. Many working systems use both, with the model doing the reading and the rules doing the acting.

How do we know if a process is too complex to automate?

Complexity is rarely the blocker. Look instead at the exception rate and at what happens to those exceptions, because an unhandled exception path is what turns a working pilot into a process nobody trusts.

Do we need our own data?

For extraction and drafting, often not much, since general models read documents and write text already. For prediction you need your own history with outcomes recorded, and that is usually the constraint rather than the modelling.