You Mapped the Process. You Never Asked If It Should Exist.

A team spends two weeks mapping its order-exception process: every handoff, every approval, every email that moves a stuck shipment forward. The map is accurate. The automation built on top of it is fast. And it now processes a hundred exceptions a day that a cleaner intake form would have stopped from ever happening. Knowing how to identify processes for automation starts one step earlier than most teams think: before you ask how a process runs, ask whether it should run at all. 

The scale of what could be automated makes the question urgent. McKinsey Global Institute estimated in November 2025 that currently demonstrated technology could, in theory, automate activities absorbing about 57% of US work hours. That figure is technical potential, not a to-do list. Automating a process does not make it correct. It makes it faster, which means a flawed process produces flawed output at a higher rate, with the exceptions piling up where no one is watching. 

Key takeaways 

• A process map shows how work flows today. It is silent on whether that work earns its place. 
• Redesign or remove the process first. McKinsey found that nearly three-quarters of AI high performers redesign the workflow before automating it, against about a quarter of everyone else. 
• Use a five-question readiness test to separate real automation candidates from busy work that should be cut. 
• The most expensive automation is the one that works perfectly on a process that should not exist. 
• Score every process on the list before you pick up a tool, a vendor, or an agent framework. 

Mapping captures the current state and stops there 

A process map records what happens: the steps, the owners, the systems, the time each handoff takes. That record is useful, and it is also silent on the only question that decides whether automation pays off, which is whether the process deserves to continue in its current shape. Mapping documents for the work. It does not interrogate it. 

This is where a workflow automation assessment differs from a mapping exercise. A map answers, “how does this run?” An assessment answers, “should this run, and if so, in what form?” The gap between those two questions is where failed automation projects live. A bot built on an unexamined map inherits every workaround, every duplicate approval, and every manual check that existed only because the process was broken. The automation then runs those flaws reliably, which is worse than running them occasionally. 

Deloitte’s State of AI in the Enterprise 2026 survey points to the same split: about 30% of organizations are redesigning key processes around AI, while 37% apply AI at the surface with little process change. The surface group is automating maps. The redesign group is asking the prior question first. 

Five questions that answer how to identify processes for automation 

Knowing how to identify processes for automation comes down to a short readiness test you run on each candidate before any build begins. The test separates real process automation candidates from work that a form of change or a policy fix would remove. A process is worth automating when it is stable, high-volume, rule-clear, costly in its current form, and still necessary once simplified. Weakness on any single dimension is a reason to pause, redesign, or drop the process rather than wrap code around it. 

Run these five questions against every process on your list. Treat each “no” as a stop sign, not a detail to fix later. 

1. Should this process exist at all? If a form, a policy, or an upstream fix would remove the work, remove the work. Automating a step you could delete is the most common waste in a first project. 
2. Is the process stable? A process that changes every few weeks will break the automation every few weeks. Stable rules are what make a process a real automation candidate. 
3. Is the logic clear enough to write down? If the people who run it cannot state the rules without saying “it depends,” the automation cannot either. Ambiguous judgment is a redesign task before it is an automation task. 
4. Does the current cost justify the build? Volume times time times error rate gives you the real cost. Low-volume, low-error processes rarely repay engineering and ongoing maintenance. 
5. Do the exceptions have a home? Every process has cases where the rules do not cover. If there is no clear path for a human to take over, automation will multiply the exceptions instead of reducing them. 

The table below turns the five questions into an automation readiness checklist you can score. Mark each process green, amber, or red, and start only with the processes that clear all five. 

Readiness question	What a strong answer looks like	What a weak answer signals
Should it exist?	The work is necessary even after upstream fixes	A form or policy change deletes the process
Is it stable?	Rules held steady for months	Frequent changes will break the build
Is the logic clear?	Owners can write the rules down	“It depends” judgment runs the process
Does cost justify it?	High volume, measurable error cost	Low volume, little to recover
Do exceptions have a home?	A named human owns the edge cases	Exceptions fall through with no owner

A process that scores green on all five is a genuine candidate. A process that scores red on the first question was never an automation problem. It was a design problem wearing an automation costume. 

Redesign usually beats automation, and the data backs it 

