The quotation process as a ready-made computational model

Inflow: 550 enquiries a year, about 2.2 on a working day, with a day-to-day variation of 26 % and a peak factor of 1.35 on 7 % of days.

The decisive finding. Engineering gives the quotation flow five hours of its day; the rest belongs to live projects. Five hours at 89 % effective time is 267 minutes, and at an average 103 minutes per clarification that is 2.6 cases a day against 2.2 arriving. On paper it fits. On a busy day it does not.

The stress test says exactly that, and it says it as a probability rather than as a verdict:

The column adds up to 100 %, and that is by construction: each run counts exactly one binding step, the one carrying the highest load that day. So "79 %" does not mean "79 % utilised". It means on four days out of five this is the step that caps throughput.

Costing, which the business blames, is the constraint in not a single run.

1. Enquiries per working day. Last year's enquiries ÷ working days. The CRM has it, or the quote numbering does.
2. Peak factor. How many enquiries arrive on the busiest day compared with a normal one? For quotes this is usually seasonal or driven by trade fairs; 1.3 to 1.5 is common. Without it you are computing a process that is never under load, and load is precisely what decides whether a quote goes out in time.
3. Hours engineering gives this process. Not head count. What matters is the share of the day a technical clarifier genuinely has for quotations, usually three to six hours, never eight.
4. The processing range for technical clarification. Low end and high end, not the average. The range is the driver: variation enters waiting time quadratically, while the average enters it only linearly.
5. Approvals per day. How many quotes does the sales lead sign off in a day when there are some waiting? This number decides whether approval is the second constraint. In the template it is, on one day in five.
6. Fully loaded rates per role. Gross salary × 1.5 to 1.8, divided by roughly 1,500 productive hours a year. A €50,000 position therefore costs about €53 an hour, not the naive €24 from salary ÷ 2,080 hours. With the naive rate your statement in money becomes attackable later.

Cross-check before you compute: count the enquiries open today and divide by the quotes you get out in a day (Little's Law). If that lands near your known lead time, the model is usable. A large deviation means a queue is missing, with quotations almost always a query back to the customer, or a supplier price somebody is waiting for.

What the template does not contain. Lead time here is processing plus queueing, in working days. Fixed calendar waits (the three days a supplier needs for a price, the week until the customer calls back) are not modelled. If you have them, enter them as their own step; otherwise the model runs faster than the customer experiences it.

Lever 1. Mandatory fields when the enquiry is logged. The six details engineering always chases anyway are captured at intake. Logging therefore takes longer (15–30 instead of 10–22 minutes) and clarification shorter (45–100 instead of 70–140), because the chasing round disappears. In the model the P90 of lead time falls from 7.2 to 1.6 working days, and engineering's busy-day load from 133 % to 94 %. Time at the intake is cheaper than time in the constraint. That is the whole sentence.

Lever 2. More engineering time for quotations. One extra hour a day. It works, but less than expected: 111 % on a busy day instead of 133 %, and clarification still binds in 56 % of runs. That is the honest price of the fact that an overloaded step does not respond linearly.

Lever 3. A second designer, half time. The most expensive lever, and barely better than lever 1. Compute it anyway and the reason shows: in both cases the constraint moves to approval, and from there engineering no longer caps anything.

Lever 4. Relieve approval. The null result, and the most instructive one. Approval is the second-tightest step at 92 % on a busy day; doubling its takt buys 0.3 days. Because while clarification binds, not enough reaches approval in the first place. A lever on the second constraint is not half a win. It is none.

Compute the four separately and rank by effect per effort. Lever 1 is a form, lever 3 is a headcount, and in the model they are 0.3 days apart.

How 20,000 runs turn into a percentage per step is covered in Monte Carlo simulation for processes; why the spread between P50 and P90 is the real statement, in Understanding P10, P50 and P90.

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

• Lead time before/after as P50 and P90. A commitment to sales is made against the P90, not against the median. Promising "two days" because the median says 0.7 is promising something that breaks on every fifth day.
• Utilisation per step on the busy day and the new constraint after the measure. In this model it moves to approval under the two most effective levers, the normal outcome of a measure, not a mistake.
• Throughput as quotes per week against quotes arriving. As shipped, 10.3 of 11 go out; the difference is not a loss but the backlog the constraint rebuilds every week.
• Annual staff cost effect as a range, from volumes, durations and fully loaded rates. The template computes roughly €254 of working time per quote, of which 941 hours a year fall on engineering.
• The assumption list with every estimated input, stated. The sentence "waiting for supplier prices is 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 79 % comes from, and where the constraint moves once you solve it. The other question (what would you recommend, 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 this page.
• 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 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.