Operations
Rank Propane Stops by Margin, Not Urgency
Quick Answer
Propane delivery forecasts say when a tank needs fuel but not if the stop earns its cost. A ranked daily exception queue combines delivery cost, gross margin, runout penalty and forecast confidence, sits above the existing delivery platform, and separates measured, estimated and drifting accounts. Monitors belong where avoided cost is highest, and account payback shows which customers never repaid their fixed cost.
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 if 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 If
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 if 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, including driver time, truck cost, fuel, and dispatch overhead
- Gross margin on the gallons delivered, meaning price minus supply cost, multiplied by gallons
- Expected penalty for failure, including 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” on the forecast 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, namely 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 its lifetime?” 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.
Where Our Energy Software Work Fits
This problem is a good example of the work we do in energy operations software, which is 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. Our 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 if the stop deserves a truck. Related reading covers what propane delivery software misses and demand charges and site margin for EV charging.
Frequently Asked Questions
Why Does a Good Forecast Still Produce a Bad Route?
We find that a forecast is only a timing estimate. It does not show if a stop earns enough margin to cover the truck, driver time and risk of a miss, so the same forecast can justify opposite decisions for two accounts once delivery cost and gross margin are compared.
What Goes Into the Cost of a Propane Stop?
We count delivery cost per stop, including driver time, truck cost, fuel and dispatch overhead, against gross margin on the gallons delivered. We also add the expected penalty for failure, such as a service call, extra labor and churn risk if a customer runs out.
Where Should We Install Tank Monitors Next?
We install them where the avoided cost is highest, not simply on the biggest tanks. For each candidate we ask what a runout costs, how expensive the stop is to serve, how uncertain the forecast is, and if telemetry would let us combine stops or prevent a costly exception.
What Is a Ranked Exception Queue?
We use the term for a daily worklist that sits on top of the system of record and replaces a long forecast report. It pulls in stops near a runout threshold, low-fill accounts on expensive routes, drifted forecast inputs and weak-margin accounts, ranked by expected margin, stop cost, runout penalty and forecast confidence.
How Do You Know a Propane Account Has Paid Back?
We compare cumulative contribution margin with the upfront and ongoing service cost, including tank set, acquisition cost, onboarding work and service history. If an account has not crossed that line after several seasons it deserves review, which may lead to a pricing change, more telemetry or dropping low-value business.
About the author
Better Software Team
Product and engineering team
Better Software Team is the product and engineering team at Better Software. We build custom software for established businesses in healthcare, energy and finance.