Why Fuel Marketers Need Simpler Systems, Not More Software Noise
Every new tool promises control. But if pricing, dispatch, delivery, billing, and accounting still depend on manual handoffs, the operation is not getting simpler.
Walk into the back office of almost any mid-market fuel distributor and you will find the same thing.
Five, six, sometimes seven systems open at once. QuickBooks or an ERP for accounting. A separate dispatch tool, maybe a whiteboard. A pricing spreadsheet someone maintains by hand. A driver app that captures deliveries but doesn’t talk to billing. A CRM nobody updates consistently. A separate tool for AP matching. And the spreadsheet that ties it all together, because nothing else does.
Each one of those systems was purchased to solve a specific problem. Each one, on its own, probably does what it was bought to do.
The problem isn’t any individual system. The problem is that nobody owns the space between them.
What that looks like for one delivery
A dispatcher sends a load using today’s rack price. The driver delivers 4,200 gallons. Billing receives the ticket the next morning. Someone checks the pricing spreadsheet to confirm the rate that should have applied. Someone confirms the customer’s contract terms. Someone enters the invoice and hopes the accounting sync doesn’t create a duplicate.
That is not one workflow anymore. That is five systems asking a person to hold the process together.
The dispatch tool dispatched correctly. The driver app captured the delivery correctly. The pricing spreadsheet had the right rate, if someone updated it. The accounting system will record the invoice correctly, once someone enters it. Every system did its job.
Nobody owns the space between them. So a person has to.
How the stack gets built
Nobody sets out to build a seven-system back office. It happens one decision at a time, each one reasonable on its own.
The accounting system was already there when the company reached a certain size. Then dispatch got too complex for a whiteboard, so a dispatch tool got added. Then the driver app got purchased because paper tickets were creating billing delays. Then a CRM got added because sales wanted better visibility into the customer pipeline. Then an AP tool got added because the spreadsheet-based 3-way match was taking too long.
Each addition solved the problem it was bought for. Each addition also added a boundary, a place where data has to move from one system to another, and where it usually doesn’t move cleanly.
Every system boundary is a place where someone has to do the work the systems should be doing for each other.
Feature-level versus workflow-level
There is a common piece of advice in software buying: choose the best tool for each function. Best dispatch tool. Best accounting system. Best CRM. Best driver app. Stitch them together with integrations.
In theory this gives you the best of everything. In practice, the best tool for each individual function can still produce the worst outcome for the workflow that runs across all of them.
The dispatch tool might be the best dispatch tool on the market. The accounting system might be the best accounting system for a business your size. The driver app might have the cleanest interface in the industry. Each one, evaluated on its own, earns a high score.
But the delivery doesn’t happen inside any one of those systems. It happens across all of them, in sequence, with a person at every handoff making sure the baton gets passed correctly.
Best in class at the function level can still be worst in class at the workflow level. And in fuel distribution, the workflow is where the money is made or lost.
This is not an argument against specialized tools in general. A dedicated telematics platform for tracking truck location and driver behavior is genuinely best served by a specialized vendor. That is a complementary function, not part of the core operational chain. The distinction is between systems that handle the core chain, pricing through to cash, and systems that handle adjacent functions that can reasonably plug into that chain from the outside.
The core chain is where the feature-level versus workflow-level gap matters most. Because that is the chain where a broken handoff produces a late invoice, a pricing error, an inventory variance, or a duplicate payment. We have written about all of those in this newsletter. Every one of them traces back to a handoff between systems that didn’t talk to each other cleanly.
Why fuel is uniquely exposed to this
We have spent this entire newsletter establishing why fuel distribution workflows are harder than generic business workflows. Pricing that changes intraday based on rack postings. Volumes measured in gross and net gallons with temperature corrections. Inventory that exists in multiple states across terminals, trucks, and in-transit product. Dispatch that changes mid-route based on real-time customer needs.
Every one of those complexities becomes a boundary problem the moment two different systems are involved in the same workflow. The rack price needs to flow from a pricing system into a dispatch system into a billing system, and if those are three different systems, that price has to survive three handoffs without drift, delay, or manual re-entry.
A retail business with simple SKU-based pricing can tolerate a boundary between its POS system and its accounting system because the data crossing that boundary is simple and stable. A fuel distributor cannot tolerate the same boundary between dispatch and billing, because the data crossing that boundary, price, volume, timing, is exactly the data most likely to be wrong if it has to be re-entered or reconciled manually.
What “more software” actually buys you
When a workflow breaks down across system boundaries, the instinct is usually to add another tool. A middleware product to connect the systems. An integration platform. A reporting tool that pulls data from everywhere into one dashboard so at least someone can see the whole picture.
Each of these additions is reasonable. Each of them also adds a new system to the stack, a new place where something can break, and a new subscription to the monthly software spend.
The stack grows. The core problem, that the workflow crosses boundaries nobody designed for, does not get smaller. It gets more systems wrapped around it.
Complexity has a cost that doesn’t show up on any single vendor’s invoice. It shows up in the time someone spends reconciling data between systems. In the errors that happen at the boundaries. In the new hire who needs to learn seven systems instead of two before they can do their job independently.
The questions worth asking instead
Most software evaluations start with a feature list. Does it do pricing. Does it do dispatch. Does it do billing. Does it integrate with QuickBooks.
The more useful questions are about the boundaries, not the features.
When a load is dispatched, does the price get set automatically from the rack and contract terms that apply at that moment, or does someone need to check a spreadsheet?
When a driver confirms delivery, does that confirmation create the invoice, or does someone need to wait for the ticket to come back and re-enter the data?
When the invoice is created, does it sync to accounting cleanly, or does someone need to reconcile sync errors and duplicate entries?
When a supplier invoice arrives, is it automatically matched against the PO and BOL, or does someone need to find both documents and compare them manually?
If the answer to any of these is “someone needs to,” that is a boundary. And every boundary is a place where the workflow depends on a person remembering to do something, doing it correctly, and doing it on time.
The fewer of those boundaries exist in your core operational chain, the simpler your operation actually is, regardless of how many individual features any single piece of software has.
The question worth asking this week
Map your core operational chain. Pricing, dispatch, delivery confirmation, billing, accounting, purchasing, BOL matching, AP.
For each handoff in that chain, ask whether it happens automatically inside one connected system, or whether it requires someone to manually move information from one place to another.
Count the manual handoffs.
The software count does not matter nearly as much as the handoff count. In fuel operations, that is where complexity actually lives.
Next issue: Why fuel marketers need a single source of truth, not five versions of it.
About the author
I’m Dibyesh G., founder of Fueleo. I spend my time working with fuel marketers on the messy handoffs between pricing, dispatch, delivery, BOLs, invoicing, inventory, and accounting. This newsletter is where I write about the operational problems hiding inside everyday fuel workflows.