If your business sends trucks out to refill other people's containers — propane, heating oil, diesel, bulk water, CO2, ice, pool chemicals, or pumped septic and grease traps — you already know the two ways delivery gets scheduled: the calendar and the phone. Either you put every customer on a route cycle ("every customer gets a stop every six weeks") or you wait for will-call customers to call when they think they're low. Both approaches are guesses, and both guesses eventually produce the same phone call: a customer with no heat, a kitchen that can't cook, or a pool that's turning green, on the worst possible day, needing an emergency run.
Tank level monitoring automation replaces the guess with a signal. Instead of deciding who gets a stop based on the calendar or a customer's hunch, you decide based on what's actually in the tank and how fast it's actually draining. This guide walks through why traditional scheduling breaks down, what a good automated flow looks like, how to build it end to end without writing code, and the mistakes that sink dealers who try. It's written for operations people, founders, and ops teams at local and field service businesses — no data science degree required.
(Note: this article is about deciding who needs a stop and when, based on telemetry from the customer's container. If you're looking to optimize a day's route that's already been decided — sequencing stops, drive times, and proof of delivery — that's a different problem, covered in our guide to daily route planning automation.)
Why Calendar-Based Delivery Fails
Calendar routing feels safe because it's predictable. Every customer gets a stop every N weeks, the route book fills itself, and nobody has to think. But the predictability is an illusion, because consumption isn't on a calendar. Here's where it breaks down.
The route is padded with stops that aren't needed
The dispatcher's rule of thumb — "this household is about 220 gallons per cycle" — is an estimate that was probably written down years ago and never updated. In reality, burn rate changes with:
- The weather. A mild stretch can cut heating demand in half; a January cold snap can double it. The calendar doesn't know what the thermometer did.
- The household. Kids move out, someone works from home now, a relative moves in, the family takes a month-long vacation. Same house, same tank, completely different consumption.
- The equipment. A new high-efficiency furnace, a failing water heater, a converted appliance, a slow leak — all of these change the burn profile, and none of them update the route book.
The result: on any given route day, a meaningful share of your stops are tanks that are still three-quarters full. You're paying for a truck, a driver, and an hour of drive time to deliver a top-off the customer didn't need.
Meanwhile, someone on the same route runs dry
The flip side of padded routes is the run-dry. One customer on that same route burned faster than their "about 220 gallons" estimate — cold snap, new tenants... rather, new occupants, a broken appliance — and their tank hit empty three weeks before their calendar slot. Now it's an emergency:
- A frozen or near-frozen home in winter, with pipe-burst risk attached.
- A restaurant that can't cook, or a kegerator and CO2 supply that just went flat mid-service.
- A full protocol response on your end: pilot-light restart, leak test, system purge, safety documentation — during your busiest week, for a customer who is also having a bad day.
Run-dries don't just cost you an unscheduled truck roll. They eat the day, they carry safety and compliance implications, and they quietly erode customer trust more than almost anything else you can do.
Will-call customers run out precisely because they guess
Will-call sounds like a feature — the customer tells you when they're low. But customers are terrible at gauging tank levels. They check when they remember, they eyeball a gauge they can barely read, and they call "when it feels about right." Then a cold snap hits, their burn rate doubles, and their guess of "I've got two weeks" turns into three days. The will-call model doesn't eliminate emergencies; it just makes the customer responsible for causing them.
The dispatcher's estimate isn't a forecast
None of this is a dig at dispatchers. They're juggling hundreds of accounts in a spreadsheet or a route book, working from stale notes, and doing the best they can with the information available. The problem isn't the person — it's that the information doesn't exist in a calendar-based system. Nobody knows the actual level in the tank or the actual rate it's draining. Which is exactly what telemetry fixes.
What Tank Level Monitoring Automation Actually Does
Tank level monitoring automation is a simple idea with a lot of moving parts done right: put a sensor on the container, let the sensor report level and usage automatically, compute each customer's real consumption rate and a rolling forecast of days until empty, and use that forecast — not the calendar — to decide who gets a stop and when.
A good flow does five things continuously:
- Reads every tank. Cellular or satellite tank level monitors report each container's current level and daily usage automatically, whether it's a 500-gallon residential propane tank behind a farmhouse or a bulk CO2 cylinder at a brewery. No driver has to eyeball a gauge; no customer has to call.
- Computes a real burn rate. The system looks at actual usage over recent days and weeks and derives each customer's true consumption — not "about 220 gallons per cycle," but "this tank is drawing X gallons per day right now, and that rate has been rising for a week."
- Forecasts days to empty. From the level and the burn rate, the system projects a rolling days-to-empty number for every tank in your book, updated as the weather and the usage change.
- Queues deliveries by threshold, not by date. When a tank's forecast crosses your threshold — for example, when it hits 30% remaining or a projected 14 days to empty — the customer is queued for delivery. When a calendar page turns, nothing happens. When a tank runs down, something does.
- Closes the loop after the fill. After delivery, the post-fill level reading is reconciled against the delivery ticket, so a missed fill, a misread sensor, or an undelivered ticket is caught the same day — not at the next emergency.
The payoff is qualitative but real: fewer run-dries and emergency calls, less wasted drive time on tanks that didn't need a stop, better truck fill per route mile, and a dispatcher who starts the day with a queue ranked by urgency instead of a stack of calendar pages.
How to Build Tank Level Monitoring Automation End to End with No Code
Here's the part that surprises most dealers: you don't need a custom software project to run this. Modern tank monitors handle the hardware side, and a no-code automation platform handles everything between the sensor and your dispatcher. With a platform like Automate Anything, you can connect your monitoring data, your delivery system, and your communication tools into one flow without writing a line of code.
Here's the end-to-end architecture, piece by piece.
Step 1: Get tank telemetry flowing in
Your tank monitors — cellular units for most locations, satellite units for remote tanks where cellular coverage is spotty — already report level readings at regular intervals, often daily or multiple times per day. Most monitor vendors can push those readings to a webhook, an email, a file export, or an integration endpoint.
Your automation flow's first job is to receive those readings and normalize them: match each sensor to the right customer and the right tank record, capture the level, the reading timestamp, and the tank size. This mapping step matters — a reading from an unmarked sensor is just a number.
What you need: a list of every tank (customer, address, tank size, sensor ID, product type) and access to your monitor vendor's data feed (webhook, export, or API connection).
Step 2: Compute burn rate and days-to-empty
For each tank, your flow maintains a running picture:
- Recent daily usage — the difference between consecutive readings, adjusted for any deliveries in between.
- Current burn rate — typically a blend of recent days weighted toward the present, so a sudden cold snap shows up quickly. A common practical approach is to track both a short-window rate (the last several days, which reflects current weather) and a longer-window rate (the last few weeks, which smooths out noise), and use the short window for urgent tanks.
- Days to empty — current level divided by current burn rate. A tank at 45% with a burn rate of 6 gallons a day on a 500-gallon tank has roughly 22 days left. That number rolls forward every day as new readings arrive.
No-code platforms handle this with scheduled jobs that run daily per tank, simple math steps, and a data store that holds each tank's recent history. You configure the logic once; it runs for every tank in your book.
Step 3: Set thresholds and queue customers for delivery
This is where your operating judgment comes in. Define a delivery trigger threshold — for example, "queue the customer when projected days-to-empty falls below 14 days, or when level drops below 30%, whichever comes first." You might use different thresholds for different seasons, different products, or different customer classes (a restaurant's CO2 tank might warrant a more aggressive threshold than a seasonal pool customer's chemical drum).
When a tank crosses the threshold, the flow adds the customer to a delivery queue with a priority based on urgency: a tank projected to empty in 12 days outranks one projected at 26 days, even if both are "queued."
Step 4: Group queued customers into efficient route days
A queue sorted by urgency isn't a route. The next step groups queued customers by geography and urgency so trucks fill sensibly:
- Tag each queued customer with a route zone or driver territory.
- Each day (or each planning cycle), the flow pulls the queued customers whose urgency falls inside your delivery window and groups them by zone.
- The dispatcher gets a ranked list per zone — who needs a stop, how urgent, how big the expected fill — and can hand it to routing or to your existing route-planning process.
This is the clean handoff point to daily route planning: tank level monitoring automation decides who needs a stop; your route-planning process decides the best order to hit them. Together they cover the whole dispatch decision.
Step 5: Send will-call nudges automatically
For will-call customers, don't wait for the phone to ring. Attach a monitor to their tank too (or start with your worst offenders), and let the flow send an automatic nudge when their level hits your nudge threshold — say, 25% or 18 days to empty:
- To the customer: a friendly text or email — "Your tank is projected to need a refill in about two weeks. Reply to this message or tap here to schedule your delivery." This keeps the will-call relationship but removes the guesswork.
- To your office: the customer is also added to your watch list, so if they don't respond, you can follow up proactively rather than discovering the problem via a no-heat call.
Step 6: Flag forecast breaches inside your delivery window
This is your safety net. Set up an alert that fires whenever a tank is projected to hit empty inside your current delivery window — for example, if your routes run on a 10-day cycle and a tank's forecast says 8 days, that's a breach. The flow sends an immediate alert to the dispatcher (and optionally an escalation if unacknowledged), so the tank gets slotted onto the next route day — or an emergency run if it's already too late. This single alert is what turns "nobody freezes" from an aspiration into an operational rule.
Step 7: Reconcile post-fill readings against delivery tickets
After every delivery, the loop closes:
- The driver completes the delivery and a ticket is recorded (from your delivery or field service software).
- The next sensor reading comes in, and the flow checks it: does the post-fill level make sense given the ticketed gallons? A tank that received 150 gallons should show a meaningful level rise.
- If the post-fill reading doesn't reconcile — the level didn't rise as expected, or a ticket exists with no corresponding reading change — the flow flags it the same day.
This catches the quiet failures that calendar systems discover weeks later: a fill that didn't actually happen, a stuck or misreading sensor, a ticket keyed to the wrong account, a delivery made to a neighbor's tank. Catching it the same day means a same-day fix instead of a customer with a full tank, a ticket for fuel they didn't get, and a burn-rate model that's now silently wrong.
Calendar Routing vs. Will-Call vs. Telemetry-Driven Scheduling
Since there's no single scheduling model that fits every dealer, here's a side-by-side comparison of the three approaches. (We'll use lists rather than tables to keep this readable on any device.)
Pure calendar routing
- How it decides: every customer gets a stop every N weeks, period.
- Strengths: simple to run; predictable workload; no customer hardware needed; keeps cash flow steady in mild weather.
- Weaknesses: routes padded with unnecessary stops; run-dries happen whenever real burn outruns the calendar; estimates go stale silently; zero visibility until the driver is standing at the tank.
- Where it fits: very small books with homogeneous customers, or as a stopgap before telemetry.
Will-call only
- How it decides: the customer calls when they think they're low.
- Strengths: minimal scheduling overhead; no forecasting to maintain; customer feels in control.
- Weaknesses: customers guess wrong, especially during weather swings; emergency calls land on your busiest days; no route density to plan around; the burden of monitoring is on the least-informed party.
- Where it fits: genuinely seasonal or intermittent demand (a camp cabin, a pool that's drained each fall), or customers who truly want full control.
Telemetry-driven scheduling
- How it decides: actual tank level and computed burn rate trigger a queue entry when a threshold is crossed.
- Strengths: stops go where the fuel actually is; run-dries get caught by forecast-breach alerts before they happen; will-call customers get nudged before they can guess wrong; post-fill reconciliation catches errors the same day; route density improves because you're only stopping at tanks that need it.
- Weaknesses: requires monitors on tanks (hardware cost per unit, and satellite units for coverage gaps); requires an automation flow to be built and maintained; requires discipline around thresholds and reconciliation.
- Where it fits: any dealer with enough tanks and enough run-dry pain that guessing costs more than the monitors.
The hybrid that most dealers land on
In practice, most successful rollouts are a hybrid: telemetry-driven scheduling for your monitored tanks, automatic will-call nudges for customers who want to stay in the loop, and calendar routing retained only for edge cases where a monitor doesn't make sense (a tiny seasonal account, a tank scheduled for replacement). The hybrid keeps the strengths of each model and lets you migrate accounts over time rather than flipping the whole book at once.
Rollout Checklist: Start with Your Worst Run-Dry Customers
You don't need to instrument your entire book on day one. The fastest way to prove the value of tank level monitoring automation — to yourself, your dispatchers, and your drivers — is to start where the pain is loudest. Here's a practical rollout sequence:
- List your run-dry history. Pull every run-dry, emergency call, and will-call miss from the last one or two seasons. These customers are your pilot group — they're the ones whose "about 220 gallons" estimate is already proven wrong.
- Add monitors to the pilot tanks. Prioritize cellular monitors for tanks with coverage and satellite monitors for remote locations. Note tank size, product, and address for each.
- Map sensors to customers and tanks. Build your tank register: customer, address, tank size, sensor ID, product type. This is the foundation everything else runs on — don't rush it.
- Connect the data feed to your automation platform. Get readings flowing in via webhook, export, or integration, and verify that each reading lands on the right customer.
- Let the data season for two to four weeks. Before you trust any forecast, let the flow collect enough readings to compute a stable burn rate per tank. Use this period to sanity-check the numbers against what your drivers actually see.
- Set your thresholds. Pick a delivery trigger (e.g., 30% or 14 days-to-empty), a will-call nudge threshold (e.g., 25% or 18 days), and a breach alert rule (projected empty inside your delivery window).
- Turn on queueing and breach alerts. Start dispatching pilot customers by threshold instead of by calendar. Watch what happens on the first cold snap.
- Turn on will-call nudges for pilot customers who are will-call accounts.
- Enable post-fill reconciliation. After each pilot delivery, verify that the post-fill reading matches the ticket. Fix the process gaps this exposes.
- Review with dispatch after one full cycle. Compare emergency calls, wasted stops, and route density before and after. Then expand to the next tier of your book — the big tanks, the far-flung tanks, the customers who've had close calls.
Common Mistakes (and How to Avoid Them)
Every dealer who's rolled out telemetry has stepped on at least a few of these rakes. Learn them the cheap way.
Thresholds that ignore weather-driven burn
A static threshold like "deliver at 30%" looks sensible until a cold snap doubles burn rates across your whole territory overnight. A tank at 30% in October has weeks of runway; the same tank at 30% during a January arctic blast might have days. Build seasonality into your thresholds — tighter days-to-empty triggers in your peak heating season, more relaxed triggers in the shoulder months — or lean on your flow's short-window burn rate, which naturally reflects current weather. Revisit thresholds every season; they're not set-and-forget.
Alert fatigue from noisy sensors
If your flow alerts on every wobbly reading, your dispatcher will start ignoring alerts within a week, and then your safety net is gone. Common noise sources: tanks that are read infrequently (producing chunky, spiky usage numbers), sensors with intermittent connectivity, and usage spikes that are actually deliveries your flow didn't know about. Fix it by:
- Feeding known deliveries into the flow so fills don't register as usage spikes.
- Requiring a sustained signal (e.g., a breach confirmed by two consecutive readings) before paging the dispatcher for non-critical alerts.
- Keeping the breach alert (projected empty inside the delivery window) loud and unignorable, while softer signals — a single odd reading, a slowly drifting sensor — go into a daily digest instead.
The rule of thumb: every alert should be one a dispatcher would act on. If it wouldn't be, route it to a report instead.
Not reconciling post-fill readings
This is the step most dealers skip, and it quietly poisons everything downstream. If you don't reconcile post-fill readings against tickets, then: your burn-rate calculations get corrupted by unreconciled fills (the flow thinks the tank burned 150 gallons in a day when it was actually filled); missed fills go unnoticed until the customer runs dry; and misread sensors stay misread. The reconciliation step costs you almost nothing once it's built, and it's the difference between a telemetry system you can trust and one you're constantly second-guessing.
Ignoring tank size differences
A tank at 40% is a completely different situation at 100 gallons than at 1,000 gallons, and days-to-empty handles this far better than a raw percentage — but only if tank size is recorded correctly in your tank register. A wrong tank size makes every forecast wrong by a constant factor. Also watch for accounts with multiple tanks on one customer record (a dual-tank propane setup, for example): your flow needs to treat each tank's level and burn independently, and the customer's delivery trigger should reflect the combined picture.
Treating the monitor vendor and the automation as one purchase
Tank monitors report levels; they don't queue deliveries, compute rolling forecasts, nudge will-call customers, reconcile tickets, or escalate unacknowledged breaches. Buying monitors and assuming the vendor's portal solves scheduling is like buying a thermometer and assuming it cooks dinner. You need a layer that turns readings into dispatch decisions — which is exactly what a no-code automation platform provides, and why monitor vendors' portals and no-code tools like Automate Anything's features complement rather than replace each other.
Forgetting the customer communication side
Telemetry changes your back office; it should also change what your customers experience. The same flow that queues a delivery can send the customer a heads-up ("we're planning to fill your tank this week"), a confirmation after the fill, and a nudge if they're a will-call account. Customers who can see that you're watching their tank — instead of guessing at it — tend to be calmer, more loyal, and far less likely to top off with a competitor because they weren't sure you were coming.
Frequently Asked Questions
Do I need monitors on every tank to make this work?
No. The hybrid model exists precisely because a full-book rollout isn't always practical on day one. Start with the tanks where run-dries and guesswork hurt most: your worst offenders, your largest tanks, your remote tanks that are expensive to check manually. Every tank you add removes another guess from the book. Unmonitored tanks can stay on calendar routing or will-call with nudges until you migrate them.
What about tanks where cellular coverage is poor?
Satellite tank monitors exist for exactly this reason. Remote farms, cabins, rural commercial accounts, and tanks in metal enclosures or basements that block cellular signal can all use satellite units that report through the same data feed. Expect satellite hardware to cost more per unit and sometimes report less frequently — factor that into which thresholds you apply to those tanks (a longer reporting interval means you want a wider safety buffer in your days-to-empty trigger).
How is this different from just using my delivery software's routing features?
Delivery and routing software optimizes the route for stops you've already decided on. It answers "what's the best order for tomorrow's 18 stops?" Tank level monitoring automation answers a different and earlier question: "which customers need a stop at all, and how urgently?" The two are complementary — telemetry decides who goes in the queue and how urgent they are; your routing layer sequences the day. Dealers who conflate the two usually end up with beautifully optimized routes full of stops that didn't need to happen.
Will this eliminate emergency runs entirely?
Honest answer: no system eliminates them entirely — sensors can fail, customers can unexpectedly fire up a pool heater, a stove can be left running. But a well-built flow converts most emergencies into scheduled stops, because the breach alert catches tanks projected to empty inside your delivery window before they actually empty, and post-fill reconciliation catches the delivery errors that would otherwise resurface as run-dries. The goal isn't zero surprises; it's that surprises become rare, visible early, and manageable rather than landing mid-route on your busiest day.
How does this work for products other than propane and heating oil?
The logic is product-agnostic. Bulk water haulers monitor cisterns and schedule by consumption rate. CO2 suppliers watch beverage cylinders at restaurants, where a run-dry means flat drinks and a lost account. Ice suppliers track merchandiser and storage levels. Septic and grease-trap pumpers use level telemetry to convert "pump every 90 days" into "pump when the tank actually needs it" — which is the same calendar-versus-reality problem in a different container. Pool and chemical refill services apply the same model to chemical tanks and drums. If it's a refillable container with a level that rises and falls, the same flow applies: readings in, burn rate computed, threshold crossed, delivery queued, fill reconciled.
What data do I need before I can build this?
A surprisingly short list: a tank register (customer, address, tank size, sensor ID, product), access to your monitor vendor's data feed, a delivery or field service system that records tickets (so reconciliation has something to check against), and your thresholds. If you're missing any of these, you can still start — build the flow for the tanks you can fully instrument, and add the rest as your register and ticketing catch up.
How long does it take to build a flow like this?
For a no-code platform, the core flow — readings in, burn rate and days-to-empty computed, threshold queueing, breach alerts — is typically a matter of setting up the data mapping and configuring the logic steps, not a software project. The longer pole is usually the data seasoning period: you need a few weeks of readings per tank before the forecasts are trustworthy. Plan for a season of pilot operation before you judge results, and expand the book from there.
The Bottom Line
Calendar routing and will-call guessing both put the decision in the hands of the party with the least information — the calendar doesn't know the weather, and the customer can't read their own tank. Tank telemetry puts the decision where the information actually is: in the tank itself. Monitors report levels and usage, your automation computes real burn rates and rolling days-to-empty forecasts, thresholds queue the customers who genuinely need a stop, breach alerts catch the tanks that would otherwise run dry, and post-fill reconciliation keeps the whole system honest — all without a line of code.
If you're ready to see what your routes look like when they're driven by data instead of dates, browse more guides on the Automate Anything blog, or start building today.
Build your first automation at https://automateanythingsoftware.com