Why your 2 p.m. arrival window keeps slipping: the capacity math behind on-time promises

Your 2 p.m. arrival window doesn't slip because your techs are slow. It slips because the board was planned on averages, and arrival windows break in the tail of the distribution, not in the middle. On paper, four 80-minute jobs with 25 minutes of drive between them put the fourth arrival at about 1:50 p.m., comfortably inside a 2 to 4 window. In our simulation of that exact day, the median arrival really was about 1:50. But once real-world job-time variability and the odd emergency were added, the fourth customer got a late tech on roughly one day in six.

This post is about the capacity math for arrival windows: why the average plan hides the risk, what operations research has known about it for sixty years, and five scheduling rules that buy back on-time arrivals without adding a truck.

The arrival window is a promise about a percentile

Most dispatchers think of a window as "when the tech will probably get there." The customer hears something different: "you'll be here by 4." That gap is the whole problem.

If you plan from averages, you are promising the median arrival. A median is, by definition, late half the time relative to itself. The window width is your only protection, and a 2-hour window gives you exactly as much protection as the slack between the planned arrival and the window's end.

So the useful question is not "when will the tech get there?" It's "by what time will the tech get there on 9 days out of 10?" That time is the 90th percentile arrival, and it's what your window end has to cover.

Every term in that sum is a random number. Adding random numbers together adds their spread, and the later in the day a job sits, the more random numbers are stacked in front of it. That is why the 8 a.m. window almost never fails and the afternoon window fails far more often.

Why job durations have a long right tail

Service work has a hard floor and no real ceiling. A capacitor swap can't take less than about 20 minutes once you include the walk-around, but it can take three hours when the "capacitor" turns out to be a burned contactor, a rubbed-through low-voltage wire and a customer with questions.

Durations shaped like that, bunched near a typical value with a long tail to the right, are commonly modeled with a lognormal distribution. The idea has deep roots in the research on surgical case times, another field where "how long will this take?" drives a schedule of promised start times. A 2018 analysis of a surgical department's data, for example, found a lognormal approximation of total surgery duration suitable for estimating the chance an operating room runs into overtime.¹ We used the same shape for the simulation below.

You can measure your own spread without any statistics package. Pull 90 days of completed jobs for one job type and compute:

A CV around 0.25 means jobs of that type are predictable, like a membership tune-up. A CV of 0.75 to 1.0 is typical of "no heat" or "no cool" diagnostics where the job can turn into anything. Those two numbers will drive your board far more than the averages do.

A worked simulation: 40,000 Tuesdays

To make this concrete, we simulated one technician's day 40,000 times. All inputs are hypothetical, chosen to look like a typical residential service day. Use your own numbers.

• Four booked jobs, each averaging 80 minutes on site.
• Four 2-hour windows: 8 to 10, 10 to 12, 12 to 2 and 2 to 4.
• Drive time averaging 25 minutes between stops, with modest spread (CV 0.4).
• If the tech arrives before a window opens, they wait for it. They never start early.
• Variability (CV of on-site time) tested at 0.25, 0.5, 0.75 and 1.0.
• Emergency insert: in one version, on 25% of days an urgent call is slipped in after one of the first three jobs, adding a drive and a 75-minute visit.

The average of every input is identical across scenarios. Only the spread and the emergency change.

Worked example, hypothetical inputs. Monte Carlo simulation, 40,000 days per row, lognormal job and drive times.

Read the median column first. It barely moves: 1:50 to 2:12 across every scenario. A dispatcher who looks at the "typical" day sees a board that works. Now read the 90th percentile column. It swings from 2:35 to 5:23. That is the column your customers live in.

An 80% on-time rate for the last window sounds survivable until you count it. At four jobs a day, five days a week, that's about one broken promise per tech per week from the last slot alone, before you count the 10 to 12 and 12 to 2 windows that are also leaking.

The queueing law that explains the afternoon

None of this is new. Two results from 1961 explain almost everything above.

Kingman: waiting explodes as the board fills

J.F.C. Kingman's work on queues in heavy traffic led to what's now called Kingman's formula, an approximation for the average wait in a queue.² In plain terms it says wait time is the product of three things:

Here u is how full the resource is, CVa is the variability of arrivals and CVs is the variability of service times. Owners usually feel the utilization term in their gut without ever seeing it written down. Here is what it does:

Going from 80% to 90% booked doesn't add 10% more waiting. It more than doubles the utilization term. And the variability term multiplies it: halve the spread of your job times and you cut the wait by far more than you would by adding a little capacity.

This is the reason a board that's "only" 90% full on a July afternoon can feel like it's on fire. It isn't 10% from trouble. It's on the steep part of the curve.

