Your Delivery Software Knows the Tank Is Low. Not the Stop Is Worth It

Your software tells you when a tank will be empty. It does not tell you whether the stop is worth making.

That is the gap in propane delivery software, heating-oil software, and most software for propane companies. The platform can estimate when a customer will need fuel. It can build routes, print tickets, and keep trucks moving. What it does not do is answer the owner’s real question: if we make this stop, do we actually make money?

That matters more now than it did five years ago. Telemetry is cheap enough that most dealers now run a mixed estate: monitors on some tanks, statistical forecasts on the rest. Consolidation has left many operators with acquired books whose forecasting values were imported wholesale and never validated. And driver availability, overtime, and truck cost have made every unnecessary stop visible.

The answer is not to rip out ADD Systems, Cargas Energy, Blue Cow, Energy Force, or PDI. Keep the system of record. Add a decision layer on top of it. That layer converts “tank low” into “stop worth making” by putting dollars on both sides of the equation.

How the forecast actually works

Most propane delivery management software uses some combination of K-factor propane, hot-water gallons, and degree days. In plain English, the system tries to estimate how fast a tank burns fuel based on past usage and weather.

• K-factor is the historical gallons-per-degree-day relationship for that account.
• Hot-water gallons are the base load the home or business uses regardless of weather.
• Degree day forecasting propane uses heating demand driven by temperature over time.
• The software then predicts a run date or fill date and may self-correct the estimate in capped increments as new deliveries and weather arrive.

That sounds precise. It is not the same thing as accurate. The estimate is only as good as the assumptions beneath it, and those assumptions drift quietly.

Why the model drifts

Forecasts break for ordinary reasons:

• a customer installs a heat pump
• a household changes occupancy patterns or goes on holiday
• a will-call account becomes automatic delivery
• an automatic account becomes more efficient after appliance changes
• a tenant changes, and the burn profile changes with them
• an acquired dealer’s values are loaded into the new system without validation

The software may correct slowly, but only inside the bounds of the model. The last-mile correction is often still a dispatcher noticing something odd in a report. That is not a decision system. That is a memory aid.

Accuracy is not the same as economics

Forecasting methods based on degree days can be useful and still carry wide prediction error. That is not a criticism of the software. It is a fact about the method. Weather explains usage imperfectly, and the error gets worse when the customer’s behavior changes faster than the model learns.

For an owner, that means the useful question is not “How accurate is the forecast?” It is “What does a wrong forecast cost us?” If a stop is cheap, a miss may be tolerable. If a stop is expensive, a forecast that is merely ‘good enough’ can still destroy margin.

Put money on the stop

To decide whether a stop is worth making, compare expected contribution against expected cost. The simplest version uses four inputs:

• Cost per stop: driver time, truck time, fuel, dispatch overhead, and branch share
• Margin per gallon: what that account actually contributes under its price plan
• Expected gallons on the stop: fill quantity or delivery size
• Expected penalty if you do not stop: runout, emergency delivery, service call, and churn risk

Here is the point: the same forecast can support opposite decisions for two accounts.

In Account A, the fill has enough margin to pay for the truck and still leave room for uncertainty. In Account B, the forecast says the tank is low, but the economics say the stop is marginal. If you add a monitor or adjust the route position, you may change the answer. But the answer is not “deliver because the tank is low.” The answer is “deliver only if the stop earns its place.”

The mixed estate: monitors on some tanks, statistics on the rest

Most dealers do not run a pure telemetry fleet. They run a mixed estate. A minority of tanks have propane tank monitoring. The rest are still modeled statistically. Good propane distribution software should treat both as inputs to the same decision layer, not as two separate worlds.

That gives you a practical rule for where the next hundred monitors should go:

Install the next monitor where the cost of a mistake is highest, not where the tank is largest.

Concretely, prioritize accounts with one or more of the following:

• high runout cost because of service intensity or customer sensitivity
• long route position where a missed stop is expensive to recover
• volatile usage, so the statistical forecast is least trustworthy
• thin margin per gallon, where low-fill behavior destroys economics
• recent acquisition status, where the historical values are least validated

