The Stop You Should Not Have Made

Most propane delivery software answers one question well: when will this tank need fuel?

That is useful. It is not sufficient.

If you run a retail propane or heating-oil business, the question that matters is different: was that stop worth making? A low-fill delivery that saves a runout may still destroy margin. A monitor-equipped tank may prevent a costly exception. An acquired account book may look healthy in gallons and routes while quietly failing to repay its tank sets. Forecasting tells you where fuel goes next. It does not tell you whether the stop belongs on the route.

That distinction matters because the economics have changed. Driver availability is tighter. Labor is more expensive. Tank telemetry is cheap enough that many dealers now operate a mixed estate: some monitored tanks, many unmonitored tanks, and a forecasting model trying to make one clean answer out of two very different kinds of data. Consolidation has also left a lot of owners with multiple customer books, imported settings, and pricing conventions that were never truly normalized. In that environment, “review the forecast report” is not a decision process. It is a ritual.

And to be clear: this is not an argument to rip out ADD Systems, Cargas Energy, Blue Cow, Energy Force, or PDI. Most established dealers have already spent years implementing a platform of record. The better move is to put a decision layer on top of it.

Forecasting gallons is not the same as deciding stops

Traditional propane delivery software uses a forecast model built on K-factor, usage patterns, hot-water-gallon assumptions, degree days, and periodic corrections. Over time, the model drifts. A customer installs a heat pump. A family goes on holiday for six weeks. A will-call customer becomes automatic delivery. A tank monitor gets added. The system may self-correct in small increments, but only within its own guardrails. The last mile of correction is often a dispatcher noticing that something looks off in a report.

That creates a hidden problem: the software produces an estimate, but the owner pays the consequence.

Two accounts can have the same forecast and deserve opposite treatment. One is close to a dense route, has high delivered margin, and is expensive to service if it runs out. Another is isolated, low-margin, and unlikely to repay the stop. The forecast says both tanks need fuel. The business should not make the same decision twice.

The missing step is arithmetic. Before you ask “when,” you have to ask “at what cost, and with what return?”

Put a cost on the stop and a margin on the gallon

Every delivery decision has three moving parts:

• Cost per stop: driver time, vehicle cost, fuel, dispatch overhead, and the cost of complexity when the route gets less efficient.
• Margin per gallon: delivered gross margin after supply cost, excluding the stop itself.
• Exception cost: runout penalties, emergency service calls, churn risk, and the operational cost of a bad promise.

Once those are visible, the same forecast can justify opposite decisions.

Example one: Account A is on a tight route, carries healthy margin, and is likely to run out in 10 days. A stop today is cheap because it fits the route. A stop later may force a less efficient add-on or a service rescue. That stop probably should happen.

Example two: Account B is geographically isolated, low-volume, and has poor gross margin. The tank is forecast to need fuel, but the route cost is high and the account has no meaningful upside. If the forecast says “deliver,” the business may still be better off letting it ride until a denser route or a service visit changes the economics.

That is the owner's version of propane delivery software: not “what is the tank level?” but “does this stop create value?”

Forecasting is an operational estimate. A delivery decision is a margin decision under uncertainty.

Mixed estates need mixed logic

One reason so many delivery departments feel stuck is that they are running a single forecast logic across a mixed estate.

Some tanks have monitors. Some do not. Some customers are on automatic delivery. Some are will-call. Some were acquired three years ago and still carry forecast values that no one has seriously audited. In that world, the fantasy of a uniform model fails quickly.

The more honest approach is to treat the estate as two systems:

• Monitored tanks, where telemetry gives you higher confidence and tighter exception management.
• Statistical tanks, where K-factor and usage assumptions are still useful but decay over time and need deliberate review.

That mixed reality should drive monitor placement. The question is not “which tanks are biggest?” It is “where does a monitor earn its keep?”

Use a simple rule: install telemetry where the avoided cost is highest, not where the tank is largest. The best candidates are usually tanks with one or more of these traits:

