What is hyperautomation, and does the term mean anything?
An umbrella term coined by analysts for using several automation technologies together. What it describes that is real, what it obscures, and how to answer when somebody asks for a strategy.
Rebecca Pearson11 min read
On this page
Hyperautomation is an analyst-coined umbrella term for using several automation technologies together — process mining to find the work, some combination of rules, integration, and models to do it, and orchestration to sequence it — applied systematically rather than case by case.
The honest assessment is that it names something real and does so imprecisely. The real thing is that most processes need more than one technique, and organisations that pick a single tool and apply it everywhere get poor results. The imprecision is that "use several tools together" is not a strategy, and a term that covers everything distinguishes nothing.
What we'll cover
Where the term came from
It is an analyst coinage, introduced to describe a shift from automating individual tasks to automating end to end with whatever combination of technologies the work requires.
It gained currency because it was useful to vendors, giving a single word for a portfolio of products that previously needed explaining separately.
It describes an approach rather than a technology. There is no hyperautomation software, despite a good deal of marketing to the contrary.
Related terms cover similar ground — intelligent automation, digital process automation, end-to-end automation — with boundaries that shift by who is speaking.
Knowing this is useful practically: when somebody asks for a hyperautomation strategy, they are asking for something, and working out what is the first task.
What it gets right
Three observations that hold up.
One technique is not enough. Real processes involve structured data, unstructured documents, systems with APIs, systems without, decisions with clear rules, and decisions requiring judgement. Any single tool handles a subset.
Finding the work matters as much as doing it. The insight that discovery — process mining, task analysis, asking people — should precede automation is correct and routinely skipped.
Coordination across a portfolio beats opportunistic local projects. Forty unrelated automations built by whoever had capacity produce less than a coordinated programme, mostly because nobody addressed the handoffs between them.
Those three are the durable content of the term, and they remain true whatever it is called next.
What it obscures
It suggests a product decision where there is a capability question. Nobody buys hyperautomation; they build a capability across several tools.
It flattens the difficulty. Automating a rules-based approval and automating a judgement-heavy exception are different problems with different failure modes, and one word for both hides that.
It encourages breadth over depth. A programme measured on how many technologies it uses is a programme that will use them whether or not they fit.
It makes the organisational work invisible. The hard parts — describing processes, deciding what happens to exceptions, getting owners — are not technological and the term does not gesture at them.
It has a shelf life. Terminology like this rotates, and a programme named after a term is awkward when the term goes out of fashion.
The techniques it covers
Worth listing plainly, because the value is in knowing which applies when.
Process discovery — mining event logs, analysing tasks — to find where time actually goes rather than where people assume.
Integration and workflow automation, which is the majority of the work in most organisations: systems talking to each other, with logic and orchestration between them.
Interface automation for systems with no API, which is genuinely useful and carries a maintenance cost proportional to how much you use it.
Document processing, turning unstructured input into structured data.
Models for judgement, where a decision cannot be expressed as rules — with a confidence threshold and a route to a person.
Orchestration, sequencing the above and holding the state of processes that run for days.
Most organisations need the second one far more than the others, and it is the least discussed because it is the least novel.
Answering the strategy question
When somebody asks for a hyperautomation strategy, this is a more useful response than a tool comparison.
Start with where time goes, measured rather than assumed — which processes, how much elapsed time, how many instances.
Pick by value, not by technology fit. The right first project is the one with the largest return, whatever technique it happens to need.
Match the technique to the work rather than selecting a technology and finding work for it.
Name the owner of each process before automating it, since a process with no owner has no one to decide what happens to the exceptions.
Decide what happens when it fails, per process, which is the design question everything else depends on.
Measure before and after, end to end, which is the part that determines whether the programme survives its first budget review.
Sequencing the work
Describe before automating. The description of how work actually happens is the artefact everything depends on, and producing it frequently shows the process should be simplified instead.
Simplify before automating. Automating a process with four unnecessary approvals encodes them permanently.
Connect before replacing. Most of the available value is in systems exchanging information rather than in any system being replaced.
Automate the handoffs before the steps. Work sits between steps rather than during them, so telling the next person immediately often removes most of the elapsed time with none of the difficulty.
Add judgement last. Where a decision needs a model, it needs an evaluation set, a confidence threshold, and an escalation path — none of which is worth building before the surrounding process works.
How these programmes fail
No baseline. Nobody measured the before, so the after is an assertion and the programme cannot defend itself.
Counting automations. A number that rewards volume produces automations nobody needed and an estate nobody can maintain.
No exception path. The happy path works and the exceptions accumulate in a queue with no owner, which looks like success in every dashboard.
A centre of excellence that becomes a queue, recreating the bottleneck the programme existed to remove.
Technology-first selection. A tool bought before the work was understood gets applied to work it does not suit.
No decommissioning. Automations outlive the processes they served, and nobody removes them, so the estate accumulates cost and risk indefinitely.
Talking to a vendor about it
A practical section, because the term appears most often in a sales conversation.
Ask which specific techniques their product covers, since almost none covers all of them and the ones claiming to usually cover most badly.
Ask what it does not do. A vendor who cannot answer that has not thought about where their product fits, which is a useful thing to learn early.
Ask about the last ten per cent. Every platform handles the common cases; what happens at the edge determines whether you finish the project.
Ask what their customers use alongside it, which is a more honest picture than a capability matrix.
Ask about pricing as adoption grows, since per-user, per-run, and per-connection models behave very differently at scale and the difference dwarfs the sticker price.
Ask who maintains the connectors, and how quickly they respond when a third party changes an API — because that is the recurring cost you are actually buying.
Where CodeWords fits
CodeWords covers the integration and workflow part — which is the majority of the work in most organisations. Describe what should happen in plain language and it builds, connects, and deploys the automation across more than 3,000 integrations.
- Open CodeWords and start a new automation.
- Describe the process to Cody, the automation builder, including where a person decides and what the exceptions are.
- Connect the systems each step touches, once, and reuse the connections.
The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.
What to get right first
A measured baseline for the processes you intend to change: end-to-end elapsed time, instance count, exception rate. It is unglamorous, it takes a fortnight, and it is the difference between a programme that can demonstrate its value and one that is defended with anecdotes at its first budget review.
Two habits make the difference. Pick projects by value rather than by which technology they showcase, since a programme measured on breadth will use techniques that do not fit. And design the exception path before the happy path, because the exceptions are where the cost is and a queue with no owner is how an automated process fails while appearing to work.
Frequently asked questions
Is hyperautomation a technology?
No. It is an analyst term for an approach — using several automation techniques together, systematically, rather than picking one tool and applying it everywhere. Nobody sells hyperautomation, despite marketing to the contrary.
What does the term get right?
That one technique is never enough for a real process, that finding the work matters as much as doing it, and that a coordinated portfolio beats unrelated local projects. Those three observations survive whatever the term is called next.
What should a strategy actually contain?
Where time currently goes, measured; which processes are worth changing, by value; who owns each; what happens when each fails; and how you will measure the result. Not a list of technologies.
Which technique matters most?
Integration and workflow automation, in most organisations, by a wide margin. It is the least discussed because it is the least novel, and it is where the majority of the available value sits.
Where do models belong in this?
At decisions that cannot be expressed as rules, with an evaluation set, a confidence threshold, and a route to a person. Added after the surrounding process works, not as the starting point.
Why do these programmes fail?
No baseline, counting automations rather than value, no exception path, and a centre of excellence that becomes the queue it was meant to remove. All four are organisational rather than technological.
Should we name a programme after the term?
Probably not. Terminology of this kind rotates every few years, and a programme named after a term that has gone out of fashion spends energy explaining itself. Name it after the outcome instead.
What should I ask a vendor selling this?
Which specific techniques it covers, what it explicitly does not do, what happens at the last ten per cent, what customers run alongside it, how pricing behaves as adoption grows, and who maintains the connectors when a third party changes an API.
Why does the last ten per cent matter so much?
Because every platform handles the common cases competently, and the project finishes or stalls on the edge cases. A capability matrix tells you about the first ninety per cent, which was never the risk.