Complaint handling as a ready-made computational model

Inflow: 1,900 complaints a year, about 7.6 on a working day, with a day-to-day variation of 28 % and a peak factor of 1.3 on 7 % of days.

Step 03 carries an hourly rate of €0 in the template. That is not an oversight, it is somebody else's working time. It costs you no payroll. It costs you lead time, all of it.

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

The column adds up to 100 %: each run counts exactly one binding step, the one carrying the highest load that day. On 94 days out of 100, that is clarification with the supplier.

Of the 85 minutes of processing per case, 44 fall on that single step, and none of them are yours. More than half of this process belongs to somebody you do not manage.

1. Complaints per working day. Last year's cases ÷ working days. The ticketing system has it, or the credit-note report does.
2. Peak factor. Complaints rarely arrive evenly: a bad batch, a change of supplier, a season. A factor of 1.3 to 1.8 is common. Without it you are computing a process that is never under load.
3. Throughput of the supplier clarification. The most important number in the template, and the only one you have to estimate rather than measure. How many cases does your supplier clear in a day when several are waiting? Not how long a single clarification takes, which is a different thing and goes in at number four.
4. The processing range for the clarification. Low end and high end. External steps have wide ranges, and the width is the driver: variation enters waiting time quadratically, the average only linearly.
5. The share of cases that go to the supplier at all. In the template it is all of them. If some are decided in house, enter a decision with a routing share. That is the lever section 03 identifies as the strongest.
6. Fully loaded rates per role. Gross salary × 1.5 to 1.8, divided by roughly 1,500 productive hours a year. Leave the external step at €0. Otherwise you are booking somebody else's working time as your cost, and the statement in money falls apart.

Cross-check before you compute: count the complaints open today and divide by the cases you close in a day (Little's Law). If that lands near your known lead time, the model is usable.

What the template does not contain. Lead time here is processing plus queueing, in working days. A contractual response window ("the supplier replies within five working days") is calendar time, not capacity. If you have one, enter it as its own waiting step; otherwise the model runs faster than the customer experiences it.

Lever 1. Automate every internal step. A portal instead of the phone at intake, a rule-based internal check, an automatic credit note. Working time per case falls from €40.33 to €25.45 in the model, down 37 %. Lead time on a busy day falls from 5.62 to 5.58 working days, down 0.7 %.

Both statements are true, and the gap between them is the reason this template exists. The saving is real; the speed promise in the proposal is not. Measure the project on lead time (and the business will, because that is what it complains about) and you get a technically successful project that lands as a disappointment.

Whether the 37 % becomes money is a second question: throughput is still capped at the supplier. The same volume gets handled, only more cheaply.

Lever 2. Shorten the clarification itself. Not chasing faster, but chasing differently: batched clarifications instead of case by case, a complete document set on the first attempt, one named contact. That pulls the range from 30–60 down to 20–40 minutes, and the P90 of lead time from 5.62 to 0.25 days. The only lever in this table that genuinely moves lead time is the one on the external step.

Lever 3. A second channel or an escalation route. A second route to the supplier for cases above a value threshold. It works (5.62 → 1.05 days), but it depends on the other party playing along, the one quantity in this model you do not control.

Lever 4. Relieve the internal check. The null result. The internal check sits at 69 % on a busy day and therefore looks like the second candidate. Raise its takt by half and lead time moves by 0.03 days, while the supplier step's constraint probability rises from 94 % to 95 %. It was never the problem. It was only standing next to it.

So the honest recommendation of this template is not "automate". It is: compute first whether the measure lands where the process actually stalls. That takes twenty minutes and decides an investment.

Why a constraint probability of 94 % does not budge under automation, and actually rises to 95 % when you relieve the wrong step, is covered in Monte Carlo simulation for processes. How to read utilisation at all, 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. For this template the comparison is the result: lever 1 moves the P90 by 0.04 days, lever 2 by 5.4.
• Utilisation per step on the busy day and the constraint afterwards. It stays where it was under three of the four levers. That too is a finding, and the most expensive one you can have before an investment.
• Throughput as cases per week against cases arriving: 35.6 of 38 as shipped.
• Working-time cost per case and per year, from volumes, durations and fully loaded rates, with the external step at €0, so that somebody else's time does not appear as your cost.
• The assumption list with every estimated input, stated. For this template above all the supplier's throughput: the one number in the model you cannot measure.

That is exported as two PDFs: a proposal for the decision maker and documentation for traceability, with your letterhead if you have set one. The "Reviewed options" page names the variant that is not worth doing, explicitly.

One model, two questions. This page answers the arithmetic one: where the 94 % comes from and why an internal measure does not move it. The other question (what would you recommend here, and what does doing nothing 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 runs from the order to the confirmation. The case with a shared role: two steps that look comfortable on their own are one person's afternoon.
• 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 is this page.
• Employee onboarding has low volume and many participants, with one step that binds 86 % of runs.
• IT ticket shows classic queueing behaviour 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.