RunSheet
Back to blog

RunSheet Blog

COD Routing: Why Most Route Planners Get It Wrong

June 12, 2026 · 6 min read

Cash on delivery looks like a small wrinkle. The driver collects a payment, hands over the goods, moves on. But COD quietly breaks more delivery routes than almost anything else, because a COD stop isn't just a delivery — it's a delivery that can only happen when a specific person with money is standing in a specific place at a specific time.

Most route planners treat COD as a label. You tag a stop "COD," the software shows a little dollar icon, and then it sequences that stop exactly like every other one. That's the bug. This post explains what COD delivery route planning actually requires, why "labeling" isn't enough, and how VRPTW — the algorithm that does it properly — works in plain language.

Why a COD stop is different from a normal stop

A normal delivery is forgiving about timing. Nobody home? Leave it at the door, snap a photo, done. The stop succeeds whenever the driver arrives.

A COD stop is the opposite. It only succeeds inside a narrow window of conditions:

  • Someone has to be there. You can't leave a cash-on-delivery package on a porch and hope. The payer has to be present.
  • That someone is only there at certain times. The shop owner who pays your COD invoice is at the register from open until lunch, then gone. The restaurant manager signs for the supply order before the dinner rush, not during it.
  • A miss is expensive twice. If the driver arrives when nobody's there to pay, you've burned the trip and you have to send someone back. The cost of a wrong sequence is double a normal stop.

So a COD stop carries a hard time window by its nature. "Deliver to this restaurant between 9am and 11am, because that's when the manager is there with the cash." If your route ignores that window, the stop fails, even though the software thought it planned a perfectly efficient route.

Where most planners go wrong

Here's the failure in detail. A basic route optimizer's job is to minimize total drive time. You give it 18 stops, it finds the shortest path through all of them, and it hands you a sequence. If you've labeled three of them "COD," a simple optimizer does one of two unhelpful things:

  1. It ignores the label entirely and sequences purely for distance. Your COD restaurant lands at 1:45pm, deep in the lunch rush, manager nowhere near the till. Failed stop.
  2. It "respects" the window by waiting. Some optimizers handle a time window by routing the driver to the stop early and then parking — having them sit in the van for 40 minutes until the window opens. Technically the window is satisfied. Practically you're paying a driver to wait, and the rest of the route slides.

Both are wrong for COD. The first ignores reality. The second is technically correct and operationally useless. What you actually want is a route where the COD stop is placed in the sequence at a time that lands inside its window naturally, without a wrong-time arrival and without dead waiting.

That requires the optimizer to treat the time window as a hard constraint while it's building the sequence — not as a label it slaps on afterward, and not as something it patches by idling the driver. That's a meaningfully harder problem, and it has a name.

VRPTW, in plain language

VRPTW stands for the Vehicle Routing Problem with Time Windows. It's the version of route optimization that bakes timing rules into the math from the start.

Strip away the jargon and it's three nested questions the solver answers at once:

  1. Which stops go to which driver? (Vehicle Routing — splitting the work across the fleet.)
  2. In what order should each driver visit their stops? (The sequencing problem — the part Google Maps doesn't do.)
  3. Does every stop land inside its allowed time window? (The "TW" — the constraint that COD lives and dies by.)

A plain route optimizer answers questions 1 and 2 and ignores 3. A VRPTW optimizer refuses to produce a sequence where a stop falls outside its window. If your COD restaurant can only be served 9–11am, the solver will only return routes where that stop is visited in that range. It works the whole sequence around that rule instead of pretending the rule doesn't exist.

The reason most cheap tools skip it is that VRPTW is genuinely harder to compute. It's easy to find a short path. It's much harder to find a short path that also satisfies a dozen overlapping timing rules without making the driver wait around. That's the engineering most "route planners" quietly don't do.

What "doing it right" looks like in practice

RunSheet was built around VRPTW specifically because COD and time windows are everyday reality for the fleets it serves — food distributors, restaurant supply, bakeries, beverage distributors. Here's how it handles a COD stop end to end.

You mark the stop as COD and set its window — say, 9am to 11am for the restaurant whose manager pays before the lunch rush. When you hit optimize, that window is a hard constraint. The optimizer builds a sequence where the restaurant is genuinely served in that range, not parked outside it, and not jammed into the lunch rush. It also avoids the "wait in the van" trap — RunSheet post-processes the route so a driver isn't sent to idle for 40 minutes to satisfy a window; the COD ordering is resolved by sequencing, not by dead time.

On the road, the driver sees the COD stop flagged on their phone, collects the payment, and records it. If you're on the Growth plan, the proof-of-delivery photo and timestamp attach to the record, so a COD stop has the same audit trail as everything else — useful when there's ever a question about whether a payment was collected.

Label-only planner VRPTW planner (RunSheet)
Treats COD window as A note shown on the stop A hard constraint during optimization
Risk of arriving when nobody's there High Low — window enforced
Handles the window by Ignoring it, or idling the driver Sequencing the stop into the right slot
Result Failed stops, callbacks, dead time Stops land when the payer is there

The cost of getting it wrong

A failed COD stop isn't one wasted trip — it's a wasted trip, a callback, an annoyed customer, and a second trip later. Two or three of those a week across a fleet is a real hole in your day and your margins. The whole point of enforcing windows during optimization is that those failures mostly stop happening, because the route never put the driver in the wrong place at the wrong time to begin with.

Try it on a real COD route

If COD and time windows are part of your daily operation, the difference between a labeling tool and a VRPTW tool is something you'll feel within a day. Set up a real route with your actual COD windows and watch where the optimizer places those stops.

See what's included on each plan on the pricing page, or start a 7-day free trial and run your COD route through RunSheet's optimizer. No charge until day 8, and your drivers don't need to install anything to run it.

Start your free trial →

More from the blog

Back to blog