Choosing Your First Workflow to Automate: A Scoring Method That Beats Gut Feel

Why do teams usually automate the wrong process first

The first automation project in most companies gets chosen by volume of complaints, not quality of fit. Someone in finance is fed up chasing invoice approvals. Someone in operations is tired of manually re-keying order data. The loudest process wins the budget, and six months later the team has a partially working automation that nobody trusts for the cases that actually matter.

This isn't a failure of ambition. It's a failure of selection criteria. Gut feel picks the process that's most annoying today. A scoring method picks the process most likely to succeed, generate confidence, and set a pattern the rest of the organisation will actually want to repeat.

That distinction matters more for the first workflow than any workflow that follows. The first automation sets the internal narrative about whether automation is trustworthy in your organisation. Pick badly and every subsequent proposal inherits the scepticism.

What is the six-factor scoring rubric for automation candidates

Bounded AI: Bounded AI means a system scoped to one task, gated by explicit approval steps, and logged so every decision can be traced back to its inputs, as opposed to an open-ended assistant asked to use judgement across an entire process.

Score every candidate workflow against these six factors before committing budget. None of them is disqualifying alone; it's the combination that separates a good first project from a slow-moving mistake.

Score each factor on a simple scale, say one to five, and total them. This won't produce a perfect ranking, and it isn't meant to. It's meant to surface the candidates where your intuition and the data disagree, because that's where a bad decision is most likely to happen unchallenged.

Can a process with a high cost of error still be a good candidate

It's tempting to rule out anything with a high cost of error and automate only the low-stakes work. That's overly cautious, and it wastes the technology on tasks nobody was struggling with in the first place.

A process with a genuinely high cost of error, contract clause extraction, say, or supplier payment matching, can still be an excellent first candidate if the review step is designed in from the start rather than bolted on afterwards. We'd argue the deciding factor isn't the cost of error at all, it's whether a human reviews the output before it has consequences.

Teams weighing this trade-off often start by mapping candidate processes against document processing automation before scoping a pilot.

This is the core of bounded AI in practice. The system does the repetitive extraction or matching work. A person, with the context to catch a genuine anomaly, approves before anything downstream happens. That structure lets you automate meaningful, high-value work safely, rather than confining automation to tasks too trivial to matter.

What does a good candidate look like next to a bad one

Two composite examples, drawn from patterns we see repeatedly across mid-market operations teams, make the scoring method concrete.

Good candidate: supplier invoice data capture

• Volume: several hundred invoices a month, arriving steadily
• Variance: mostly PDF or structured email, from a known, fairly stable set of suppliers
• Decision complexity: matching invoice lines to purchase orders, a rule-based comparison
• Cost of error: a mismatch delays payment by a day rather than causing a financial loss
• Data availability: invoices are already digital, POs live in one system
• Exception ownership: accounts payable already owns the exception queue today

This scores well across every factor. It's high volume, predictable, and any mismatch routes to a human who was already doing that job manually. The automation removes repetitive work without removing judgement from the cases that need it.

Bad candidate: customer complaint triage

• Volume: moderate, but spikes unpredictably around product issues
• Variance: highly variable free text, tone and context differ hugely case to case
• Decision complexity: requires genuine judgement about severity, goodwill and precedent
• Cost of error: a wrongly triaged complaint can escalate publicly or damage a relationship
• Data availability: scattered across email, chat and call notes with no consistent structure
• Exception ownership: unclear, often whichever manager is free that day

Every factor here works against automation. High variance, high stakes, poor data, and no clear owner for the cases that need a human. This is exactly the kind of process that gets picked first because it's painful, and exactly the kind that produces a visible, embarrassing failure within weeks.

Why should you design the exception path before the happy path

Most automation projects are built around the happy path: the 80 or 90 percent of cases that are straightforward. The exception path, what happens to the remaining cases, gets designed last, or not at all, because it's less satisfying to build and harder to demo.

This ordering is backwards. The exception path is where trust in the system is either built or destroyed. If exceptions vanish into a queue nobody monitors, or get silently approved because nobody flagged them as different, the automation looks like it's working right up until it very publicly isn't.

1. Name the person or role who owns exceptions before writing a single automation rule.
2. Define what counts as an exception explicitly, rather than leaving it to whatever the model doesn't confidently classify.
3. Set a service-level expectation for how quickly a flagged exception gets human attention.
4. Log every exception with enough context that a pattern of similar exceptions gets noticed, not handled one at a time forever.
5. Review the exception rate monthly for the first quarter; a rate that isn't falling suggests the automation's scope was drawn incorrectly.

A well-designed exception path also gives you an honest measure of whether the workflow was correctly scoped in the first place. If a third of cases are routing to exceptions six months in, the automation's boundary was drawn in the wrong place, and that's worth knowing early rather than discovering it in a compliance review.

How does scoring compare with letting a committee decide

Many organisations default to a steering committee to choose the first automation candidate, on the reasonable assumption that more perspectives produce a better decision. In practice, committees tend to converge on the process that's politically visible or personally painful to a senior stakeholder, which is a different thing from the process best suited to automation.

The practical answer is to use both, in sequence. Score the candidates first, so the committee is choosing between a shortlist of genuinely viable options rather than litigating from scratch. If your organisation is early in this conversation, an honest readiness check on your current data and process maturity is a useful precursor to either exercise.