Where AI belongs in a workflow, and where rules are better

Take a process almost every company has: customers email to change an order. A different delivery date, two more pallets, a new delivery address. Someone reads the email, finds the order in the ERP, checks whether the change is possible, updates it and writes back.

When people first look at automating this, the instinct is to hand the whole thing to an AI model. Read the email, figure it out, update the system, reply. It demos well. It's also the wrong design, and it tends to break in the second month.

Split the process into steps first

Before deciding anything about AI, write the process down as a list of steps. Not the tidy version from the process handbook, the real one, including the part where Sandra checks the stock in a separate Excel file because the number in the ERP is never quite right.

For the order-change example you end up with something like this:

1. 01Read the email and work out what the customer wants.
2. 02Find the order number, the new date or quantity, and who is asking.
3. 03Look up the order in the ERP.
4. 04Check whether the change is allowed (cut-off times, stock, credit limit).
5. 05Update the order.
6. 06Reply to the customer.

Now go through the list and ask one question per step.

The question: judgment or rule?

Could you write this step as a rule on a whiteboard, one an intern could follow without asking you anything? If yes, it's a rule, and it belongs in code. If the honest answer is "it depends" or "usually", you've found a step where AI can help.

Steps 1 and 2 need judgment. Emails arrive in German, French and English, sometimes all three in one thread. Order numbers hide in signatures, in subject lines, in a forwarded PDF. One customer writes "same as last time, but Thursday". A language model is very good at turning that kind of mess into a clean, structured record: what's wanted, which order, which date, and how sure it is.

Steps 3 to 5 are rules. Is the order in the system? Is the new date after the cut-off? Is there enough stock? Each of these questions has exactly one correct answer, and you want that answer every single time. A model will get them right most of the time. "Most of the time" isn't good enough for something that changes a delivery. (It's also slower, and every call costs a little, which adds up at a few thousand emails a month.)

Step 6 is judgment again. Writing a polite, correct reply in the customer's language is something models do well, as long as the facts in that reply come from step 4 and not from the model's imagination.

AI at the edges, rules in the middle

The pattern that falls out of this is nearly always the same. AI sits at the edges of the process, where messy input comes in and human-readable text goes out. Rules sit in the middle, where decisions are made and systems are changed.

In practice that means the model never touches the ERP directly. It produces a structured result, something like "order 48213, change delivery date to 14 November, high confidence", and ordinary code takes it from there. If the code says the change isn't possible, the model is given that fact and drafts a reply that explains it. It doesn't get to argue.

There's a useful side effect. When something goes wrong, you can see where. Either the extraction was wrong (compare the email with the structured record) or the rule was wrong (look at the code). With one big AI step you get a wrong outcome and a shrug.

Plan the exceptions before the happy path

No extraction is perfect. Some emails are genuinely ambiguous, some customers ask for things your rules don't cover, and sometimes the model simply isn't sure. That's fine, as long as you've decided in advance what happens then.

The goal isn't 100 percent automation. It's that every case ends up in one of two places: handled automatically, or in front of a person with everything already prepared. The order is found, the request is summarised, and one line says why the case stopped. That person then needs thirty seconds instead of five minutes.

We'd rather start with a cautious threshold, where more cases go to a person, and loosen it once the numbers show it's safe. Going the other way (start aggressive, clean up later) is how automation projects lose the trust of the people who have to live with them.

A quick check for your own process

A few signs that a step is a good fit for AI:

• the input is free text, a scan, or a document without a fixed layout
• the same thing gets expressed in many different ways, or languages
• the output is a draft that a person reads anyway

And a few signs it should be a plain rule:

• there's one correct answer, and it has to be the same every time
• the step changes money, stock, contracts or access rights
• you'd have to explain the decision to an auditor

If you're still unsure, write the step as a single sentence. If the sentence contains "always", write the rule. If it says "usually" or "it depends", that's where a model earns its keep.