Your order-intake process probably looks tidy on the process chart, yet it works because one or two experienced people know what to do when an order does not fit. Capture those order-intake exceptions as business rules before you automate, and AI agents can move routine orders through while each unusual case reaches the person who decides it.
Exception capture turns each “it depends” into a named rule: what triggers it, what gets decided, who owns the decision and where the case goes next. An agent can only act on the picture of the company it is given, so this is the first build step, not paperwork.
What you gain by writing order-intake exceptions as business rules for AI agents
- Routine orders move without re-keying. Once the checks are explicit, software can match customer, part, price, date and drawing revision on every purchase order (PO) instead of a clerk checking by eye.
- Unusual orders reach the accountable person with the context attached. Each rule names an owner, so a price query goes to the sales manager with the PO and the quote.
- The company keeps the knowledge. What lived in one clerk's head becomes part of your own business model, ready for the next workflow and the next agent.
The agent checks each trigger against shared definitions, then either prepares the step or hands the case to its owner. SMBC's Kei Yamamoto set out the arithmetic at UiPath FUSION 2026, Diginomica reports: if each of three steps is 90% accurate, the process is around 73% accurate end to end. SMBC sends high-confidence, low-risk cases through automatically and exceptions to people.
This is where FAIS starts. We model one real workflow in an ontology: a shared description of your customers, parts, drawing revisions, orders, owners and permitted actions. A customer's PO and your ERP sales order are different records, and the model states how one becomes the other. Your ERP, spreadsheets and future agents then work from the same meaning, and we build the automation and its routing rules on top of it.
Why exceptions are the layer agents miss
Diginomica's report of 24 September 2026 finds the rules agents need scattered across outdated procedures, chat threads and experienced employees' memories. UiPath made its Cartographer generally available on 23 September 2026 to draft machine-checkable rules and policies alongside the judgement of experienced staff. Its founder, Daniel Dines, argues that a description covering only the smooth path gives an agent a false picture of the work. Apply that principle to one process at a time, starting with the person everyone asks.
How do you capture order-intake exceptions as business rules?
Sit with that person while real orders arrive, on their schedule rather than in a workshop. For each “it depends”, record five fields:
- Name: a label the team recognises.
- Trigger: the condition that makes the case unusual, stated so it can be checked.
- Decision: what the clerk does today.
- Owner: the person accountable for the rule.
- Escalation: where the case goes when the stakes rise or the owner is away.
When two colleagues describe the same case differently, record an open question for the owner rather than blending the answers. As UiPath's announcement puts it, averaging two answers “produces a third that nobody gave”. The owner signs off the list before development begins.
An illustrative exception map for order intake
Consider a Taiwan maker of machined parts that receives POs by email. Three exceptions the senior clerk handles from memory might look like this:
| Rule | Trigger | Decision | Owner | Escalation |
|---|---|---|---|---|
| Superseded revision | The PO cites an older drawing revision than the current one | Hold the order and confirm the revision with the customer | Sales engineer | Engineering, if tooling is affected |
| Rush date | The requested date is earlier than the standard lead time allows | Check capacity before confirming | Production planner | Operations manager, if another order would slip |
| Price mismatch | The PO price differs from the quoted price | Hold the confirmation and query the customer | Sales manager | Managing director, above a limit the owner sets |
Before: the senior clerk reads each email, checks it by eye, keys the sales order into the ERP and confirms to the customer. Colleagues queue their questions for that clerk.
After: the agent reads the PO, runs the checks and prepares the ERP sales order and a draft confirmation. The order clerk releases routine confirmations; each exception goes to its owner with the matched rule, the PO and the quote. Once results hold, the process owner decides which routine orders may confirm without a release step. The senior clerk spends less time catching problems and more time refining rules.
To test the benefit, track time to a confirmed order, misrouted cases and exceptions nobody had written down.
Start with one process this quarter
Book two sessions with the person everyone asks, record every “it depends” in the five fields and get the list signed. That signed list is the first specification for your automation. If a process in your business runs on a few people's memory, it is worth discussing how to turn their rules into a shared model and an automation your team can see and correct.
Sources
Questions operators ask
Exception capture turns each “it depends” in a process into a named business rule that states what triggers it, what gets decided, who owns the decision and where the case goes next.
What should you record for each order-intake exception?
Record five fields: a name the team recognises, a trigger that can be checked, the decision the clerk makes today, the person who owns the rule, and where the case goes when the stakes rise or the owner is away. The owner then signs off the list.
What if two colleagues handle the same exception differently?
Don't blend their answers. Record an open question for the rule's owner, who decides which version becomes the rule. As UiPath's announcement puts it, averaging two answers “produces a third that nobody gave”.