Every business has exceptions.
A customer needs a different approval path. A supplier sends incomplete information. A sales order does not quite match the standard product setup. Finance has to manually adjust a charge. Operations has to check three systems before deciding what happens next.
That is normal.
The problem starts when the same exceptions keep appearing.
At that point, they are no longer edge cases. They are the real workflow.
The documented process might say one thing. The CRM stages, finance system, delivery tracker, or project board might suggest everything is neat and linear. But the actual work happens in the side channel: inbox threads, Slack messages, spreadsheet tabs, copied notes, manual checks, and the person everyone goes to because they know how the exceptions are handled.
That hidden exception process is often where the cost sits.
It slows decisions. It creates rework. It makes reporting unreliable. It trains the business to rely on memory instead of rules. And when people ask for automation, what they often mean is: please make this messy exception handling less painful.
Frequent Exceptions Are Operational Evidence
An exception is useful evidence.
It tells you that something about the standard process is not covering reality. That might be a good thing. Businesses change. Customers ask for unusual things. Products evolve. Teams learn where the original process was too rigid.
But repeated exceptions usually point to one of four problems.
First, the rule is unclear. People do not know what should happen, so they ask around until someone gives them an answer.
Second, the ownership is unclear. The work crosses teams, but nobody owns the decision or the outcome.
Third, the data is incomplete or untrusted. The system does not contain enough reliable information for someone to act without checking elsewhere.
Fourth, the tool does not fit the way the business actually works. People create workarounds because the official system is too slow, too rigid, or missing a key step.
None of those problems are solved by pretending the exception is rare.
If it happens every week, it deserves to be designed.
Do Not Automate The Workaround First
The tempting move is to automate the workaround.
Generate the message. Route the approval. Create the task. Copy the field. Summarise the case. Notify the manager. Chase the missing information.
Some of that may be useful.
But if you automate too early, you can easily encode the confusion. The business gets a faster workaround, not a better process.
That is how companies end up with workflows nobody fully understands. A form triggers an email. The email triggers a task. The task relies on a field that is only accurate half the time. Someone still checks a spreadsheet before approving it. The automation technically works, but the operational burden has not gone away. It has just been spread across more places.
Before building anything, map what is really happening.
Where does the exception start? Who spots it? What information is missing? Who decides? What rule are they using? What happens if they are unavailable? Which system is updated afterwards? Where does the reporting break?
Those questions can feel slower than jumping into automation. They are usually the shortest route to a fix that lasts.
AI Can Help, But It Needs Boundaries
AI is often useful around exception handling because exceptions tend to arrive in messy formats.
Emails, call notes, documents, free-text forms, support tickets, supplier messages, and customer requests do not always fit neatly into dropdowns. AI can help extract facts, classify requests, summarise context, draft responses, or identify missing information.
That can save real time.
But AI should not be used as a substitute for a business rule.
If nobody can explain the decision, an AI workflow will not make the business clearer. It will just add another layer between the problem and the person accountable for it.
Use AI where the input is messy.
Use process design where the decision is messy.
Use better architecture where the system of record is messy.
Those are different problems. Treating them as one big automation opportunity is how projects drift.
Turn Exceptions Into A Designed Path
The practical fix is not to eliminate every exception. That is unrealistic, and usually not worth trying.
The fix is to separate genuine edge cases from recurring alternative paths.
Start with the repeated exceptions. Pick the ones that consume time, delay revenue, create customer friction, introduce risk, or make reporting untrustworthy.
Then define the path properly:
- what triggers the exception
- what information is required
- who owns the decision
- what rules should be applied
- what happens when information is missing
- which system is the source of truth
- what status or audit trail is needed
- how success will be measured
Only then decide whether the fix is automation, AI, a better form, a cleaner approval rule, a system change, or a removed step.
Sometimes the best answer is a small internal tool that guides the decision and updates the right record.
Sometimes it is an AI-assisted triage step that turns messy input into structured data for a human to review.
Sometimes it is not automation at all. It is a clearer policy, a better handoff, or a change to the core system so the exception becomes a normal supported path.
The Hidden Workflow Is Where The Improvement Is
Founders, CTOs, and operations directors are often told to look for automation opportunities in repetitive work.
That is fine, but incomplete.
Look at the exception process too.
Look at the cases people keep escalating. Look at the work that depends on one experienced person. Look at the records people do not trust. Look at the approvals that happen outside the system. Look at the Slack threads where the real decision gets made before somebody updates the official tool afterwards.
That is often where the business is telling you what the process really is.
At Intelligent Marmalade, an operational friction review is designed to find exactly this kind of hidden workflow. We look at where work actually moves, where it gets reinterpreted, where data stops being trusted, and where targeted automation or a cleaner core process would make the business easier to run.
If your exception process is busy every week, it is not a side issue.
It is probably the workflow you need to fix next.