• high runout cost, especially residential accounts where a dry tank can trigger service labor and churn;
• poor route density, where a surprise stop is expensive;
• volatile demand, where the forecast drifts often;
• accounts with high gross margin or strategic retention value;
• books inherited through acquisition where the forecast quality is uncertain.

That is how you avoid treating telemetry as a universal upgrade. A monitor on a low-value, dense-route account may have little payback. A monitor on a remote, high-risk account may pay for itself quickly by preventing a single bad dispatch.

Replace the forecast report with a daily exception queue

Most systems produce reports. What owners need is a worklist.

The operational shift is small but important: instead of asking dispatch to “review the forecast,” build a ranked queue of exceptions that require action. This is the thin software layer that turns data into decisions without replacing the system of record.

A useful exception queue can rank accounts by a few simple questions:

• Is the forecasted stop profitable after stop cost?
• Is the account at elevated runout risk?
• Is this account on a monitored tank or a decaying statistical estimate?
• Would delaying the stop improve route density without increasing risk?
• Is the account structurally unprofitable even if delivery timing is technically correct?

That queue should not be a giant custom platform. It should be a compact decision layer sitting on top of ADD, Cargas, Blue Cow, Energy Force, or PDI. The system of record continues to run scheduling, billing, customer history, and route execution. The decision layer ranks the exceptions that deserve human attention.

This is the kind of software Better builds in energy: operational systems that sit above the record of truth and turn it into something an owner can act on. The same shape shows up whether the business is selling and installing energy equipment or moving oil and gas data through a system like Nesh. The point is not to replace the platform. It is to make the data decision-ready. For more on that work, see energy software engineering.

Bring payback into the picture

The biggest blind spot in many propane and heating-oil operations is not route efficiency. It is account economics over time.

Owners often know gallons, service history, and price per gallon. They do not always know whether a customer has paid back the cost of the tank set, acquisition, install labor, and service burden. That matters especially in books that have grown by acquisition, where the business may have inherited customers with very different economics.

A simple payback view changes the conversation. If an account took a tank set three years ago and has never earned back the full installed cost through margin, that account is not just a delivery stop. It is a capital allocation problem.

Likewise, some will-call customers look flexible until you load in the real cost of missed timing, emergency dispatch, and low-margin sporadic fills. A book can be busy and still underperform if too many accounts never contribute enough to cover the operational burden they create.

The useful question is not only “which stop should we make today?” It is also “which customer relationships have actually created value, and which have only consumed it?”

People also ask: what is propane delivery software supposed to do?

At minimum, propane delivery software should manage customer data, delivery planning, route scheduling, tank readings, service history, and billing. The best systems also help forecast demand. But forecasting alone is not the business outcome. The outcome is profitable delivery, fewer runouts, and better use of labor and trucks.

People also ask: what is the best propane delivery software?

For an established dealer, “best” usually means the platform that already runs the business cleanly: reliable dispatching, billing, account records, and integration with service and telemetry. The gap is rarely the core platform. The gap is the decision layer on top of it. Owners often do not need a replacement; they need a way to prioritize forecast exceptions by margin, risk, and payback.

People also ask: how do tank monitors fit into propane distribution software?

Tank monitors are most valuable where they reduce expensive uncertainty: remote accounts, high-risk runouts, low-density routes, and strategic customers. They are not simply a replacement for statistical forecasting. In a mixed estate, monitors should be deployed where avoided cost is highest and where the forecast model is most likely to drift.

What this changes for the owner

If you run 3,000 to 40,000 delivered accounts across one or several branches, the decision problem is not theoretical. You already have the software. You already have the routes. What you may not have is visibility into which deliveries create margin and which ones just consume it.

That is why the important upgrade is not a new forecast engine. It is a clearer operating model:

• price the stop;
• price the gallon;
• separate monitored from statistical tanks;
• rank exceptions instead of reviewing reports;
• carry account payback into the delivery decision.

Once you do that, the question changes from “when does this tank need fuel?” to “should this tank be on the truck at all?”

That is the stop you should not have made.