For processes that break the moment a rule is missing
AI Automation
Many business processes look automatable until an invoice arrives in the wrong format or a claim falls outside every rule the bot was given. This practice builds automation that reads unstructured input, classifies what kind of case it is looking at, and routes exceptions to a person only when judgment genuinely is required. It exists for processes RPA cannot finish because the inputs refuse to stay standard.
What judgment-bearing automation actually looks like
Document reading, exception routing and the human checkpoint walked through in full.
85 secSample frame · video pending01Before automating a process
Not every process needs judgment, and that matters
Automating a process that already follows one fixed rule with a judgment layer spends more than the problem requires. Four checks settle whether a process actually needs judgment or a simpler bot.
Do inputs arrive in more than one format?
A process reading scanned invoices, emails and spreadsheets needs document understanding a rule-based bot was never built to handle.
How often does a case fall outside the standard rule?
A process with frequent exceptions spends more time on workarounds than the automation was meant to save.
Does a wrong classification carry real consequence?
A misrouted low-value ticket is recoverable; a misclassified compliance case is not, and that gap should decide the automation depth.
Would a simple rule actually cover this case?
If every case truly follows the same steps in the same order, deterministic automation is faster and cheaper to build.
| RPA | Intelligent process automation | |
|---|---|---|
| Input format | Fixed and structured | Documents, emails, mixed formats |
| Exception handling | Fails or halts | Classified and routed |
| Logic | Explicit rules | Learned patterns plus rules |
| Maintenance | Breaks on format change | Adapts within trained range |
| Right for | Stable, repetitive steps | Judgment-bearing, variable cases |
02Agreed before automation starts
The ledger that keeps the process honest
Every automation engagement fixes what you bring, what we design and train, what comes back as a working process, and what authority never leaves your team regardless of engagement shape.
- Your side
You bring
- Sample documents across every format they arrive in
- The rules the current manual process actually follows
- The exceptions your team already handles by hand
- Our side
We build
- A document classifier trained on your real cases
- Confidence thresholds tuned to your risk tolerance
- Routing that sends only genuine exceptions to a person
- Your side
You receive
- An automated intake handling the standard cases
- A routing path for every exception type
- A measured reduction in manual handling time
Never leaves you
- Final policy on what counts as an exception
- The reviewers who make the judgment calls
- Ownership of every document and its data
Where the line sitsWe classify and route. Deciding what an acceptable exception actually looks like stays a policy call your team makes.
03From manual to routed automatically
Four stages, each closing on a process you can trust
Automation fails quietly when exceptions get buried instead of routed, so this process closes each stage with a checkpoint your team can inspect before trusting the next one.
Trace the process as it actually runs
Every path a case takes today is mapped, including the workarounds nobody wrote down, before any automation gets designed.
A mapped processBuild the document and case classifier
Cases are sorted by type and confidence, so the system knows when it is sure and when a person should look.
A classifier with a confidence scoreWire exception routing to a real reviewer
Low-confidence cases reach a named reviewer automatically, so exceptions do not sit in a queue nobody is watching.
A routing rule with teethHand over the process and its training data
Your team owns the classifier's training data and the routing rules, so the process improves after we step back.
A team that can extend it
04What actually drives the number
Four drivers behind an automation build
Automation work is priced against how much judgment the process actually requires, not a flat per-process rate, because these drivers change the effort by multiples.
Variety of input formats
A process reading one document type costs less to automate than one ingesting emails, PDFs and scanned forms together.
Exception rate and complexity
A process where most cases are standard needs less judgment logic than one where exceptions are the majority.
Consequence of a wrong classification
Higher-stakes processes need tighter confidence thresholds and more reviewer checkpoints than a low-stakes internal workflow.
Existing systems the process must reach
Wiring the automation into legacy systems already in place costs more than automating a process with modern interfaces.
05Evidence and proof
Processes where the exception queue finally stopped growing.
Automation proof is measured in exceptions routed correctly, not in cases processed. Each record stays a placeholder pending the named client's written approval.
Explore case studies
A logistics claims process stopped drowning in manual exceptions.
Tern's freight claims arrived as scanned forms, emails and spreadsheets that a fixed bot could not read consistently. A classifier sorted claims by type and routed only genuine exceptions to a reviewer.
- Claims routed automatically
- Majority of volume
- Manual review queue
- Reduced sharply
A manufacturer's purchase-order exceptions found a reviewer automatically.
Nexa Foundry's purchasing team manually checked every order that did not match a supplier catalogue exactly. Automated classification routed genuine mismatches to a buyer within the same shift.
- Orders auto-matched
- Most standard volume
- Reviewer response time
- Same shift
Exceptions used to sit in a queue for days. Now the ones that actually need a person reach one the same morning.
Sample · pending client approval
06Read this first
When intelligent automation is the wrong spend
Building a judgment layer around a process with one fixed rule and no real exceptions spends more than the problem justifies, so the exits are marked early. When the build is justified, it reads your existing documents and systems, not a new intake format we impose.
- RPA automation
Your process already follows one fixed rule
Deterministic automation handles this at lower cost and with a simpler system to maintain.
- AI consulting
The process barely exists yet
Map and stabilise the manual process first, so there is something proven worth automating.
- AI transformation
Automation is one piece of a bigger change
A wider adoption programme should set the sequence this automation then fits inside.
| Shape | Best when | You direct | We carry |
|---|---|---|---|
| Scoped build | One process is mapped and ready | Priorities and thresholds | Classifier, routing, automation build |
| Delivery pod | Several processes need automating in sequence | Roadmap across processes | Ongoing build, training, releases |
| Team extension | Your leads want to own the build | Standards and architecture | Named engineers embedded in delivery |
07Straight answers
Asked before an automation build starts.
01How is this different from RPA?
RPA follows a fixed script across structured inputs and stops when something does not match. Intelligent process automation reads varied documents, classifies what it sees, and routes genuine exceptions to a reviewer instead of halting.
02Can it work alongside an RPA bot we already have?
Yes, and that is a common pattern. The intelligent layer classifies and normalises inputs, then hands the standard cases to the existing bot rather than replacing it outright.
03What happens to cases the system is not confident about?
They route to a named human reviewer automatically, based on a confidence threshold agreed with your team. The system never guesses past the point it was trained to trust itself.
04How much manual review does this remove?
It depends on how much of the process already follows a standard pattern; automation handles that share and leaves genuine exceptions to your reviewers. Most teams see the manual queue shrink to the cases that actually need judgment.
05Does the classifier need our historical data to train on?
Yes, historical cases are what teach it to recognise your real document variety and exception patterns. Without them, the system starts from generic patterns that fit your process poorly.
06What industries is this suited to?
Any process handling documents, claims or applications with real variation, across finance, healthcare, logistics and manufacturing alike. The suitability test is the exception rate, not the sector label.
07Who reviews the exceptions the system flags?
Whoever your process already assigns to the equivalent manual decision, kept in the loop by design rather than removed. Automation routes the case to that person faster, not around them.