Before you automate anything, show me the weird ones.

Before you write a long brief for someone building your system, find five recent jobs, orders or enquiries that needed extra attention. The one that needed three phone calls. The one someone fixed in a spreadsheet before entering it properly. The one that sat in an inbox because nobody knew who could approve it. The one where a staff member said, “Leave that with me, I know how they like it.”

For each, write down what was supposed to happen, what actually happened, and how it got sorted out. Include the email, the amended order, the note on the job. Whatever helps explain it. You do not need to tidy it into a process document first.

Those examples give us something concrete to work through. They show where information was missing, where a decision was needed, and where someone quietly made the process work.

Take a simple example: an emailed order. On paper, the process might be three steps. Read the email, enter the order, send it to the warehouse. But what does the person entering it actually do?

They recognise that the customer uses an old product name. They know “two boxes” means something different for that account. They notice the delivery address has changed and check whether that was intentional. They apply an agreed price that is not on the standard list. Then they enter the order.

If you only describe that job as data entry, you can build something that copies the email into the order system perfectly and still creates the wrong order.

There is often one person who gets pulled into all of these. They remember which customer needs a purchase order number. They know why a particular quote looks wrong. Their name might not appear anywhere in the process document, but their judgement shows up throughout the working day. Before changing that process, sit with them and work through a few real examples. Ask what they look for and how they know what to do.

Some of what comes out will be straightforward rules you can put into the system. Some will be information that should have been available to everyone already. Some will require experience and should keep coming back to them. A system that removes the typing but sends every decision back to the same person has only solved part of the problem.

Once you start collecting the awkward cases, it is tempting to accommodate all of them. That can get expensive, and it can preserve things the business would be better off changing. Each exception needs a question: why do we do it this way?

An agreed customer price might be a perfectly good rule. Store it against the account and apply it consistently.

A second spreadsheet might exist because the old software could not produce a report. If the new system can produce it, the spreadsheet can go.

An unusual request that happened once might be fine to handle manually. It does not automatically need its own screen, setting and approval process.

And sometimes nobody can explain the exception beyond “we have always done that”. That is a reason to investigate before turning it into permanent software. You are deciding which rules belong in the business as it runs today. Building the system is an opportunity to make those decisions explicit. Those decisions also affect what the system costs to build.

You will not discover every exception before launch. Customers will send incomplete information. An order will arrive in a format nobody has seen. Two records will disagree. Someone will request something the usual rules do not cover. The system needs a sensible way to handle that.

For an order, that might mean holding the uncertain item for review and showing the original request beside it. The person reviewing it should be able to see what is missing, what has already been checked, and what decision is needed. They should not have to reconstruct the whole job from five different places.

This matters especially when AI is reading emails or documents. For a procurement client we built a system that drafts quotes from forwarded supplier emails. Reading the email was the smaller part of the job. Most of the effort went into what happens when the email does not match what the system expects, and making sure a person sees that before a quote goes out.

Extracting something that looks like a price or a product code is only one step. The system still has to check whether it matches the customer, the catalogue and the rules for that job, and when it cannot, someone needs to see the uncertainty before it becomes a packed order or a sent invoice.

Those five examples are useful again when there is something working. Run them through it. Does the customer get the agreed price? What happens when the delivery address changes? Can an amended order be handled after packing starts? Does the invoice reach the right account? Where a person still needs to decide, do they get the information they need?

A clean example can show that the screens work. The awkward examples show whether the system understands the job well enough to help. They also make review easier for your team. Instead of asking them to click around and imagine what might go wrong, you can ask a specific question: would this have handled the order that caused trouble last Tuesday?

You do not need a perfect process before you talk to someone about automation. But the person building it needs access to how the work actually gets done. That includes the corrections, the workarounds and the decisions people make without thinking to mention them.

Bring the normal process. Then bring the weird ones. The normal process will show us where to start. The weird ones will show us what we still need to understand.