The six steps
The six steps are a principle, not a template. Every system we build is shaped by them, and no two of the four look alike — what a line means, which rule applies and who may overrule it are learned separately every time. What carries over is the order of the work and what each step has to produce.
Below, one order is taken through all six as an example, including the places each step is usually got wrong.
Take one order as an example
Order 4471-B, line 3. Two hundred and fifty units, due the fourteenth of March. One case out of the kinds an operations inbox produces — it is here because it is ordinary, not because it is difficult.
It arrives three times in three formats, because three different people sent it — and one of them wrote "same as our last one" instead of a specification. Everything below happens to that line.
1 Intake
What arrives. An email with the request in the body. Page two of a PDF, where the table has no ruling and the columns are held apart by spaces. An export from a portal, semicolon-separated, written in 2019 by someone who has left.
What the system does. Reads all three without anyone agreeing a format. Nobody is going to change how they send you work, and asking them to is the request that quietly ends the project.
Where it goes wrong. The temptation is to treat reading as parsing: it either succeeded or it failed. Real intake produces a third thing — how much of what was read can be relied on. A quantity taken from a clean export and a quantity inferred from a sentence are not the same fact, and a system that flattens them has thrown away exactly what the next five steps need.
What to ask. Take a document that failed and ask what the system thought it saw. If the answer is "nothing", intake is a parser.
email "Can you do 250 by the 14th? Same as our last one."pdf · p2 Item 3 250 units delivery 14/03portal 4471-B;3;250;2026-03-142 Structure
What arrives. Text that means a line: a part, a quantity, a term, a date.
What the system does. Turns it into lines matched against your catalogue and your master data, not against a generic dictionary. "250" becomes two hundred and fifty of a specific thing, under a specific agreement.
Where it goes wrong. In your data rather than in ours. The same customer spelled two ways. A part that exists twice because somebody created it again. A unit that means packs in one contract and pieces in another. This is the step where the work turns out to be larger than anyone estimated, and where saying so in week two is worth more than being right in month five.
What to ask. What does it do with a customer that exists twice? Silence is the wrong answer, and so is quietly picking one.
CUSTOMER ITEM QUANTITY DELIVERYNordwerk GmbH line 3 of 9 250 units 14 Marchorder 4471-B · received 14:06
3 Decision
What arrives. Structured lines, each carrying what is known about how reliably it was read.
What the system does. What it can do reliably, and only that. Every result carries the source it stands on, so a person confirms it in seconds instead of redoing the work.
Where it goes wrong. Knowing where reliable stops is most of the engineering here, and it is the part that cannot be bought. A system tuned to decide everything decides some things wrongly and reports none of them. The measure of this step is not how much it handles — it is whether what it hands over is worth handing over.
What to ask. What proportion does it refuse? A system that never refuses has not been calibrated.
"Same as our last one" their order in January
four previous orders, all the same specification · confirmed
4 Exception
What arrives. The line the system will not decide. "Same as our last one", with four previous orders behind it, three identical and one not. A price four percent above the agreed contract price.
What the system does. Routes it to the one person who can answer it, with the question already formed and a clock on it.
Where it goes wrong. Routing is the difficult half. The right person is rarely the one who owns the document: the price question belongs to whoever agreed the price, not to whoever received the email. A queue that routes to a team routes to nobody, and a queue without a clock is a folder.
And the answer does not stop there. It is written down as a rule and goes back into matching, so the same case does not arrive a second time. This is why the exception is the product rather than the error branch — it is the only part of the system that gets better by being used.
What to ask. What happened to the last hundred exceptions, and how many of them were the same question twice?
Their price is 4% above the agreed contract price.
ROUTED TO the account manager who agreed that contract price 14:065 Write-back
What arrives. A confirmed line.
What the system does. Writes it into the system that owns the record — your ERP, in that system's own format, unchanged.
Where it goes wrong. Integration is the step that decides the schedule, and it is the one usually planned last. The integration is two versions behind, or undocumented, or reachable only through an export somebody runs by hand on Tuesdays.
What to ask. When is integration planned? Last is the wrong answer.
order 4471-B · line 3 · 250 units · 14 March · confirmed 14:31
written at 14:31 >>> your ERP6 Record
What arrives. Everything above.
What the system does. Writes what was decided, on what basis, under which version of the rules, and who could have overruled it — as it happens, not afterwards.
Where it goes wrong. A record assembled afterwards is a reconstruction, and it is worth what a reconstruction is worth. The test is not whether a log exists. It is whether the same inputs, re-run today, produce the same result.
What to ask. Take a decision from a year ago and re-run it.
14:06 RECEIVED IN email FROM purchasing
14:06 ASKED OF account manager ABOUT price above contract
14:31 ANSWERED BY account manager AS approved once
14:31 WRITTEN TO your ERP AS line 3 of 9
Four of the six are the ones nobody sells you
Moving data between systems is steps one, two and five, and there are good tools for that. Steps three, four and six — what a result rests on, who is allowed to decide it, and what the record has to hold when somebody asks a year later — are the ones that take longest to build and the ones an operation is eventually judged on.
The same six, four times
Four industries, no shared supplier, regulator or vocabulary between them, and the same six steps under all four. What was learned separately each time is the domain model; the order of the work was not.
Which of the six your problem actually needs is a forty-five minute question. Bring one order that went wrong, with whatever came in with it. We take it through all six on screen, and you leave knowing which steps you need and what the first working piece would be.