All the work is in the orders that go wrong

Every order system demonstrates the same flow: the order comes in, it is paid, picked, packed, shipped and invoiced. That path is well automated almost everywhere, and on a good day most orders follow it without anyone touching them.

Then look at how the order desk actually spends its day. Very little of it goes on those orders. It goes on the others: the ones that stop, split, change or come back to life, and which the system treats as orders that should not exist.

What an exception looks like

The change after picking. The customer wants a different address, an extra item or another colour, and the parcel is already on the packing table.

The missing item. One line out of six is not on the shelf. Wait for it, ship five now, offer a substitute or cancel the line: four decisions, each with consequences for stock, the invoice and the customer.

The order that waits. On hold for payment, for stock, for a price to be confirmed. Waiting is a state, and something has to end it, or the order sits there until the customer phones.

The duplicate. The same order placed twice, through two channels, or once online and once by phone because the customer was not sure the first one had gone through.

The address that fails. The courier rejects it, the parcel comes back, and the order has to be shipped again or refunded.

The edit by phone. A regular wholesale customer adds three items to an order placed online yesterday, and whoever takes the call has to decide where to write it down.

Why systems handle them badly

They are modelled as errors. An order is designed to move forward. Anything that pauses, splits or reverses it becomes a status somebody invented, a notes field, or a tag whose colour means something to one team.

The decision is made outside. Whether to wait or split is agreed by email or shouted across the warehouse, and the system only learns the result. The reason is lost.

Each channel has its own version. The shop, the marketplace panel and the ERP each have their own idea of a held or partial order, and none of them agrees with the others on what happened.

Nobody owns the queue. An exception that is not visible to everyone is an exception waiting to be forgotten, usually until the customer asks where their order is.

What it costs

Time, first: an exception takes minutes of a person, where a normal order takes seconds of a machine. Then errors, such as a partial delivery invoiced in full, a cancelled line still holding a reservation, or a substitute shipped without the customer agreeing to it. And finally the slow cost: no record of why exceptions happen, so the same ones come back every week.

What modelling them properly looks like

Exceptions as real states. Held, partially shipped, awaiting a substitute, cancelled after picking. Named, with clear rules for what each one does to stock and to the invoice.

An owner and a reason. Every exception assigned to someone, with a reason chosen from a short list rather than typed out fresh each time.

The full history on the order. What changed, when, who decided and why. When the customer calls, the answer is on the screen rather than in someone’s inbox.

One queue across channels. Open exceptions from every channel in one place, visible to the whole team, oldest first.

Rules written before they are needed. What happens when an item is missing is a company policy, not a judgement call made differently by each person on each shift.

The measurable version

For one week, ask the order desk to mark every order they touched by hand and to note why. At the end of the week, group the reasons.

That list is your real process. The flowchart describes the orders that run themselves; the list describes the work. Most of it turns out to be predictable, and predictable exceptions are exactly the ones a system should be handling, so that people are free for the ones nobody saw coming.