That rule beats a simple tank-size heuristic. A large tank on a dense route with stable load may not need a monitor. A smaller tank on a remote route with high churn risk often does.

From report to queue

The smallest useful layer above propane dispatch software is not a new platform. It is a ranked daily exception queue.

Instead of asking dispatchers to “review the forecast report,” the system should produce a short worklist with each account scored by expected value and risk:

• accounts drifting against their own historical pattern
• low-fill repeat offenders
• runout risk weighted by route position and recovery cost
• acquired accounts whose imported K-factors have never been validated
• telemetry exceptions where the monitor and the burn model disagree

That queue should tell the dispatcher what changed, why it matters, and what action is implied. This is a small build, not a platform replacement. It sits on top of the system of record and uses its data.

The account-level view most operators do not have

The owner’s missing view is not just gallons per stop. It is account payback. If you set a tank, installed a regulator, sent labor, and serviced the account for years, has that account repaid its capital and operating load?

Once you add the full burden—tank set, regulator, labor, inspections, service calls, routing inefficiency, and churn risk—you can identify books that looked fine at the route level but have never earned back their setup cost. That is especially important after acquisition, when pricing conventions and service expectations vary across books.

This is where the real operating question changes. Not: “How many gallons did this account take?” But: “Over its life, did this account create value or absorb it?”

Build versus buy, stated plainly

Buy the platform for tickets, routing, billing, compliance, and the core operational workflow. Keep it. You do not need to replace ADD, Cargas, Blue Cow, Energy Force, or similar systems to make better decisions.

Build or commission the layer that encodes your economics. That layer should reflect:

• your route cost structure
• your margin by pricing plan
• your runout cost assumptions
• your monitor strategy
• your account-level payback logic

No vendor can model those precisely for one dealer, because those numbers are specific to your book, your drivers, your branch density, and your acquisition history. The system of record knows the tank is low. Your decision layer decides whether the stop belongs on the truck.

What it takes to build it

The data is usually already there:

• delivery history and ticket detail
• pricing plan and margin data
• monitor telemetry where installed
• service records and runout history
• customer acquisition dates and tank set costs

Integration with systems like E3 or Cargas is usually about extracting the right events, not replacing the workflow. A first version should do three things well:

1. score forecast exceptions by expected margin impact
2. rank accounts by runout and stop economics
3. surface accounts whose historical burn has materially changed

It should not try to rewrite dispatch, billing, or compliance. It should improve the decision before the stop is made.

FAQ

How often is propane delivered?

It depends on tank size, weather, appliance load, and whether the customer is automatic delivery or will-call. Some accounts need deliveries multiple times in a heating season; others may go much longer. The point is not the calendar cadence. It is whether the delivery is timed well enough to be profitable.

What is the minimum amount of propane delivery?

Operationally, the minimum is whatever makes sense for the route and the account economics. A small fill can be acceptable on a dense route with strong margin and low stop cost. On a remote stop, the same fill may be unprofitable.

How does propane delivery work?

Most dealers forecast usage from K-factor, hot-water gallons, degree days, and telemetry where available. Dispatch then plans the stop, routes the truck, and bills the delivery through the delivery management system.

How to start a propane delivery business?

Starting a propane delivery business requires regulatory compliance, supply contracts, trucks, tanks, trained staff, billing systems, and a dispatch process. But the hard part is not the license. It is building a model that keeps stops profitable after the first season.

Do tank monitors pay for themselves?

They do when they prevent enough runouts, recover enough route efficiency, or protect enough high-value accounts. The right test is not tank size alone. It is whether the monitor reduces the expected cost of a bad decision on that account.

Should we replace our delivery software?

Usually no. Keep the platform that handles your core operations. Add the decision layer that turns forecasts into ranked actions and margin-aware stop decisions.

That is the point: your delivery software is already good at telling you when the tank will be low. The next step is deciding whether that stop belongs on the route at all.

For teams that need the reporting and decision layer above the operating system of record, this is the kind of energy work Better builds: software that turns operational data into something an owner can act on. See Energy and Nesh.