Why do so many booked jobs never actually happen?

One status, four different failures

Most systems collapse this into a single canceled flag, which makes the number useless. A job canceled because a competitor came first is a competitive loss. A job canceled because your dispatcher moved it twice is an operational loss. A no-access call is a capacity loss that also consumed drive time. They need different owners and different fixes.

Adding a required reason code at cancellation is the cheapest possible improvement here, provided the list is short and mutually exclusive. Long dropdowns get answered with whatever is first.

The four buckets and what each responds to

• Solved elsewhere while waiting. Strongly correlated with days between booking and appointment. Shorten the gap or confirm earlier, and this shrinks. It is the bucket that connects directly to capacity.
• No access. Nobody home, gate locked, tenant not notified, unit unreachable. Fixed at confirmation with specific questions, not with a generic reminder text.
• Rescheduled into oblivion. You moved them, then moved them again, and the follow-up never closed. Almost always a process gap rather than a customer decision, and almost always invisible because the record still shows an open appointment somewhere.
• Never firm. Tentative holds, quotes pending approval, and jobs waiting on parts or permits. These were never really booked and should not be counted as bookings in the first place.

Measure the gap, not just the rate

Plot cancellation rate against days between booking and scheduled date. In most repair-heavy shops the curve rises sharply after a couple of days. That single chart tells you what a shorter promise date is worth without any experiment.

Also track cancellations by who initiated them. A rising share of company-initiated moves is an early warning that dispatch is over-committed, and it shows up before utilization or revenue does. Pulling appointment history including the moves — not just the final state — is the part that takes real integration work, because most platforms overwrite rather than version the schedule.

Close the loop with confirmation that does something

Confirmation is only useful if it collects information and can act. A message that asks whether access will be available, whether the problem still exists, and whether the window still works will surface cancellations early enough to refill the slot — which is the entire point.

The refill is the part shops skip. A cancellation known at eight in the morning is a recoverable slot; one discovered at the door is a lost half-day. Wiring the confirmation response back into dispatch so the slot is offered to a waiting customer is a straightforward piece of operational automation and one of the higher-return ones.