A few months ago I was sitting with a dispatcher at a mid-sized fuel operation.
She pulled up the tank monitoring screen. Forty-some sites. Every tank had a live reading. Product level, available gallons, last update time. Most had been reporting through the night.
It looked exactly like the kind of visibility software vendors put on the cover of a brochure.
I asked her how she used it.
“I check it when somebody calls worried they’re going to run out.”
That was the whole answer.
The data was there every hour, for every tank. But it was not deciding which sites got a load tomorrow. It was not telling her which stops belonged on the same truck. It was not flagging which customer was going to call at 8am before the customer knew they needed to call.
Those decisions still came from standing orders, experience, and whoever picked up the phone first.
The ATG was being used like a thermometer. You looked at it when you already suspected something was wrong.
She was not doing anything wrong. That is what makes this interesting.
What the data actually tells you versus what you need to know
A tank at 37% is a fact.
But a dispatcher does not need a fact. She needs an answer to a different question.
When will this become a problem?
A tank at 37% burning 120 gallons a day is fine. The same tank burning 900 gallons a day needs to be on tomorrow’s board. And that same tank might behave completely differently on Tuesday than it does on Saturday when the customer’s crew is running double shifts.
The percentage is just the starting point.
What you actually need is the tank level, the consumption rate, the delivery constraints, the truck capacity, and what else is already scheduled in that area.
A 37% reading does not tell you when to send a truck. It tells you where to start looking.
Why the data dies before it reaches dispatch
I keep seeing the same gap across fuel operations. The tank is connected. The readings are coming in. And none of it is making its way into the dispatch decision.
Here is why.
The monitoring system knows: Tank 3. ULSD. 31%. 2,480 gallons.
Dispatch needs to know: Which customer? Which ship-to location? Is this a keep-full account or will-call? Is there already an order scheduled? What are the delivery hours? Which terminal supplies it? Which truck can access the site?
Pulling a tank reading through a connection is the easy part. The harder part is building the relationship between the monitor and everything else the operation needs to know.
Monitor → Tank → Product → Customer → Order → Delivery
Without that connection, you have visibility. You do not have a workflow.
And then there is the trust problem.
Probes fail. Readings drift. Connectivity drops. After enough exceptions, dispatchers start building their own mental correction layer. That one always reads a little low. Do not trust that reading right after a delivery. That monitor has not reported since yesterday.
Eventually the dispatcher trusts experience more than the screen. And experience is very hard to integrate with anything.
Have a lesson worth sharing?
Some of the best lessons in fuel operations never make it into a playbook.
They live in the experience, workarounds, mistakes, and tribal knowledge of people doing the work every day.
If you have something you have learned that could help another fuel marketer, I would love to hear it.
It may become part of a future issue of The Fuel Stack.
Dibyesh Giri.
What the data should actually do
I would not want a system automatically creating orders because a tank crossed 30%.
That just replaces one rigid rule with another.
What I would want is the system telling the dispatcher every morning:
Seven tanks are likely to need attention in the next 48 hours.
Then explain why.
Tank A is projected to hit its reorder point tomorrow afternoon based on this week’s consumption.
Tank B’s usage jumped 34% over its normal pattern. Worth a call.
Tank C has enough fuel until Friday but there is already a truck going within five miles of it tomorrow.
Tank D looks low but there is already an order on the board.
Tank E has not reported in eleven hours.
Now the dispatcher is not opening two hundred tank screens looking for trouble. She is looking at five things that deserve her judgment.
ATG data should reduce the search space. Not replace the dispatcher.
That is the immediate value. Not full automation. Just better information reaching the right person earlier in the day so the decision gets made before the customer calls instead of after.
The loop that almost nobody closes
Here is the part I find most interesting.
The tank predicted a delivery. The dispatcher approved it. The truck lifted the product. The driver delivered it.
Now ask: did the gallons reconcile?
The customer tank showed 1,900 gallons before the truck arrived. The meter says 4,100 gallons were delivered. What did the tank show afterward?
Not necessarily exactly 6,000 gallons. Product may have been consumed during delivery. Temperature matters. Measurement has tolerance. But you now have two independent signals you can compare.
And on a full route: terminal BOL, truck inventory, metered delivery, customer tank movement.
The ATG is not just telling you when to deliver. It is helping you validate what happened after you delivered.
That matters for inventory. It matters for billing. It matters for finding the tanks whose readings you cannot trust and figuring out why.
Over time the data starts auditing itself. The tanks that consistently reconcile earn confidence. The ones that consistently show unexplained differences get flagged. Maybe the probe needs calibration. Maybe the product mapping is wrong. Maybe the reading is being assigned to the wrong asset.
The system builds a picture of which monitors are trustworthy without the dispatcher having to maintain that list in her head.
Try it with ten tanks
You do not need a new platform to start seeing whether this matters.
Pick ten tanks you already monitor. For two weeks, record the morning reading and the actual delivery.
Then ask a few simple questions.
How many deliveries happened because the customer called? How many could you have anticipated from the consumption pattern? How much usable capacity was still in the tank when the truck arrived? How often did you go into an area and then return to roughly the same area a day or two later? Did the metered delivery roughly match what the tank showed?
Do not automate anything yet. Just look.
You will start seeing where the decisions are hiding.
The expensive part is already done
The probes are in the tanks. The connectivity exists. The readings are coming in. The history is accumulating.
In most operations I visit, the data already exists to answer much more useful questions than how much fuel is in this tank right now.
The questions worth asking are simpler.
Which tank needs fuel next? When will it need it? How much should we send? Can it fit into a load we are already planning? And after we deliver, did the gallons agree?
Until those questions get answered from the data, ATG is not really tank monitoring. It is a very expensive thermometer that tells you something is wrong after someone calls to tell you something is wrong.
The readings have been coming in for years.
It is time to start using them.