Propane Delivery Software Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does scoping this as a routing project happen so often?

The brief that arrives at a developer is almost always the same sentence: we need better routing. It is the visible symptom. Everyone in the yard can see a bobtail come back short. So the work gets scoped as a route engine, priced as one, and built against whatever delivery data can be extracted quickly.

Routing is not where the money leaks. Forecasting is. A route engine optimises the stops you give it, so a wrong tank list produces an efficient trip to houses that did not need gas. The list is wrong because the K-factor was set when the account opened and has never been retuned, multiplied against heating degree-days from a profile that has not seen your last three winters. Fix routing alone and you will still run dry on the cold snap and still top off tanks at 55 percent, because both failures come from the same stale estimate.

The fix is sequencing. Scope the per-customer burn-rate model first, trained on your full delivery history plus whatever live monitor readings you have, retuning itself every time a truck delivers. Then put the route engine on top of a list of tanks that will genuinely run out this week. A build that ships the forecast and a plain sorted worklist beats a build that ships elegant routing over a guess, and it costs less.

What goes wrong with getting delivery history out of ADD Systems?

This is the single most underestimated line in every propane quote. ADD Systems is a closed back office with a thin integration surface, and it is your system of record for gallons, tank sizes, addresses, pricing tiers and the keep-full versus will-call flag on every account. The model is worthless without that history, and getting it out reliably is real engineering rather than a connector you install.

Three things go wrong in sequence. First, the extraction is scoped as a two-week task and turns out to be six, because the export path is a scheduled job and a file format rather than an interface. Second, the history has gaps: accounts that changed tank size and were never updated, addresses that moved between routes, deliveries recorded against a parent account rather than the tank. A burn-rate model trained on that data quietly learns the wrong thing for the accounts you care about most. Third, nobody plans the ongoing feed, so the build works against a one-time dump and drifts within a month.

The concrete fix is to assess the extraction before you agree a price for anything else. Pull ninety days of real history, profile it for missing tank sizes, orphaned deliveries and duplicated accounts, and put the cleanup work into the plan as its own line. Then design the nightly feed as incremental with reconciliation, so you can prove every day that the model is reading what ADD actually holds.

Why do the tank monitor feeds break after launch?

Monitor telemetry looks like the easy part because each vendor publishes an interface. The trouble is that most dealers do not have one vendor. If your fleet of monitors is split across Tank Utility, Otodata and Wesroc, that is three separate feeds with three notions of a reading, three ways of reporting a stale or failed sensor, and three tank identifier schemes that have to be matched back to the ADD account.

What breaks after launch is almost never the happy path. It is the sensor that stops reporting and keeps returning its last value, which reads as a tank that is not being consumed, so the forecast quietly removes it from the at-risk list. It is the monitor swapped onto a different tank during a service call, still mapped to the old account. It is a vendor changing an authentication requirement, and because the failure is silent, nobody notices until a run-out.

The fix is to treat freshness and confidence as data, not as an assumption. Every reading carries a source and a timestamp, and any tank whose monitor has gone quiet for longer than a defined window falls back to the burn-rate model rather than to a stale number. Build a daily feed health report that names the tanks with dead sensors and the accounts whose monitor identifier no longer matches ADD, and give the office an owner for that list.

What happens when the gas safety obligations are not covered?

Two obligations get missed, and one of them is dangerous. The first is the run-out consequence: when a tank goes to zero, state code means a technician has to pressure test the system, check for leaks and re-light every appliance before it is legal to leave. If your build measures success in miles saved and never counts run-outs and the technician hours they trigger, it will optimise the wrong number and look successful while costing you afternoons.

The second is the phone. An AI voice agent answering after-hours calls is one of the highest-return pieces in this category, and it is also the piece a generic booking flow will get wrong. Propane has a regulated safety sequence that must run before anything else: the do-you-smell-gas question, the instruction to leave the house, the escalation to a human. A booking bot that treats a no-heat call like a restaurant reservation is not merely a poor experience.

The fix is specification before code. Write the safety script with your own compliance lead, define exactly which answers force an immediate human page, and test those branches explicitly rather than as part of a general conversation test. On the operations side, put run-out count and emergency re-light hours into the reporting from day one, alongside gallons per stop and miles per route, so the system is scored on the outcome you actually care about.

Should you build custom or configure what you already own?

Some dealers should not build, and it is worth saying plainly. If you run a handful of trucks, most of your base is will-call rather than keep-full, and the routing and forecasting that ship with your existing tools keep up without you padding the schedule, then ADD Systems with Tank Utility, or ServiceTitan or Jobber on the service side, is genuinely enough. Add monitors before you add software. More live tank readings on your highest-volume keep-full accounts will reduce run-outs faster and cheaper than any build, and they are the input a future model needs anyway.

The other honest configuration answer is to retune your K-factors by hand before spending anything. A finance or operations person working through your top two hundred accounts against last season's actual gallons will find the accounts where the estimate is badly wrong, and that exercise tells you whether your forecasting problem is systemic or concentrated in a hundred houses.

Build when the pattern is structural rather than fixable by discipline: you pad every delivery schedule to avoid run-outs and accept the wasted miles, after-hours calls go unanswered, conversion quotes die in the queue during the months they are worth most, and years of ADD history has never answered a single question. And do not rip out ADD Systems. It is good at billing and compliance. Build where the money leaks, which is dispatch intelligence, the phone and follow-up.

How do hidden costs get into the quote?

Four ways, and they are all avoidable by asking before you sign. The first is the back-office extraction discussed above, quoted as an integration when it is a data engineering project. Ask for it to be priced as a separate discovery phase with a fixed fee and a written output, so the rest of the estimate rests on evidence.

The second is monitor vendor count. A quote written assuming one telemetry provider grows materially at three. Count your monitors by vendor before the conversation and put the number in the brief.

The third is peak load. Propane demand is not smooth. A cold snap multiplies call volume, delivery volume and re-planning in a single day, and a system sized for an average Tuesday will be slowest exactly when it matters. Ask what the design assumes about a day at four times normal volume, because retrofitting that later is expensive.

The fourth is the ongoing line nobody quotes: the voice agent carries usage cost per call, the monitor feeds need maintenance as vendors change interfaces, and the model needs periodic review. Budget a realistic annual figure for upkeep alongside the build number rather than discovering it in year two.

What separates a propane build that works from one that fails?

The working builds all share the same three habits. They ship the forecast before the interface. A dealer using a plain daily list of the twenty tanks most likely to run out this week is already saving money, and that list is what proves the model before anyone spends on a dispatch board.

They keep a human in the loop for the first season. Your dispatcher should be able to see why a tank is on the list, override it, and have the override recorded. Their overrides are the most valuable input you will get, because each one is usually a real constraint nobody wrote down: the customer who fills their own tank, the driveway no bobtail can reach in January, the account that always calls before it runs low.

And they are honest about ownership. Insist in writing, before kickoff, that you own the code, the trained models and the data pipelines, running against your own ADD data with no per-seat lock-in. The asset here is your delivery history and the model that learns from it. If either sits on a supplier's account, you are renting the one thing that compounds.

The builds that fail do the opposite: a polished dispatch screen over an unvalidated forecast, no measurement of run-outs, and a data feed nobody owns after launch.