Operations
Propane delivery software should rank stops by margin
By Better Software · Fri Sep 18 2026 · 9 min read
If you run a propane or heating-oil business, you probably already trust your delivery platform to tell you when a tank is getting low. That is useful, but it is not the decision you actually pay for. The real question is whether a stop adds enough margin to justify the truck, driver time, and risk of a miss.
That is why a good forecast can still produce a bad route. A customer can be “due” in the system and still be a poor stop for today. If you want propane delivery software to help the business, it has to do more than predict gallons. It has to help you rank exceptions by margin, not just by urgency, while you keep the platform you already run.
This matters more now for three practical reasons. Mixed estates are common, so some tanks have telemetry and others are still estimated from usage patterns. Acquired books often arrive with imported K-factors and hot-water-gallon values that were never audited. And the cost of a stop is no longer hidden inside a route plan; it shows up in labor, fuel, and missed opportunities.
Forecasting tells you when. Margin tells you whether.
Most delivery platforms estimate when a tank will need fuel by combining historical usage, customer type, weather, and sometimes telemetry. That is the right first step. It keeps trucks from running blind and helps dispatch plan capacity.
The problem is that a forecast is only a timing estimate. It does not answer whether the stop will earn enough to cover its own cost. A low-fill automatic stop might be cheap to serve, or it might consume so much route time that it destroys the margin on the gallons delivered. A will-call customer may look risky on paper, but if they take a larger fill when they finally order, the economics can be better than a frequent low-volume stop.
The owner’s job is to compare the delivery cost with the gross margin on the order. A simple version looks like this:
- Delivery cost per stop: driver time, truck cost, fuel, and dispatch overhead
- Gross margin on the gallons delivered: price minus supply cost, multiplied by gallons
- Expected penalty for failure: service call cost, extra labor, and churn risk if a customer runs out
Once you put numbers on both sides, the same forecast can justify opposite decisions for two accounts. A stop that is “due” at 20 percent remaining may be worth making if the house is remote, the fill is small, and the margin is thin. Another “due” stop in a dense route may be profitable because the truck can serve it with almost no incremental cost.
That is the part most propane delivery software does not do for you. It reports the forecast, but it leaves the economics in the dispatcher’s head.
A forecast can be accurate and still be economically wrong
The hidden assumption in many systems is that if the estimate is close enough, the route decision will be close enough too. In practice, the estimate can drift for reasons that are operationally normal and financially important.
K-factors and hot-water-gallon values decay quietly when customers change appliances, add a heat pump, move to will-call, spend the winter elsewhere, or simply use the house differently. Telemetry improves visibility on the tanks that have it, but it can also create a false sense of completeness if the rest of the book is still being modeled statistically. Across an acquired portfolio, those old values may have come from a different system, a different pricing policy, or a different service pattern.
That is why the question should not be “Is the forecast report right?” It should be “Which forecast exceptions are worth human attention today?” A dispatcher can correct outliers, but a dispatcher cannot rebuild the economic logic for every stop in the book. The software has to surface the exceptions in a way the owner can act on.
Treat the estate as mixed, then decide where monitors belong
Most dealers do not operate a uniform tank estate. They have telemetry on some high-value or hard-to-serve accounts, and statistical forecasting on the rest. That is not a weakness. It is the reality of a mature business.
The mistake is to deploy monitors only where the tank is large or where the customer is important in the abstract. A better rule is to install them where the avoided cost is highest. That usually means a combination of runout risk, service complexity, and route density.
A practical rule for choosing the next monitor
Ask four questions for each candidate account:
- What does a runout cost here, including the service call and the risk of losing the customer?
- How expensive is this stop to serve compared with the rest of the route?
- How uncertain is the forecast today, based on old usage values or a recent change in customer behavior?
- Would telemetry let us combine this stop with others more efficiently, or prevent a costly exception?
If the answer to those questions points to high avoided cost, the monitor is more likely to pay for itself. If the account is already dense, predictable, and cheap to serve, telemetry may add little. In other words, the decision is not “big tank or small tank.” It is “where does better visibility reduce the most waste?”
This is also where mixed estates deserve honesty in the software. A single model that treats telemetry and estimated demand as if they were the same thing will eventually mislead the dispatch team. The system should show which accounts are measured, which are inferred, and which have drifted far enough from their historical pattern that they need review.
Replace the forecast report with a ranked exception queue
The operational change that matters most is small. Do not ask dispatch to review a long forecast report and “spot the issues.” Build a ranked daily worklist that sits on top of the system of record.
That worklist should pull in only the accounts that matter today: stops near the edge of a runout threshold, low-fill accounts on expensive routes, customers whose forecast inputs have drifted, and accounts whose margin profile suggests they may not be worth the trip. The ranking can be simple at first. The point is not perfect optimization. The point is to stop treating every forecast exception as equally important.
A useful first version might sort by a combined score such as:
- expected margin on the delivery
- cost of the stop
- penalty for runout or missed service
- confidence in the forecast
That score does not need to replace dispatcher judgment. It needs to focus attention. When an owner asks, “Which stops should we not have made?” the answer should come from a list that shows why a stop was chosen, what it cost, and what risk was avoided or created.
This is the kind of layer that can sit above ADD Systems E3/E360, Cargas Energy, Blue Cow, or Energy Force without replacing them. Those platforms remain the operating system of record. The added layer turns their data into a daily decision tool.
Do not ignore account payback
Delivery economics are not only about this week’s route. They are also about whether a customer has ever earned back the cost of winning and serving them.
In propane, that often includes the tank set, acquisition cost, onboarding work, service history, and the low-margin period that can follow a sale. In acquired books, the original economics may never have been measured cleanly, which makes it easy to keep serving customers whose lifetime value is weak or negative. Will-call accounts can have the same problem if they require repeated attention but buy in small, irregular volumes.
For an owner, the key question is not just “Is this delivery profitable?” It is “Has this account repaid its fixed cost over three to eight years?” If not, then the book may be carrying structural drag that no amount of route tweaking will fix.
A simple way to think about payback is to compare cumulative contribution margin with the upfront and ongoing service cost. If the account has not crossed that line after several seasons, it deserves review. That review may lead to a pricing change, a service policy change, more telemetry, or in some cases a decision to stop chasing low-value business.
How Better fits into this kind of work
This problem is a good example of the work Better does in energy operations software: building the decision and reporting layer that sits on top of an operating system of record and turns its data into something an owner can act on. Better’s energy work includes software for Sunny Energy, a solar installation business, and data-pipeline and document-processing engineering on Nesh, an oil and gas information platform. The common thread is not replacing the core system. It is making the data usable for the people who have to decide.
For a propane or heating-oil distributor, that means the practical aim is narrow. Keep your delivery platform. Add the layer that shows margin, risk, and payback in the same view, so the daily route is chosen for business value rather than habit.
What to ask your team or software vendor next
If you want to move from forecasting to margin-aware dispatching, start with a few specific questions:
- Can we see stop cost and gross margin together for each delivery decision?
- Which accounts are forecast by telemetry, which are estimated, and which are drifting?
- Do we have a ranked exception queue, or only a report?
- Which accounts have not repaid their acquisition and service cost over time?
- Can we test where additional monitors would reduce the most cost, not just where they would be easiest to install?
If your current platform cannot answer those questions, that does not mean it has failed. It means it is doing the first job well and leaving the economic judgment to people. The next step is to give those people a better decision layer.
That is the difference between a delivery department that stays busy and one that gets measurably better. The forecast tells you when the tank needs fuel. The margin view tells you whether the stop deserves a truck.