You fix the four fields routing actually depends on before you optimize anything: a verified delivery coordinate, tank size and current level, access constraints, and a service-time estimate. A routing engine cannot improve a stop it has placed a quarter mile up the wrong driveway.
Ask a dispatcher why the optimizer's route did not survive contact with the road and the answer is almost never the algorithm. It is that account 4417 geocoded to the center of a five-mile rural route, that the Hendricks place has a gate the software does not know about, and that three "residential" stops on the same run are actually 1,000-gallon tanks behind a machine shop.
Routing software solves an arithmetic problem very well. It solves it against whatever the customer file says. That is the whole story of route optimization at a propane dealer.
Why does route optimization fail on propane accounts specifically?
Because propane serves the addresses that geocoding handles worst. Rural delivery, long private drives, seasonal properties, unnamed roads, and tanks that sit nowhere near the mailbox all break the assumption a routing engine makes — that a mailing address is a place a truck can stop.
Four failure modes account for most of it:
- The mailing address is not the delivery address. A rural route and box number tells the carrier where to leave mail. It does not tell a driver where the driveway is. Many counties have since assigned physical 911 addresses that do, and plenty of dealer files still carry the old one. - Interpolated coordinates. When a geocoder cannot match an exact address point, it estimates a position along a street segment. On a suburban block that is off by a few houses. On a five-mile township road it is off by a mile. - The tank is not at the house. Behind the barn, down the hill, on the far side of a fence — the hose length and the approach angle are route data, and they are usually in a driver's head. - The account type is wrong. Residential and commercial stops with the same tank size can carry very different service times, access rules, and delivery windows.
What data does a routing engine actually need?
Five fields carry nearly all the routing weight. Everything else is nice to have.
| Field | Why routing breaks without it | The cheap fix |
|---|---|---|
| Verified delivery coordinate | Every distance, sequence, and drive-time estimate is computed from it | Capture a GPS pin at the truck on the next delivery and overwrite the geocode |
| Tank size + last-known level | Determines whether the stop can take a profitable drop today | Recalculate from delivery history; flag accounts with no tank size on file |
| Access constraints | Gates, low clearance, unplowed private drives, dogs, locked yards, hours | Structured checkboxes, never free-text notes the optimizer cannot read |
| Service time at the stop | A 12-minute stop routed as a 6-minute stop breaks the whole afternoon | Time a sample by account type; set defaults by tank size and access class |
| Delivery window / constraint flags | Commercial hours, school zones, restricted roads, customer-required notice | Store as a field on the account, not as tribal knowledge |
The pattern in that table is the point. Every one of these lives in a driver's memory at most dealers, which means the route is only as good as which driver took it.
How do you clean up rural addresses that won't geocode?
Standardize the mailing address, capture the physical location separately, and treat a GPS pin taken at the tank as the highest-authority record. Those are two different data elements and they should live in two different fields.
Standardization first. The U.S. Postal Service publishes the address formats — street suffixes, directionals, secondary unit designators, and a dedicated standard for rural route addressing — in Publication 28, *Postal Addressing Standards*. Running the customer file through those conventions resolves a meaningful share of no-match records before anyone touches a map, because most failures are formatting, not geography.
What standardization will not do is find a driveway. That takes field capture, and the cheapest field capture in propane is already driving past the tank every few weeks:
1. Turn on coordinate capture at delivery. The truck is at the tank. Record where it is. 2. Trust the pin over the geocode. Once a delivery pin exists, it becomes the routing coordinate, permanently. 3. Work the exception list, not the whole book. Sort by geocode confidence and by accounts where the pin and the geocode disagree by more than a set distance. Those are the accounts costing you time. 4. Fold in the 911 address. Counties that have completed rural addressing assign a physical address that a routing engine can match; the mailing address stays on the invoice. 5. Close the loop on missed stops. Every "could not deliver" gets a structured reason code, and every access-related reason code updates the account record before the truck is unloaded.
Six weeks of that on a normal delivery cycle produces a better address file than any one-time cleanup project, and it does not require a project.
How do you route around hazmat restrictions and road limits?
You route around them deliberately, using the designated-route information published for hazardous materials transport plus the local restrictions no national dataset carries. A bobtail is a placarded vehicle, and the shortest path is not always a legal or a passable one.
The federal reference point is the National Hazardous Materials Route Registry, maintained by the Federal Motor Carrier Safety Administration, which compiles the routes states have designated or restricted for hazmat transport. Any routing configuration that ignores it is optimizing against a road network the truck may not be permitted to use.
The local layer is the one that actually surprises dealers, and no vendor dataset will have it:
- Seasonal weight restrictions on secondary roads during spring thaw
- Low bridges, weight-posted bridges, and tunnel restrictions
- Private drives that a loaded bobtail cannot turn around in
- School zones and time-of-day restrictions on specific streets
- Roads that are fine in October and not in February
That list belongs in the routing system as constraint data on the road segment or on the account, in whatever form the software supports. Kept in a driver's head, it disappears the day that driver retires — and driver turnover is the single most common way a well-run propane route quietly gets worse.
What's the right order of operations?
Clean before you optimize, and sequence the work so each step pays for the next. Optimization applied to a dirty file produces confident, precise, wrong answers, which is harder to detect than an obviously bad route.
1. Audit. Count accounts with no tank size, no verified coordinate, low geocode confidence, or a default service time. That count is the real starting condition. 2. Standardize the address file against postal conventions. 3. Capture delivery coordinates at the truck and let them overwrite geocodes. 4. Structure the access and constraint data that currently lives in free-text notes. 5. Set realistic service times by account class rather than one global default. 6. Then optimize — and compare the optimizer's planned route against actual GPS breadcrumbs, not against the plan.
That last comparison is the audit that keeps everything honest. Where planned and actual diverge by more than a few minutes, the data is still wrong somewhere, and the divergence points at exactly which stop.