Little's Law: your backlog is your lead time

John Little proved in 1961 that, for a stable system, the average number of items in it equals the arrival rate times the average time each spends inside: L = λW.³ Fifty years later Little noted that the result had become widely known simply as Little's Law, and that it holds under very general conditions.⁴

For a service shop, it gives you a fast sanity check on booking promises:

Say your board holds 96 open booked jobs and your crew completes about 32 a day. Customers are waiting, on average, three days. If the CSR is promising "tomorrow" to every caller, the math says some of those promises will break, and they'll break somewhere in the afternoon.

What actually buys back on-time arrivals

We reran the simulation with the same four jobs (CV 0.75, emergencies on 25% of days) and tried five fixes. The on-time rate is shown for each window in order.

Worked example, hypothetical inputs, 40,000 simulated days per row.

Then we tested job order. Same four jobs, same total work: one long diagnostic (120 minutes on average, CV 1.0), one average call and two short, predictable tune-ups.

Worked example. Same jobs, same drives, same emergencies; only the order changes.

Nothing about the work changed. Only the order did. When the uncertain job goes first, its tail is stacked in front of every promise that follows. When it goes last, its tail lands mostly on the tech's own clock instead of on three customers.

1. 1

   Sequence by uncertainty, not just geography

   Put predictable jobs (tune-ups, scheduled maintenance, known repairs) in promised windows early in the day. Put high-variance diagnostics and anything that could turn into a replacement where its overrun hurts fewest customers: last, or in a wide window.

2. 2

   Size the last window for the 90th percentile

   Use your own on-site time data to find when the last arrival lands on 9 days in 10. If that's 4:45, a 2-to-4 window is a promise you can't keep. Widen it, or book one fewer job.

3. 3

   Keep emergencies off promised routes

   Inserting an urgent call into a full route moves every later window. A rotating flex tech, or a lane kept partly open on peak days, protects the promises on everyone else's board.

4. 4

   Cap booked hours below 100% on purpose

   Kingman's curve says the last 10% of utilization costs the most in waiting. Decide your ceiling (many shops land somewhere around 80 to 85% of bookable hours for promised work) and leave the rest for the day's surprises.

5. 5

   Quote lead time from Little's Law

   Backlog divided by daily completions is the honest wait. Give CSRs that number each morning so 'tomorrow' is only promised when tomorrow exists.

Measuring whether your windows hold

You can't manage what you haven't defined, so write the definition down before you build a report.

• Window hit rate: arrivals inside the promised window ÷ all appointments with a promised window, by window slot. Report the 8 a.m., midday and afternoon slots separately. A single blended number hides exactly the pattern this post is about.
• Minutes late, 90th percentile: for late arrivals only, how late the worst 10% were. A shop that's late by 10 minutes and one that's late by 2 hours can have the same hit rate.
• On-site time CV by job type: recompute monthly. If a job type's CV is rising, the booking questions or diagnosis for that call type need work. The first-time fix rate post covers that side.
• Booked utilization by lane: booked hours ÷ bookable hours. Watch the share of tech-days above 90%.
• Backlog lead time: open booked jobs ÷ average daily completions, as above.

Communicate inside the window, not only before it

Even a well-sized window leaves the customer waiting for a stretch of their day. In his classic essay on the psychology of waiting lines, David Maister argued that uncertain waits feel longer than known, finite waits, and unexplained waits feel longer than explained ones.⁵ Those two propositions are the case for the on-my-way text.

Practically:

• Send an on-my-way text with a real estimated arrival when the tech leaves the previous job, not at window start.
• If the 90th percentile model says a window is at risk, call before it's missed. A call at 2:45 that says "3:30" lands very differently from silence until 4:10.
• Offer an earlier slot to customers who want one when a job finishes early. In TradesWork, the dispatch board can text tagged customers when a cancellation or early finish opens time, and books the first yes after re-checking capacity.

app.tradeswork.app · Dispatch board lanes showing jobs by technician and time

Who this doesn't apply to

If you run route-based recurring work (lawn, pest, pool) with no promised windows, the arrival math matters much less than route density. If most of your days are single all-day installs, the window problem collapses into "start time and crew readiness." And if you're a one-truck shop, you already feel all of this personally; the fix is mostly honest windows and early phone calls.

For everyone running three to fifty trucks of demand service, the arrival window is where your capacity plan meets the customer. Plan it as a percentile, sequence by uncertainty, and keep the last 10% of the board for the day you actually get. For how utilization fits beside productivity and efficiency, see the three tech metrics owners mix up. For background terms, the glossary covers arrival windows, capacity and route optimization, and the dispatch board and AI dispatcher pages show how TradesWork handles both.