Intelligent Process Automation
Automating the processes that traditional automation could never touch, because they need reading, classifying and deciding — measured on how many cases complete without a person, not on how many steps were automated.
Rule-based automation stops where judgement starts. It handles the invoice that matches the purchase order and hands you the four hundred that do not, which is where the work actually was. Intelligent process automation is the attempt to take those four hundred, and its honest measure is what share of them complete without a person.
Intelligent process automation combines workflow orchestration with machine learning and language models so that processes involving unstructured input, classification or judgement can run end to end, with confidence thresholds routing uncertain cases to people rather than guessing.
Measure the process before automating it
Almost every process is documented as it was designed rather than as it runs, and the difference is where automation succeeds or fails. So we measure first:
- Actual volume by variant. The happy path is usually a minority. Automating it alone delivers a fraction of the promised benefit.
- Where the time really goes. Often in waiting and rework rather than in the steps anyone thought to time.
- What the exceptions are and how often they occur. An exception rate of thirty per cent changes the entire business case.
- Which decisions are genuinely judgement and which are undocumented rules people apply consistently without realising.
- What a mistake costs, in both directions, because that sets the confidence threshold.
Automating a bad process makes it worse, faster
Where measurement shows the process contains steps that exist because of a system limitation removed years ago, or approvals nobody can justify, we say so. Removing a step is cheaper and more reliable than automating it, and that finding belongs in week three rather than in a retrospective.
How intelligent automation differs from rules
| Capability | Traditional automation | Intelligent automation |
|---|---|---|
| Structured input | Handles it well | Handles it well |
| Unstructured input | Cannot | Extracts and classifies with confidence |
| Variation in format | Breaks | Tolerates within a measured range |
| Judgement calls | Escalates all of them | Handles the confident ones, routes the rest |
| Behaviour when unsure | Fails or guesses | Routes to a person with the reason |
| Improvement over time | Only by editing rules | Reviewer corrections become training data |
The fifth row is the design principle the whole engagement turns on. A system that guesses when uncertain destroys trust in a fortnight; one that says clearly what it could not determine earns the right to handle more over time.
How we build it
Design the exception path first
The review queue, what the reviewer sees, how they correct it and where that correction goes are designed before the automated path, not after. Exception handling built as an afterthought is the single most common reason these systems are abandoned by the people meant to use them.
Set thresholds from consequence, not from a default
Every automated decision carries a confidence score and a threshold. Where a wrong approval costs thousands and a review costs two minutes, the threshold is high; where the reverse holds, it is lower. Starting conservative and relaxing on evidence is how trust is built rather than assumed.
Keep an audit trail per case
What was extracted, what was decided, by which model version, with what confidence, and who reviewed it. This is required for anything financial or regulated, and it is what makes the system defensible when a case is disputed months later.
Integrate through supported interfaces
APIs where they exist, and screen automation only where they genuinely do not, because interface automation is brittle and becomes a maintenance obligation. See RPA modernisation where existing robots are the starting point.
Report straight-through rate, not steps automated
The number of automated steps is a vanity metric. The share of cases that complete without human intervention is the one that maps to cost, and it is reported by case type so that the profitable segments are visible.
Close the loop
Corrections made by reviewers become training data, so the straight-through rate improves rather than decaying. Without this the system is at its best on launch day, which is the wrong shape for something meant to last.
How the engagement runs
The process is measured as it runs before any automation is designed.
Process measurement
Real volumes, variants, exception rates and cycle times measured; steps that should be removed rather than automated identified.
Design
Automated path, exception path, thresholds and audit requirements designed with the process owners and the people who will handle exceptions.
Build
Extraction, classification and decision components built and integrated, with the review queue delivered alongside rather than afterwards.
Shadow running
Running in parallel with the current process, outputs compared, thresholds tuned on real cases.
Rollout and handover
Staged rollout by case type, with runbooks and training for the exception handlers.
What you receive
A process with a measured straight-through rate, and an exception path people are willing to use.
Process measurement report
Real volumes, variants, exception rates and cycle times, with steps that should be removed named.
Automated process
Extraction, classification and decisioning integrated with your systems through supported interfaces.
Exception queue
Designed with the handlers, showing why each case arrived and capturing corrections.
Confidence thresholds
Set from the cost of each error direction, with the tuning evidence recorded.
Audit trail
Per-case record of extraction, decision, model version, confidence and reviewer.
Performance reporting
Straight-through rate by case type, exception reasons and cost per case.
Is this the right engagement?
Worth being direct. Intelligent Process Automation is the wrong spend in some situations, and those are listed rather than buried.
Good fit if
- A high-volume process is limited by people reading and judging rather than by system speed.
- Rule-based automation already handles the easy cases and escalates the rest.
- Exceptions are frequent enough that they are the real cost.
- The process is stable enough to be worth automating for more than a year.
- Someone owns the process and can commit to changing it.
Choose something else if
- Volume is low; the build will cost more than the labour it replaces.
- The process is about to be redesigned or the underlying system replaced.
- The work is entirely structured and rules are sufficient. See workflow automation.
- Nobody will handle exceptions, which makes the whole design unworkable.
Frequently asked questions
Marked up with FAQPage schema so these answers can surface directly in search results and inside AI assistant responses.
What is intelligent process automation?
Workflow automation combined with machine learning and language models, so that processes needing reading, classification or judgement can run end to end. The distinguishing feature is that uncertain cases are routed to a person with the reason attached rather than guessed at, which is what makes the automated share trustworthy.
How is IPA different from RPA?
RPA follows fixed rules and typically drives system interfaces; it breaks on variation and escalates anything requiring judgement. IPA adds models that handle unstructured input and uncertain decisions, with confidence thresholds. Many engagements combine both — see RPA modernisation with AI.
What straight-through rate is realistic?
It depends entirely on the process, which is why we measure before promising. Well-structured processes with consistent inputs reach high rates; those with genuinely varied inputs and consequential decisions settle lower and still pay back. The measurement phase gives you a defensible number before you commit to the build.
What happens to the people doing this work today?
Their work changes shape rather than disappearing: fewer routine cases, more exceptions and judgement. That is a real organisational change and it goes badly when it is sprung on people, so we involve exception handlers in the design from the start — they know the edge cases better than the process documentation does.
How do you stop it degrading over time?
By capturing reviewer corrections as training data and monitoring straight-through rate, confidence distributions and exception reasons. Inputs change, new case types appear, and an automation nobody retrains becomes an expert in last year's process.
Often paired with this
Most clients combine two or three engagements from the AI Integration and Process Automation pillar. These are the ones that most often run immediately before or after.
Document Workflow Automation
Intake, classification, extraction, validation and filing as one flow, measured on straight-through rate.
Read more →Business Workflow Automation
Cross-system orchestration with retries, idempotency and visibility, so nothing stalls unnoticed.
Read more →RPA Modernisation with AI
An honest robot-by-robot audit: retire, re-platform onto APIs, or extend with AI where judgement is needed.
Read more →Is this the right engagement?
Tell us what you are trying to build. If a different service fits better, or if you do not need us at all, we will say so.