An automation can read an order correctly and still have no basis for choosing the right product. The trouble starts when the system can list the possible answers but can't safely treat any of them as the correct one.
Take a simple example: a B2B customer orders "module Z, industrial version". The catalog has two products that match that description: one runs on 24 V DC, the other on 230 V AC. They aren't interchangeable. The order contains every field the current process requires, but it doesn't say which power supply variant is meant. The data available to the automation doesn't settle it either. There's no standing agreement with the customer, for instance. Get it wrong and you may end up shipping the wrong goods, dealing with a complaint and fulfilling the order a second time.
You could force a choice, block the whole order or ask an employee to approve one of the suggestions. None of these removes the uncertainty on its own. You need to define which decision can't be made yet, what work can carry on in the meantime and where the basis for settling it will come from.
When is a missing answer a real exception?
Not every stop in an automation needs its own exception path. A missing field that the form clearly marks as mandatory can be caught by validation. If a product description has a current, approved mapping to a specific item number, the system can apply it automatically. And if nobody knows whether the command to save the order in the ERP actually went through, that's a problem with how the system runs, not with choosing a product.
The order in our example is a different kind of problem: the process treated the data as complete, even though it isn't enough to choose between two non-interchangeable items. The company has no grounds for guessing which variant the customer meant. That's a genuine business exception given the way orders are currently handled.
If situations like this keep coming back, the sensible fix may be to change what an order has to contain: make the supply voltage mandatory, or approve a rule for reading the variant from agreed documents. There's no point keeping a queue of manual decisions for a case that a clear rule can settle.
Until there's a basis for the choice, the automation should block approval of the ambiguous line and the activities that depend on that choice, not the entire order by default. It can check the other lines and prepare a draft document. Fulfilling those lines separately is acceptable only if the commercial terms and the dependencies within the order allow it. How much gets put on hold should follow from the consequences of a mistake and how easily it can be reversed, not from what's convenient to configure.
People need a basis for the decision, not an "approve" button
Handing an uncertain result to an employee helps only if they can add something new: check a document the system can't see, apply specialist knowledge, use an authority the system doesn't have or go back to whoever holds the information. If all they see is the same description and the same two variants, a manual approval is still a guess. Why human approval has to apply to a specific decision is covered in the article on the limits of AI autonomy.
In this case the employee should see the original order, a comparison of the 24 V DC and 230 V AC variants, and the customer's current documents. If a current appendix to the contract settles the variant, it can serve as the basis for the decision. If the choice depends purely on what the customer had in mind and never said, ask the customer rather than asking the operator to guess.
The exception card: what to agree on for one class of cases
To design a path like this, the process owner can use an exception card. It's a practical tool proposed by Codino, not a formal standard. The step handover card from the previous part covers an ordinary handover, where a task simply passes from one team to the next. The exception card is mainly about the limits of the permitted decision, how the evidence is obtained and what happens to the case if nothing settles it.
| Point | Example order handling process |
|---|---|
| 1. Decision limit: what must not be guessed? | Neither the 24 V DC nor the 230 V AC variant may be chosen on the strength of the description "module Z, industrial version" alone |
| 2. Controlled hold: what do we block? | Don't approve the ambiguous line or release it for picking. The other lines can be verified, but fulfilling them separately needs its own business justification |
| 3. Evidence: what can settle it? | The original order, the current catalog, a current contract appendix, approved customer mappings or a clear answer from the customer |
| 4. Resolution path: who acts, and when? | An order specialist checks the documents by the end of the next working day. If the documents settle nothing, the account manager asks the customer directly: "24 V DC or 230 V AC?" If the customer doesn't reply within, say, two working days, the account manager follows up and passes the case to the sales manager, who decides on a new deadline or on how to proceed under the contract |
| 5. Permitted decisions: who decides, and on what basis? | An authorized employee confirms the variant only on the basis of a current document or the customer's answer. Without evidence, the line stays on a controlled hold. Any decision to decline the line is approved by the sales manager, if the contract terms and company rules allow it |
| 6. Outcome and record: what happens to the case? | The line is ready for standard fulfilment, is waiting for a specific piece of information with a named next action, or has been formally declined. The record covers the outcome, the source of the evidence, the person responsible and the date |
The roles, deadlines and authorities in the table are assumptions made for the example, not universal rules. What they look like in practice is for the process owner to decide. The card is there so that these decisions get made before anyone configures a tool. It isn't meant to add another form or an elaborate set of statuses.
Two resolutions and one controlled hold
It helps to distinguish closing the exception from properly putting the decision on hold. In our example there are two possible business resolutions and one interim state.
The product has been confirmed. The specialist finds a current contract appendix showing that for this customer "module Z, industrial version" means the 24 V DC variant. They check that the clause covers the current order, and then an authorized person confirms the variant and records the source. The line can go back to standard fulfilment. That closes the exception, though not the whole order.
We're waiting for a specific answer. The available documents don't settle it. The account manager asks the customer about the supply voltage, and the line stays blocked from fulfilment. The case record shows the person responsible, the question and the date of the next check. If no answer comes, the account manager follows up and the manager decides what happens next under the contract: set a new deadline or start the procedure for declining the line. "Awaiting clarification" on its own doesn't close the exception. Every extension needs a reason, an owner and a next checkpoint.
The line is declined. If the required specification can't be obtained, and the contract and company policy allow the line to be declined in that situation, an authorized manager makes that decision and records it. The customer is informed accordingly. This is the second state that can close the exception. It shouldn't be confused with automatically rejecting an order once some arbitrary deadline has passed.
There's also a situation that needs none of these paths: the company has, for this customer, a current, unambiguous mapping from the product name to the 24 V DC variant, and nothing contradicts it. An approved rule can then settle the case with no manual approval. A recurring case should stop being an exception once the company can safely describe how to resolve it.
How can you tell the exception handling works?
Instead of starting by building a universal exception queue, ask the process owner to test one class of ambiguous orders. Acceptance should be about how the process behaves in specific scenarios, not about the mere fact that someone ran a test.
| Test scenario | Pass condition |
|---|---|
| Two non-interchangeable variants, no evidence | No variant is picked automatically for the ambiguous line, and the line isn't sent for fulfilment |
| A current appendix clearly points to 24 V DC | An authorized person confirms the right variant, and the case record cites the current document the decision rests on |
| Only the customer knows the required variant | The customer gets a precise question, and the case has an owner and a date for the next action |
| The customer confirms 230 V AC after being asked | On the basis of a clear answer, an authorized person confirms the variant, records the evidence and releases the line for standard fulfilment |
| The customer doesn't reply in time | The agreed follow-up or the manager's decision has been triggered, and the line isn't left without an owner indefinitely |
| Nothing settles it, and the contract allows the line to be declined | An authorized person makes a formal decision in line with the terms, records the reason and informs the customer |
| An approved mapping exists and no data contradicts it | The system applies the rule with no unnecessary manual approval |
| The order also contains unambiguous lines | Permitted independent activities can continue, without automatically assuming a partial shipment is allowed |
An example result for one test: the system recognized two variants and approved neither, the account manager sent the question "24 V DC or 230 V AC?" and has a date set for checking the reply. The other lines remained available for validation but weren't shipped without authorization. This test scenario passes, because the decision was properly held back and the route to settling it was defined. The choice of variant is still waiting for information, though, so the whole path hasn't passed yet. Handling the customer's answer has to be tested separately, and so does formally closing the case when it can't be resolved. The scenario would have failed if the system had guessed the product, or left the line in a vague "to be checked" status with nobody responsible and no date.
These are hypothetical acceptance criteria, not results from a Codino implementation. They confirm the logic of the path, not how often exceptions really occur or what the operational savings are. Those effects have to be measured separately.
Automation doesn't have to settle every situation. It does have to draw a clear line between the decisions it has a basis for and the ones that can't be made yet. Then an unusual order doesn't end in guesswork, in all the work grinding to a halt for no reason, or in a case left "to be checked" forever.