Pick the workflow where somebody can already state the decision rule out loud, the work arrives in a system you can get credentials for, it runs at least weekly, mistakes are recoverable, and there is a named person with capacity to own the exceptions. All five. If one is missing, choose a different workflow or fix the missing one first.
There is a lot of published advice built around weighted scoring matrices for this decision. The matrices are fine as far as they go. The trouble is that they always produce a ranked list, and a ranked list feels like an answer. In practice the top-scoring candidate is often disqualified for a reason the matrix has no column for, and the disqualifiers are the part of this decision that actually saves money.
The five conditions
Someone can state the rule now. Not after a workshop. Now, in a meeting, in a couple of sentences, with the edge cases they already know about. If the rule cannot be articulated before the build, an agent cannot execute it reliably after the build. This is the single best predictor we have, and it is free to test.
The work arrives in a system. A helpdesk, a CRM, a shared mailbox with a real owner, a document store. It needs an interface you can call and credentials somebody in the business can authorise. Work that arrives in individual inboxes, or in a chat thread, or via someone walking over, has no reliable trigger, and building one is a separate project you have not scoped.
It runs weekly or more often. Frequency does two things: it makes the economics work, and it gives you enough real items to know within a fortnight whether the thing is behaving. A quarterly process gives you four observations a year and you will never build confidence in it.
Mistakes are recoverable, and somebody notices. Recoverable means a person can put it back without a customer or an auditor being involved. Noticed means the error surfaces in someone’s normal work rather than sitting undetected. A workflow where a quiet error compounds for a month is a bad first choice, regardless of how much time it would save.
There is a named exception owner with capacity. Not a team. A person, by name, who has agreed that the items the agent cannot finish are theirs, and who has room in their week. If the answer to “who picks up the ones it cannot do” is a shrug or a department name, the exception queue will become a second manual process and the project will be judged a failure for reasons that have nothing to do with the agent.
The disqualifiers
These override any score.
The system is being replaced. If the helpdesk, CRM or ERP holding the work is due for migration or consolidation inside the next few months, build afterwards. Wiring into a tenant that is about to be retired means paying for the same integration twice.
The process is about to change for other reasons. A reorganisation, a new pricing model, a policy rewrite. Automating a process the week before it is redesigned produces an agent that enforces the old rules faithfully.
The rule is genuinely contested. If support and finance disagree about when a credit is allowed, automation does not settle it. It relocates the disagreement into a system where it is harder to see. Settle the policy with people first. This one is common and it is usually the real blocker behind a project that keeps not starting.
Nobody will own the exceptions. Covered above, and worth repeating because it is the most frequently ignored condition and the most reliable predictor of a dead automation.
The volume is small. Do the arithmetic before anything else. A queue producing a few items a week does not repay an implementation, and a monthly retainer on it will not repay one either. That belongs in the first conversation, not in a discovery in month three.
The value of the work is the judgement. Negotiation, senior escalations, anything where the relationship is the product. You can automate the preparation around those conversations. You should not automate the conversation.
The data is not accessible to anyone who can grant access. Sometimes the information the agent needs sits in a system owned by another business unit, or a supplier’s portal, or a spreadsheet on someone’s drive. That is an access project, and it needs to finish before the automation starts.
The three shapes that usually pass
Across the workflows we are asked about, three recur, and they recur because they satisfy the five conditions naturally rather than because they are fashionable.
Support ticket triage. High frequency, the rule is describable once you have read a few months of your own tickets, the writes are internal and reversible, and there is an obvious place to stop and hand over. Details on the customer support workflow page.
Sales operations hygiene: enrichment, scoring and CRM write-back. High frequency, the fields are known, and everything customer-facing sits naturally on the other side of the line. Details on the sales operations workflow page.
Document extraction with validation against your systems. High frequency in most finance and claims functions, the checks are arithmetic against records you already hold, and the exception types map to owners who already exist. Details on the document processing workflow page.
Measure the baseline before anything is built
This is the step most often skipped, and skipping it is why so many automations end up with no defensible result. Without a baseline you cannot show what changed, and you will end up asserting a benefit rather than demonstrating one.
We do not supply an industry average for this, and you should be sceptical of anyone who does, because the number that matters is yours. Three measurements, over two ordinary weeks:
Count the items. How many tickets, leads, invoices actually came through that path, and what the daily spread looked like. Peaks matter more than averages when you are sizing an exception queue.
Time a sample. Sit with whoever does the work and time twenty items end to end, including the interruptions. The interruptions are usually where the real cost is.
Count the handoffs. How many items needed a second person, and why. That count is your future exception volume, and it is the closest thing you have to a forecast of the review load.
Two weeks of this is enough. It also frequently changes which workflow people want to start with.
Scope smaller than feels satisfying
“Automate customer support” cannot be approved, delivered or measured. “Resolve repeatable order status tickets in the existing helpdesk, with a person on anything touching money” can be all three.
The narrower scope is not a lesser ambition. It is the version that goes live, produces real numbers, and earns the argument for the second workflow. The version that tries to cover the whole function is the version that stalls in scoping and becomes another slide.
The most valuable workflow is usually the wrong first one
This runs against instinct, so we will say it plainly. The process with the largest theoretical saving is typically the one with the most exceptions, the most stakeholders and the most contested rules. It is exactly the workflow that will take two quarters and disappoint people.
Start with the one that is boring, frequent and clearly owned. Get it live. Then use the credibility from something that actually works to go after the expensive one.
How the decision gets made with us
A delivery lead spends thirty minutes on one real process, and the output is a straight answer about whether an agent is worth putting live on it. If the answer is no, we say so on the call, and the client keeps the workflow map either way.
That is the free assessment. What it costs if the answer is yes is on the pricing page.