Order handling as a ready-made computational model

Inflow: 6,000 orders a year, 24 on a working day, with a day-to-day variation of 24 % and a peak factor of 1.3 on 7 % of days. Start of month, call-offs against framework contracts, the last day of a price promotion.

The visits column is the first sign that this template reads differently from the others: steps 03 and 04 do not run once per order but 1.18 times. The reason sits one row below. 15 % of approvals go back to pricing as an exception rather than onward.

The decisive finding. Constraint probability per step, across 20,000 runs:

The column adds up to 100.0 %: each run counts exactly one binding step, the one carrying the highest load that day.

The credit check is the step where the least happens to an order. Nine to eighteen minutes of pulling an agency report, checking the limit, releasing. It is still the binding step in three runs out of four, because it is one person and every order passes through them: 370 usable minutes a day divided by 13.2 minutes of work is 28 orders against the 24 that arrive. On average that is enough. On 30 % of days it is not, and from there the queue grows faster than the utilisation does.

And the two middle rows belong together. 9.7 % plus 9.7 % is 19.4 % of runs, bound by one person who appears on the canvas as two boxes. That is the second most important constraint in the model, and it has no row of its own.

The shared role. Approval (step 04) and the exception decision (step 05) are not two capacities in this template but one resource: the sales lead, 6.5 hours a day at 86 % effective time, so 335 minutes. What the two steps ask of it:

That is 53 % of one person. Measured separately, each step given a capacity of its own, they would read 41 % and 12 %: two comfortable numbers nobody asks about. It is the same work; what differs is the volume you measure it against. Two steps that look comfortable on their own are one person's afternoon.

That is why both boxes read the same utilisation in the model, around 87 % on a busy day. They share one person and therefore share their fate: if that person is out for a day, both steps are out, not one. A model that assumes two independent capacities is quietly modelling two managers who are never ill on the same day.

The rework loop. 15 % of approvals return to pricing as an exception. Back, not onward. That is not a branch but a re-entry, and it has a consequence you cannot see reading left to right: steps 03 and 04 run 1/(1 − 0.15) = 1.18 times per order, the exception step itself 0.18 times.

What that costs, computed against the same model without the loop:

So the loop costs eleven per cent of the working time per order and a good third of the sales lead's day, and it still is not the constraint. This is exactly where two questions people treat as one come apart: "what is this costing me?" and "what is holding me up?" have different answers in this model. The template computes both, and the gap between them is half the story.

Leave a loop out because it is "only an exception" and you lose all three numbers at once: the visits, the cost and the time. A model without the re-entry reads eleven per cent cheaper and 0.7 working days faster than the process is.

1. Orders per working day. Last year's orders (or order lines) ÷ working days. Use the unit the work is actually done in: if a twelve-line order is entered once, count orders; if every line is checked, count lines. Either is right, mixing them is not.
2. Peak factor. How many orders arrive on the busiest day compared with a normal one? Start of month, framework call-offs, the last day of a promotion. A factor of 1.3 to 2 is common. Without it you are computing a sales desk that is never under load, and the credit check tears on exactly those days.
3. Hours the credit check genuinely has for orders. Not the head count of accounts receivable. Somebody also running dunning and matching incoming payments does not have seven hours for credit checks. This single number decides where the constraint sits.
4. The processing range for the credit check. Low end and high end. Two minutes for a regular customer inside their limit, thirty for a new one needing an agency report and a callback. That range drives the waiting time, not the mean.
5. The share of exceptions. 15 % in the template. The figure is rarely in a report but can be counted in an afternoon: how many orders went back to pricing last month? It is the only input in this model that moves cost, utilisation and lead time at the same time.
6. Fully loaded rates per role. Gross salary × 1.5 to 1.8, divided by roughly 1,500 productive hours a year. Do not forget the rate on the shared role: in the template it sits on the resource, not on the two steps. Otherwise an approval is costed at clerk rates.

The one input that is not a number. Before you compute, check who really shares one person here. In the template it is approval and the exception decision. In your business it may be a different pair. Entry and confirmation often sit with the same clerk, pricing and approval with the same sales lead. Every such binding you leave out splits one person across two capacities on paper, and the model then reports two relaxed steps instead of one tight role.

