Hyperautomation fails at the handover, not the task

Inbound invoices are the classic automation project, and this one was done properly. Capture reads the PDF. A bot codes the invoice to the right account and cost centre. A workflow routes it for approval. An export sends it to accounting. Every step was automated, tested and shown working in the demo.

Then an invoice arrives with no purchase order number. Capture reads it correctly. Coding fails, because without the order the bot cannot tell which project it belongs to. The invoice lands in a shared exceptions queue that three people can see and nobody owns. Two weeks later the supplier phones about a late payment. The automation dashboard still shows a high share of invoices processed without a touch. The supplier only sees the one that was not.

“Hyperautomation” is the name the industry gives to automating as many steps as possible with a combination of tools: capture, bots, workflows, models. The approach treats a process as a sequence of tasks. But processes rarely fail inside a task. They fail between tasks, where work passes from one tool to another, from a machine to a person or from one team to the next. Each handover is a place where context is lost, ownership is unclear and the clock keeps running.

Where handovers break

Context is dropped. The bot passes on “coding failed” without saying what it tried, what it found or what is missing. The person who picks it up starts the investigation from scratch.

Queues without owners. A shared exceptions inbox feels safe because everyone can see it. In practice, everyone assumes someone else is dealing with it.

Waiting without a reason. An item sits as “pending” without saying on whom or on what it is waiting. Nobody can tell a case that is blocked from a case that is forgotten.

A mismatch of speed. Automation produces exceptions faster than people can clear them. The backlog grows quietly, because nothing measures it.

Measuring tasks instead of outcomes. “Share of steps automated” rises while “time from invoice received to invoice correctly paid” does not. Only the second matters to the supplier, and to the cash flow.

Each tool keeps its own state. The bot’s log, the workflow engine and the accounting system each believe something different about where the invoice is. Reconciling them becomes a job.

Design the handover first

Every task has an owner and a reason when it waits. An owner is a person, not a team. A reason is one sentence: waiting for the purchase order from procurement, since Tuesday.

The handover carries the case. What was done, what evidence was found, what is missing and what the suggested next step is, all in one place. When an agent hands over, it hands over a proposal with its sources and an estimate of risk, not an error code.

Route by risk, not by type. Low-risk exceptions with a clear suggested fix can be approved in bulk. High-risk ones go to a named person with the authority to decide.

One state for the case. Every tool involved writes to the same record, so “where is this invoice” has one answer.

Measure end to end. Time from arrival to correct completion, and the age of the oldest item waiting anywhere in the process. Those two numbers show handover failure; the automation rate hides it.

These are the principles behind Hurukan’s Decisions and Tasks module: one approval inbox for agent proposals with their sources and risk, bulk approval and routing by risk, tasks that always have an owner and a reason when waiting, and a history of every handover. The Agentic Logic layer sets the rule underneath: an agent proposes, a person decides on critical steps, and every action is logged. Both are in build. Choosing which kind of automation to use for each step is a separate question, covered in agents, RPA or workflows.

A test you can run today

Take your most automated process. Pull the list of every item currently waiting anywhere in it: in a queue, in an inbox, in a bot’s error log, in somebody’s flagged email. For each item, answer three questions:

1. Who owns it? A name, not a team.
2. Why is it waiting? One sentence.
3. Since when?

Mark every item where you cannot answer all three within a minute. Those are your handover failures, and they are the real measure of the automation.

Then take the oldest item on the list and read its history. Count how many times it changed hands, and how much of its age was spent waiting for somebody to notice it. That number is what the next automation project should reduce. More on how Hurukan approaches it is on the homepage.