Every fuel operation I visit has one.
Sometimes it is a spreadsheet open on a second monitor. Sometimes it is a shared Google Sheet three people edit simultaneously and nobody fully trusts. Sometimes it is a laminated sheet taped to the wall beside the dispatch desk. Sometimes it is a group text that has been running for two years and contains more operational decisions than any system in the building.
I stopped calling these workarounds a long time ago.
I started calling them signals.
Every workaround in a fuel operation is a signal that the software stopped where the operation did not.
What the workaround is actually telling you
When a dispatch manager opens a spreadsheet before assigning a load, he is not doing it because he enjoys maintaining two sources of truth.
He is doing it because the dispatch system does not know that this customer only accepts deliveries before 6am. Or that this driver cannot go to that terminal because of an incident three months ago that was never logged anywhere official. Or that this load needs to be split across two compartments in a specific sequence because the customer has two tanks and one of them has a slow intake valve.
The dispatch system handles what it was built for. The spreadsheet handles what the dispatch system does not understand.
That boundary, the edge of what the software can do, is exactly where the workaround begins.
Every morning before the first truck rolls, the dispatcher is doing two jobs simultaneously. The visible job is assigning loads in the system. The invisible job is applying a layer of operational knowledge the system has never been taught.
Which driver fits which customer. Which terminal to avoid after 10am. Which load needs a phone call before the truck leaves the yard. Which delivery window is non-negotiable and which one has a thirty-minute buffer the customer will never mention but always expects.
None of that is in the dispatch system. It is in the spreadsheet. Or in the dispatcher’s head. Or in a notes field that one person maintains and nobody else reads.
The dispatcher is not the problem. The software did not understand the operation well enough to hold what the dispatcher was carrying manually.
And as long as that knowledge lives outside the system, the operation is one retirement, one resignation, or one bad morning away from a day that does not run the way it should.
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 G.
The group text that runs the dispatch
One of the most revealing workarounds I have seen in fuel distribution is not a spreadsheet. It is a phone.
A dispatcher in East Texas managed a fleet of twelve trucks through a combination of a dispatch system and a group text that had been running for three years. The dispatch system handled the scheduled loads. The group text handled everything else.
Driver calls in sick at 5am. Group text.
Terminal goes down at 7am. Group text.
Customer changes the order after the truck has already left the yard. Group text.
The dispatch system was technically capable of handling some of these scenarios. But it was not fast enough, flexible enough, or visible enough to the right people at the right moment. So the group text filled the gap.
By the time I saw it, the group text had become the real dispatch system. The software had become the record-keeping layer that documented decisions that had already been made somewhere else.
That is what a workaround looks like when it has been running long enough. It stops feeling like a workaround. It becomes the system.
The binder that ran the pricing
I visited a mid-market fuel wholesaler in Washington state last year.
Their pricing manager had a binder.
Not a binder of reference material. A binder of decisions. Thirty-seven customer accounts, each with a page that described how that customer’s price was calculated. Which rack posting to use. Which differential applied. Whether freight was included or billed separately. Whether the customer was on gross or net gallons. Whether there were volume tiers that changed the margin at certain thresholds.
Every one of those pages represented a decision the pricing system could not make on its own.
When an order came in, the pricing manager opened the binder, found the right page, and manually applied the correct logic before the invoice was generated.
She had been doing it for four years. She was fast. She was accurate. She knew every account well enough to catch errors before they reached the customer.
I asked her what would happen if she was not there.
She thought about it.
“They would call me.”
The binder was not a failure of organization. It was four years of operational knowledge that the pricing system had never been built to hold.
Why software creates workarounds in fuel distribution specifically
Most back-office software was not built for fuel distribution.
It was built for businesses that sell discrete products at fixed prices to customers with standard billing requirements.
Fuel distribution does not work that way.
The price changes intraday. The product that leaves the terminal is measured differently than the product that arrives at the customer’s tank. The customer’s billing requirements vary by account, by location, by product type, and by a contract that was negotiated at a specific moment in the market. The freight cost depends on which carrier ran the load, which route they took, and whether there were detention charges the customer may or may not be responsible for.
Generic software handles the standard case. Fuel distribution is full of cases that are not standard.
The workaround is what happens every time the software encounters a case it was not built for and the team has to bridge the gap manually.
In a small operation with low volume, the workarounds are manageable. The dispatcher knows the spreadsheet. The pricing manager knows the binder. The team carries the knowledge and the operation runs.
Then the operation grows.
More trucks. More customers. More loads per day. More edge cases per week. More people who need to share knowledge that used to live in one person’s head.
The workarounds do not scale the way the business does.
What happens when the workaround fails
Most workaround failures in fuel distribution are not dramatic.
They are quiet.
The pricing manager goes on vacation and a new hire applies the standard rate to three accounts that have negotiated differentials. Nobody notices for two weeks. The customer calls on week three.
The dispatcher’s group text loses a message during a busy morning and a driver does not get the update about the terminal that went down. The load gets turned away. The driver waits. The delivery misses the window.
The billing spreadsheet and the accounting system go out of sync during a month-end rush and nobody has time to reconcile them until the following week. Three invoices go out late.
None of those are catastrophic. All of them are expensive. And all of them were predictable consequences of an operation that had grown past what its workarounds could reliably handle.
The workaround works until it does not. And when it stops working, it usually stops working at the worst possible moment.
What the software should do instead
The answer is not better training on the existing software.
The answer is not adding more features to software that was not built for fuel distribution in the first place.
The answer is software that understands the operation well enough that the workaround is no longer necessary.
For the dispatcher with the spreadsheet: customer delivery windows, driver restrictions, terminal preferences, and split-load logic should live in the dispatch system and apply automatically when a load is assigned. Not in a spreadsheet he maintains separately.
For the dispatcher with the group text: mid-route changes, terminal alerts, and driver availability updates should be visible to everyone who needs them inside the dispatch system in real time. Not communicated through a text chain that nobody can search or audit.
For the pricing manager with the binder: every customer’s pricing logic, differentials, volume tiers, freight treatment, and gross or net billing preference should live in the pricing system and apply automatically when an order is created. Not reconstructed manually from a printed page every time a load is dispatched.
The workaround disappears when the software understands what the team was doing manually and builds it into the workflow.
That is the standard we hold ourselves to at Fueleo.
Every time we see a spreadsheet beside a dispatch system, a group text running alongside a load board, or a binder of pricing decisions sitting next to a software platform, we ask the same question.
What did the software not understand that the workaround was compensating for?
The answer to that question is a gap worth closing.
The question worth asking this week
Walk through your operation and count the workarounds.
The spreadsheets that live beside your systems. The group texts that coordinate decisions your software should be coordinating. The binders, the printed sheets, the sticky notes, the shared drives full of documents that exist because your software does not carry that information automatically.
Count them.
Then ask about each one: what does this workaround know that my software does not?
That list is not a list of your team’s inefficiencies. It is a list of the gaps in your software’s understanding of your operation.
And until those gaps close, the workarounds will keep running. Getting faster. Getting better. Getting more embedded in how the operation actually works.
Until the day they stop working.