The Hidden Cost of Calendar-Based Service | ClearPath

The Hidden Cost of Calendar-Based Service

Fixed-path service runs on a schedule, and every schedule is wrong twice. It sends people to points that didn’t need service, and it misses points that needed service sooner. The fix is not a tighter schedule, because the flaw is the model. The alternative is service that runs on signal, not schedule.

The first error is the trip that didn’t need to happen. Someone shows up to a half-full bin or a stocked dispenser, finds nothing to do, and moves on. The trip still cost labor, fuel, and time, and it produced nothing.

The second error is the opposite, and it is the more expensive one. A point crosses the line between scheduled visits. A bin overflows on day four of a weekly route. A dispenser runs dry long before the round comes back around. By the time the schedule returns, the problem has already happened, and someone else has already noticed.

A single schedule produces both errors at the same time, in the same operation, on the same day. It over-serves the points that were fine and under-serves the points that weren’t, because it was written before anyone knew which would be which.

The first cost hides in plain sight. A wasted trip looks like work getting done. The route ran, the stops got made, the sheet came back clean. The operation records activity, not necessity.

The second cost hides somewhere else. It surfaces as an overflow, a complaint, a missed service level, and it gets filed as a failure of execution. The schedule was always going to miss that point, because a calendar cannot see a container fill or a tank drain.

This is the part worth being exact about. A better schedule has the same flaw. Tighten the cadence and the wasted trips multiply. Loosen it and the missed events multiply. Every fixed schedule only trades one error for the other, because it commits to a plan without knowing the condition of the thing it is servicing. The wrongness is structural. The model carries it no matter how well anyone runs the route.

Once you see the problem this way, the question changes. The goal is no longer finding the perfect schedule. The goal is to stop scheduling work that doesn’t need to happen and start responding to the work that does. That’s the shift behind the idea that service runs on signal, not schedule. The route doesn’t disappear. It shrinks to the points that actually need attention, at the moment they need it.