Why “Google time + 30%” breaks on the days it matters most

Almost every self-drive operator we have spoken to budgets drive time the same way: take the number a mapping app gives, add twenty or thirty per cent, write it in the spreadsheet. It is a sensible heuristic. It is also the single assumption most likely to be wrong on the day that matters.

What the base number actually assumes

A routing estimate is a model of a vehicle that does not stop, does not photograph anything, and drives at the posted limit. It is a lower bound on a good day. It is not a prediction of your client’s day, and it was never supposed to be.

That is fine. The problem is not the base number. The problem is what the padding is being asked to absorb.

A percentage cannot encode a deadline

Add 30% to a five-hour drive and you get six and a half hours. That is a reasonable allowance for stops, coffee, photographs and one slow tractor.

It is not an allowance for any of these:

• A ferry that leaves at 15:30. Missing it by ten minutes and missing it by two hours cost the same: a night in the wrong place. There is no percentage that expresses a cut-off — it is a hard edge, not a distribution.
• An attraction that closes at 17:00. Arriving at 17:05 means the stop did not happen, and the client paid for it.
• Daylight in November. Four usable hours does not stretch by 30%.
• A road that is shut. The detour is not slower — it is a different route with a different length.
• A vehicle that cannot use the road. A 3.2 m campervan and a hire car do not share an itinerary.

Each of these is a constraint, and constraints do not average. A day either satisfies them or it does not. Padding turns a hard failure into a soft number and hides it.

The failure mode is asymmetric

Overestimate a day and you lose a stop you could have sold. Underestimate a day and your client is driving in the dark, misses the ferry, and emails you from a town they were not supposed to be in. Those two errors do not cost the same, and a symmetric percentage treats them as though they do.

This is why experienced planners quietly over-pad everything — and why itineraries end up thinner than they needed to be. The buffer is doing the work that a constraint check should be doing.

What to do instead, without new software

1. Write the hard edges down first. For each day, list the fixed times: ferry departures, closing times, sunset, check-in cut-offs. Plan the day against those, not against a total.
2. Budget the segment, not the day. A day is feasible when every leg between two fixed points fits, not when the sum looks reasonable.
3. Pad the variance, state the constraint. Keep a buffer for traffic and stops. Do not use it to cover a deadline — name the deadline in the itinerary.
4. Re-check anything seasonal before departure, not at booking. A road status from three months ago is not a road status.

Where we come in — honestly

This is the work we are automating: a solver that takes the real routing graph, your vehicle profile and the day’s fixed points, and either produces a day that satisfies all of them or tells you which constraint it broke and by how much. Not a smaller percentage — no percentage.

It is not live yet. If you plan self-drive itineraries and recognise the “Google time plus thirty” habit as your own, the founding programme is where operators shape what ships first.