Measuring plow-lag and re-accumulation

Here is a scenario every high-density operator knows and few tools can express. Your crew clears a driveway beautifully at 2 a.m. At 3 a.m., the municipal plow comes down the main road and pushes a wall of heavy, wet snow right back across that driveway. The property you marked complete an hour ago is now impassable — and on a static route sheet, it is still just "done."

This is re-accumulation, and its most common cause is the plow ridge. It is one of the biggest sources of angry customer calls in residential snow removal, and it is invisible to any system that treats "serviced" as a permanent state.

Why a fixed list cannot represent it

A route sheet is a list of things to do once. Once a property is checked off, it is off the list. There is no vocabulary in that model for "done, but undone by an external event." So re-accumulation gets handled the worst possible way: reactively, when the customer calls to complain, at which point you are dispatching someone back on an emergency basis and eating the reputational hit.

The plow-ridge problem is not that re-accumulation happens — it always will. It is that a static list has no way to know it happened until the customer tells you.

Making re-accumulation a first-class event

The fix starts by giving operators a way to say more than "done." When a crew finishes a property but the driveway has been re-buried, they should be able to mark it "cleared, but with issues" — a distinct state that acknowledges the work was done and the property is not actually clear. That single distinction turns an invisible problem into a tracked one.

From there, the response can be systematic. Hold the property for a recheck, wait a sensible cooldown (a common default is around 45 minutes — long enough that the plow has likely finished the pass, short enough that the customer is not stranded), and then re-queue the property so the fleet sends someone back. The operator flags the condition; the re-dispatch happens on its own. Along the way you naturally capture how many times a property needed a return trip and how long the lag was — which is data you can actually use.

What to measure

Once re-accumulation is a tracked event rather than a surprise, you can start measuring plow-lag, and it turns out to be one of the more actionable metrics in winter operations.

• Recheck rate by property — which properties routinely need a return trip. These are your problem accounts, and the reason is usually their position relative to a municipal plow route.
• Plow-lag duration — how long between your service and the re-burial. This tells you whether your timing is fighting the municipal schedule.
• Return-trip count per storm — the hidden labor cost re-accumulation imposes, which almost never shows up in a route-based estimate.

Turning the data into decisions

A property that needs a recheck every single storm is telling you something: maybe it should be serviced later in your sequence, after the municipal plow has run, or maybe its contract should price in the near-certain return trip. Without the data you are guessing; with it you can time your service to the plow instead of against it, and price the accounts that genuinely cost more to keep clear.

Key takeaways

• Re-accumulation — often from the municipal plow ridge — is a top source of complaints and invisible to a "done means done" route sheet.
• Give operators a distinct "cleared with issues" state so the problem becomes tracked instead of reactive.
• Hold, cool down (~45 min is a common default), and re-queue automatically — the operator flags it, the re-dispatch is automatic.
• Measure recheck rate, plow-lag duration, and return trips so you can time service to the plow and price the accounts that need it.