Your propane software says the tank is low

Your propane delivery software can tell you when a tank is likely to run low. It usually cannot tell you whether sending a truck is the right business decision.

That is the gap most owner-operators live with. The platform gives you a forecast, a route sheet, and a pile of exceptions. The dispatcher still decides which stops to make, often using a feel for the book that sits in one person's head. That works until you mix automatic-delivery and will-call accounts, add tank monitors on a minority of tanks, and inherit customer books with forecast values nobody has checked in years.

The practical answer is not to rip out your delivery software. Keep it for tickets, routing, billing, and compliance. Add a thin decision layer on top that prices the stop, estimates the risk of waiting, and ranks the day's exceptions by margin, not just by gallons.

How propane forecasting actually works

Most propane delivery management software uses a version of the same logic. It starts with a customer's K-factor, which is a measure of how many degree days it takes to burn a gallon of propane. Degree days are a weather-based way to estimate heating demand. Add hot-water gallons, account for tank size, and the system estimates when the tank should need fuel.

That estimate is useful, but it is still an estimate. The system learns from past fills, then self-corrects in limited steps when actual deliveries do not match the prediction. In many platforms, that correction is intentionally capped so one odd fill does not throw the model too far off. If the K-factor is stale, the software may keep forecasting from a wrong base and only slowly move back toward reality.

ADD Systems, Cargas Energy, Energy Force, and similar platforms document this general approach in their own materials and training. The important point for an owner is simple: the forecast is built to answer when, not whether.

Why the estimate drifts

Forecasts drift because customers change faster than the model does. A house gets a heat pump. A family goes away for part of the winter. A will-call account becomes automatic delivery. A tenant moves out. A propane water heater is replaced. An acquired customer book arrives with imported values that were never validated against local usage.

Each of those changes alters consumption. The platform can only infer that something changed after enough deliveries reveal it. In a mixed estate, that means some accounts are being forecast from live telemetry, some from decent statistical history, and some from old assumptions that happen to still be in the system.

That is not a software failure so much as a limitation of the method. Degree-day forecasting works best when the customer behaves like the past. The further the account moves from that history, the more the estimate needs human review or a better signal.

Why the same forecast can justify opposite decisions

The owner's question is not "When will this tank be low?" It is "Is this stop worth making?" To answer that, you need two extra numbers: cost per stop and margin per gallon.

Cost per stop includes the driver's time, truck time, fuel, a share of branch overhead, and the hidden cost of making an unproductive trip. Margin per gallon is what you actually keep after product cost, freight, and the customer's price plan.

Now the same forecast can point to two different actions. A low-fill stop on a poor-margin account may be a bad use of labor. A similar stop on a high-margin account may be worth protecting because the customer is valuable, close to other stops, and likely to churn if the tank runs out.

Here is a simple illustrative example.

If the delivery is protected and the route is otherwise efficient, Account B is an obvious yes. Account A may still be worth serving if it sits on a dense route or if the customer is strategically important. But if it is a low-fill stop on a sparse route, the economics may say wait.

The point is not that one formula fits every dealer. The point is that gallons alone do not tell you whether the stop pays for itself.

Where tank monitors earn their keep

Tank monitoring helps most when the cost of being wrong is high. That means accounts with expensive runouts, remote locations, or high churn risk. It also means stops that are hard to bundle into dense routes.

A useful rule is to place the next monitor where it changes a decision, not where the tank is biggest. A large tank on a dense route may not need telemetry if the risk of a missed delivery is low and the route is already efficient. A smaller tank on a sparse route, or a customer with a history of sudden usage spikes, may deserve the monitor first.

That shifts the decision from "How many tanks can we watch?" to "Which unseen tank is costing us the most when we guess wrong?" If the runout cost plus lost margin is high enough, telemetry pays for itself quickly. If the account is easy to service and already stable, the monitor may add convenience without changing the economics.

From forecast report to ranked worklist

The small software layer many owners need is not a new delivery platform. It is a ranked daily exception queue.

That queue should combine a few signals that the base platform already knows or can ingest:

• accounts drifting away from their own historical burn pattern
• repeat low-fill stops that never reach an efficient truck load
• runout risk weighted by route position and customer value
• acquired accounts whose imported K-factors and hot-water gallons have never been checked
• monitor alarms that disagree with the statistical forecast

When those items are ranked together, the dispatcher no longer has to scan a long report and rely on memory. The day starts with a short list of exceptions: deliver now, defer, recheck, or validate the account.

That is a small build because it sits on top of the system of record. It does not replace ADD, Cargas, Blue Cow, Energy Force, or PDI. It reads the data those systems already store and adds your company's economics on top.

The account-level view most software does not show

Most delivery systems can tell you gallons delivered by account. Few can tell you whether a customer has ever paid back the full cost of the tank set, regulator, labor, inspections, and service work that came with the account.

That matters most in acquired books and in long-lived will-call accounts. If a customer took a tank set three years ago and has produced thin margin ever since, the delivery department may look busy while the account remains structurally weak. The only way to see that is to carry the economics from inception forward, not just the last route ticket.

This is where better reporting changes behavior. Once you can compare lifetime margin against customer acquisition and service cost, the question becomes sharper: which books have paid for themselves, and which are still being subsidized by the rest of the business?

Build the decision layer, not the whole stack

The right build-versus-buy decision is usually conservative. Keep the platform that handles tickets, routing, billing, compliance, and daily operations. Build or buy the layer that reflects your pricing, your routes, and your definition of a good stop.

That is the kind of work Better often sees in energy operations software: one system of record, plus a decision and reporting layer that turns operational data into something an owner can act on. For a related example of that pattern, see our energy work and the Nesh case study.

A first version of this layer does not need to be large. It should answer three questions:

• Which stops should we make today, and which should we defer?
• Which accounts have drifted far enough from history that their forecast should be reviewed?
• Which customers have not earned back the cost of serving them?

To support that, you need delivery history, ticket detail, monitor telemetry where available, pricing plan data, and service records. You do not need a full replacement of your dispatch system. In most cases, you need a clean integration and a ranking model that is honest about uncertainty.

A practical next step

If you run a propane or heating-oil delivery business, start with one route and one month of tickets. Assign a realistic stop cost, a gross margin per gallon, and a simple runout penalty. Then compare the platform's forecasted stops against the stops that actually protected margin.

The pattern usually becomes obvious quickly. Some low-fill stops are worth making because they protect dense routes or high-value accounts. Others are just activity. Once you can see the difference, tank monitors, dispatch exceptions, and account payback all become easier to prioritize.

FAQ

How often is propane delivered?

It depends on tank size, weather, appliance load, and whether the account is automatic delivery or will-call. Many automatic accounts are served several times each season, while others need only occasional fills. The software estimate is meant to predict that timing, not to decide whether the stop is profitable.

What is the minimum amount of propane delivery?

There is no universal minimum. Dealers usually set a practical minimum based on route economics, truck capacity, and customer policy. A very small fill may be acceptable if it is part of a dense route, but it can be expensive if it requires a special trip.

Do tank monitors pay for themselves?

They do when they prevent expensive runouts, reduce emergency dispatches, or improve route efficiency enough to justify the hardware and service cost. The best candidates are not always the biggest tanks. They are the tanks where a wrong guess is costly.

Should we replace our delivery software?

Usually no. If your current platform already handles dispatch, billing, and service, the higher-value move is often to keep it and add a decision layer above it. Replace the platform only if it cannot support the data integration or operational workflow you need.