Bob Has Been Dispatching for Forty Years. Here Is What Building for Him Actually Looks Like.
The best software decisions I have made came from watching someone work before I touched a single feature.
The phone rang before Bob finished his sentence.
He picked it up, said a few words, looked at the load chart on his screen, moved a station from one split to another, changed the compartment assignment on the truck, and called the driver.
Three minutes. Maybe less.
I needed another fifteen minutes afterward just to understand everything that one decision had touched.
That was my introduction to how Bob dispatches fuel in East Texas.
The office
Bob is seventy four years old. He has been running dispatch and operations at this common carrier for four decades. His desk had two monitors, a printed load sheet beside the keyboard, and a phone that did not stay quiet for long. Driver names highlighted in different colors. Terminal notes written in the margins. A stack of dispatch packets waiting to be printed.
The spreadsheet on his left monitor had forty years of revisions. New colors. New tabs. Notes tucked into cells referencing decisions made years ago. It had grown alongside the operation. You could almost read the company’s history in it.
I had expected whiteboards and sticky notes and a system that mostly lived in someone’s head.
What I found was something more interesting. Bob had turned four decades of experience into a visual system that other people could follow.
The spreadsheet was not for him. He already knew the answers. It was for everyone else.
What four decades actually looks like
Bob started dispatching when everything was paper. Load sheets written by hand. Delivery tickets carried back by the driver at the end of the shift. Customer calls taken on a landline with a notepad on the desk.
At some point the fax machine changed things. Then spreadsheets changed things.
But the core of the job never changed.
Knowing the trucks. Knowing the terminals. Knowing the drivers. Knowing which station needs to be hit first and why. Knowing that one customer always changes the order after the packet is printed and that one terminal backs up by 10am on Fridays.
The tools got faster. The judgment stayed the same.
I asked Bob if he had looked at dispatch software before.
He had. More than once.
“The demos always looked clean,” he said. “The reality always looked different. The systems wanted me to work the way they were built. They did not know how my terminals worked, how my drivers worked, or why certain stations had to be delivered in a certain order.”
So the spreadsheet survived. Every time.
Not because Bob was resistant to change. Because nothing he had seen was built around how the job actually works.
The morning before the first truck rolls
Before I arrived I thought the hardest part of common carrier dispatch was routing. Getting trucks to the right places in the right order.
Sitting with Bob changed that.
The hard part is everything that changes after you think you have the plan.
A driver calls in sick. The terminal runs out of premium. A customer adds 1,500 gallons after the packet is already printed. Bob crossed out the original quantity that morning, rewrote the compartment split by hand, and called the driver because the paper packet was now wrong before the truck had even left the yard.
One small change does not stay small. One compartment reassignment touches three loads. One late driver shifts two routes. One terminal running slow pushes the whole day back.
And all of it lands on Bob’s desk before 7am.
The load chart
The first thing Bob walked me through was the load chart.
Every truck broken down by compartment. Product assigned to each slot. Gallon capacity. Delivery sequence.
Before I understood what I was looking at I thought it was about truck capacity. It was not. It was also a training document, a quality control check, and a communication tool rolled into one.
“I have a mix of new and old drivers,” Bob said. “The experienced ones know the trucks. They load and go. The new ones are still figuring things out. This chart tells them exactly which product goes in which compartment. I do not want a new driver putting diesel in the wrong compartment because nobody told them clearly.”
An experienced driver looked at a list of customer names and already knew the likely sequence, the terminal, the compartment setup. A new driver needed every detail written out. The same dispatch packet had to work for both.
Without the chart, the calls started.
“Bob, which compartment is diesel again?”
“Bob, am I loading at Mount Pleasant or Tyler?”
“Bob, which station do I hit first?”
Every one of those calls interrupted dispatch. The load chart was Bob’s way of answering those questions before they got asked.
Bob knew his drivers the way a coach knows a roster. He knew which driver could handle a complicated split load without calling in. He knew which driver needed the terminal written at the top of the packet in large letters because he had missed it before. He knew which driver would push back on a sequence change and which one would just figure it out.
That knowledge was not in any system. It lived in Bob.
The split load logic
The second thing Bob showed me was how he groups his gas stations.
Not alphabetically. Not by account number. By proximity to each other and by which terminal serves them.
“Split loads,” he said. “If I know which stations are close together and which terminal serves them, I can plan a split load in about two minutes. Group the stations, match the terminal, figure out the compartment breakdown, done.”
I initially thought this was a routing problem. Bob showed me it was equally a terminal problem, a compartment problem, a product problem, and a driver-familiarity problem all at once.
The groupings in that spreadsheet were not random. They were the result of thousands of routes, dozens of terminal relationships, and forty years of learning which combinations worked and which ones created problems later in the day.
What happens when Bob takes a vacation
I asked him what happens when he takes a week off.
He smiled.
“I don’t.”
Not complaining. Just stating something that had become true over time.
I pushed a little. What would actually happen if he did?
“They call me anyway.”
Then I asked him what he wanted the operation to look like in five years.
He thought about it for a moment.
“I want whoever does this job after me to be able to do it right. Not have to call me every five minutes because something is not written down anywhere.”
He paused.
“Forty years is a long time to carry something. At some point it should live somewhere else.”
Bob was never the bottleneck. Bob was the system. The spreadsheets existed because nothing had ever been built to hold what he knew. So he carried it. Every day. For forty years.
What the visit changed about the design
I spent the first morning tracing Bob’s process rather than showing him anything. We took one real load and followed it from customer order to terminal selection, compartment assignment, driver instruction, delivery sequence, and printed packet. Every time Bob left the main spreadsheet to check another file, make a phone call, or write something by hand, we marked it.
That exercise changed the design completely.
We stopped treating a dispatch as a simple order assigned to a driver. The operating unit had to include the truck, the compartments, the terminal, the product split, the sequence, the certifications, and the driver instructions, all connected to the same record.
Later I watched a driver review his packet before leaving. He did not read it top to bottom. He looked first for the terminal, then the compartment split, then the stop sequence. That changed how we structured the mobile load screen.
Not every decision belonged in an automated rule. Bob knew one customer disliked late afternoon deliveries. Another site was difficult for a newer driver to navigate. Some knowledge could be structured. Some needed to stay visible as context the dispatcher could see and act on.
The system now flags an expired TCEQ certification before Bob assigns the load instead of relying on him to check a second spreadsheet every morning. It shows Bob’s station groupings, preferred terminals, and compartment logic so a new dispatcher can see the decisions without calling Bob for every one of them. Driver instructions attach directly to the load so the questions that used to require a phone call get answered before the driver asks them.
The goal was never to replace what Bob knows. It was to make sure that knowledge does not disappear the day he finally takes a vacation.
The thing I keep coming back to
Every common carrier has a Bob.
Sometimes he is the dispatcher. Sometimes she is the billing manager. Sometimes it is the owner who has not taken a real week off in fifteen years.
Somewhere in every operation is one person carrying decades of unwritten knowledge the business quietly depends on.
Great software does not replace that person.
It makes sure the operation can still run on the day they finally do.