Cross-check before you compute: count the open, unconfirmed orders in the ERP and divide by the orders you confirm in a day (Little's Law). If that lands near your known confirmation time, the model is usable. A large deviation means a queue is missing, here almost always the "waiting for the customer" status.

What the template does not contain. It ends at the order confirmation: picking, shipping and invoicing are deliberately not modelled. That is a different process with a different capacity. Also absent: material availability, callbacks to the customer (calendar time, not working time) and prioritisation. The model works in arrival order. If you genuinely expedite rush orders, model them as a second branch with its own capacity.

Lever 1. The agency check through an interface. The credit agency is queried automatically and a person only decides the cases above the limit or without a match. The check falls from 9–18 to 4–9 minutes. Effect: the P90 of lead time from 5.81 to 0.28 working days, busy-day load from 132 % to 65 %, working time per order from €60.85 to €53.96. The strongest lever in the field, and the only one that needs no staff.

The interesting part sits in the last column. Afterwards the most likely single constraint is "pricing & confirmation" at 41 %. Read only that column and you miss the bigger block: approval and the exception then stand at 25.3 % and 25.1 %, so 50.4 % of runs together. After lever 1 the constraint is no longer a step but a person.

Lever 2. A second person on the credit check. Works almost identically (0.30 instead of 0.28 days) but costs half to one headcount and changes nothing about the working time per order: the same work, spread over two people. The ratio between the two (an interface against a position, 0.02 days apart) is the actual statement of the table.

Lever 3. Exceptions from 15 % to 5 %. Clearer pricing rules, stored conditions, a value threshold below which nothing needs approving. Effect: working time per order from €60.85 to €56.00, load on the shared role from 53 % to 40 %, lead time P90 from 5.81 to 5.20 days. A good result, just not one that solves the constraint: the credit check afterwards binds more runs, not fewer (89 % instead of 74.7 %), because the competition for the title has gone. The lever relieves a person and saves money; it barely improves what you can promise a customer.

Lever 4. Split the shared role. The first null result, and the more uncomfortable of the two. Approvals go to a second manager, exceptions stay with the first. The two steps drop to the comfortable 41 % and 12 % from section 02. Lead time P90 falls from 5.81 to 5.31 days, working time per order stays at €60.85, and the credit check's constraint probability rises from 74.7 % to 86.6 %: the shadow constraint is gone, the real one stands where it was. The shared role is a correct finding and still not a measure, as long as the credit check sits in front of it. It becomes one the moment lever 1 or 2 has run; after that it binds half of all runs. A question of sequence, not of selection.

Lever 5. Order entry via EDI or a customer portal. The second null result, and the single most common recommendation in this family of processes: orders arrive by e-mail and get typed in; a portal or an EDI feed removes that. Entry falls from 8–17 to 3–7 minutes and working time per order from €60.85 to €54.12. Lead time on a busy day: from 5.81 to 5.79 days. Which is nothing. Entry runs at 55 % utilisation and 74 % on a busy day. It never held the process up. The measure is right; the justification "this will make it faster" is not. It saves €6.73 per order, and at 6,000 orders a year that is an argument in its own right, just a different one.

Compute the five separately and rank by effect per effort. Two of five move the lead time; three move money or utilisation. Both are results, as long as one is not sold as the other.

How 20,000 runs turn into a percentage per step is covered in Monte Carlo simulation for processes; why 85 % utilisation is already too much, in How to calculate a bottleneck.

After saving the baseline, changing one lever and running a second time, the comparison produces:

• Lead time before/after as P50 and P90. The median says 0.16 working days. Promise sales "confirmed same day" on the strength of that and you are wrong on every tenth day, by almost six working days. A commitment is made against the P90, not against the median.
• Utilisation per step on the busy day and the new constraint after the measure. In this model it moves to "pricing & confirmation" under two of the five levers, and behind that waits the shared role, carrying the larger block.
• Utilisation per shared resource, separately from the steps. This is the figure no step row can show: 178 of the sales lead's 335 minutes, spread across two boxes.
• Throughput as confirmed orders per week against orders arriving: 112 of 120 as shipped. The difference is eight orders left sitting every week.
• Working-time cost per order and per year, from volumes, durations and fully loaded rates. The template computes €60.85 per order, €6.90 of it attributable to the exception loop.
• The assumption list with every estimated input, stated. The sentence "picking, shipping and invoicing are not modelled" takes the sting out of the sharpest question before it is asked.

That is exported as two PDFs: a proposal for the decision maker and documentation for traceability, with your letterhead if you have set one.

One model, two questions. This page answers the arithmetic one: where the 74.7 % comes from, why two boxes show the same utilisation, and what a 15 % re-entry costs in time and money. The other question (what would you recommend, and what does an order waiting three days on a credit report cost) belongs to the method rather than the tool. It lives next door in the Flowrefy analysis archive, alongside the approach these templates came out of. One dataset, two questions, two audiences.

• Order handling is this page. The first card in the gallery and the only case with a shared role and a rework loop.
• Quotation process is the case where lead time acts on revenue rather than on cost.
• Invoice approval is the volatility case: under capacity on average, over it at month end.
• Complaint handling puts the constraint outside the company, so the honest recommendation is not "automate".
• Employee onboarding has low volume and many participants, with one step that binds 86 % of runs.
• IT service desk is the case with a branch: 65 % solved on the spot, 35 % escalated to second level.

Every template opens from the welcome window via Browse templates. The first time round it is worth opening one before starting your own model. Otherwise people build too finely.