The strongest evidence for fixing a process before automating it comes from the organizations already seeing financial returns. In McKinsey’s State of AI survey published in August 2026, nearly three-quarters of AI high performers reported fundamentally redesigning workflows because of their AI use, up from 55% a year earlier, while only about a quarter of other respondents did the same. The high performers are not automating faster. They are automating different work, because they reshaped it first. 

Redesign-first works because it attacks the cost before the tooling does. A process with four approvals becomes a process with one, and only then does automation run against the leaner version. Deciding which processes to automate first is really a decision about which processes are worth keeping at all, and in what form. The strongest process automation candidates are the ones that survive that cut, not the ones that topped the list before anyone questioned them. The sequence matters: simplify, confirm the process still earns its place, then build. 

This is also where process mining for automation earns its keep, used correctly. Mining tools reconstruct how a process runs in practice from system logs, which exposes the rework loops and the ignored steps a workshop map hides. Read as a discovery tool, process mining for automation tells you where to cut. Read as a blueprint, it tells you what to automate and quietly carries the waste straight into the build. 

The broken-process trap: when automation multiplies the exceptions 

Skipping the readiness test carries one specific, expensive risk. When a process has rules that do not cover its real range of cases, automation does not close the gap. It runs straight through the gap, faster, and turns a trickle of edge cases into a steady flood. 

Speed is what changes the stakes. The same gap behaves in two very different ways depending on who works the process: 

• At manual speed, a person meets each uncovered case, improvises a fix, and moves on. The gap stays invisible because a human quietly absorbs it. 

• At automated speed, there is no improvising. Every uncovered case drops into an exception queue, and the queue fills faster than anyone clears it. The dashboard keeps reporting success while the backlog builds behind it. 

A logistics order desk makes the pattern concrete. Picture rules that handle standard orders cleanly but stay silent on partial shipments, customs holds, and split deliveries. A clerk resolves those by instinct every day. An automation cannot. It routes each one to a queue, and when no one owns that queue, the queue becomes the new bottleneck. The automation did its job. The process design did not work. 

The lesson is worth stating plainly. Automating a broken process does not reduce its exceptions; it industrializes them. That is why the fifth readiness question, the one that asks where exceptions go, is both the question teams skip most often and the one that causes the most damage when it is missed. 

A logistics order desk, scored before anyone built a bot 

The following example is illustrative and does not describe a specific client. 

A mid-market distributor wanted to automate its order-exception desk, where staff spent hours each day chasing stuck shipments. The obvious move was to map the chase process and automate it. The team ran the five-question test first instead, and two answers changed the plan before a line of code was written. 

• Question one exposed a form fix. A third of exceptions traced to one cause: an intake form that let customers submit orders with missing delivery windows. That was not an automation candidate. Correcting the form removed a third of the work outright. 
• Question five exposed a missing owner. Customs-hold cases had no one accountable for them. An automation would have routed those into a queue nobody watched, so the team named an owner before building. 

What remained after the redesign was a smaller, cleaner process: stable rules, clear logic, real volume, and a named home for the edge cases. That version was worth automating, and it was held because it ran against a process that had already earned its place. The map alone would have delivered a fast bot sitting on top of the same broken intake. 

Where ViitorCloud cuts before it codes 

Most automation engagements begin by asking what to build. On AI-driven automation projects, ViitorCloud begins by asking what to delete. The first deliverable is a scored list of candidate processes, not a bot, because the readiness test routinely cuts the automation scope before the engineering starts, and a smaller scope that runs is worth more than a larger one that breaks. 

That order changes the economics of a first project, because deciding which processes to automate first is a scoping decision as much as a technical one. Processes that fail to question one are redesigned or removed, so the build targets only work that survives scrutiny. Exceptions receive a named owner before launching, so the system has somewhere to send the cases its rules do not cover. For a logistics operation, that has meant order-desk and exception workflows scored against real volume and error cost first, as in the Hensel distributor order portal work, then automated once the process held up. The method draws on the same build-or-redesign judgment covered in ViitorCloud’s guide to choosing which operations to automate. 

Score the list before you pick a tool 

If you have a list of manual processes and no way to rank them, start with the five-question test, not a vendor demo. That test is the practical answer to how to identify processes for automation: run each process through the automation readiness checklist, mark the greens, and redesign or drop the rest. The processes that clear all five are the ones worth a build, and they are a short list more often than teams expect. To pressure-test your own candidate list against real volume and exception cost before committing an engineering budget, talk to the ViitorCloud team.