The Oilfield Dispatch Problem: Why Spreadsheets Don't Scale

Every hauler running fewer than 10 trucks is dispatching with a spreadsheet. Some are using Excel. Some are using a shared Google Sheet so the dispatcher and the office manager can both see it. A few are running a Notion page or a wall-mounted whiteboard with magnetic truck labels.

It works. Until it doesn't.

The breakdown is predictable. It happens around the 8 to 10 truck mark. Before that, one dispatcher can hold the whole operation in their head: every truck, every driver, every location, every customer's preferred service window. Above that, no one can. The spreadsheet stops being a memory aid and becomes the source of truth, and the source of truth starts losing to reality.

This post walks through what actually breaks, why it breaks at that scale, and what to look for if you're past the breaking point.

Where spreadsheets work

In a 3-truck water hauling operation, the dispatcher knows which truck is at which pad, which driver is running it, and what the customer's expectations are. A spreadsheet captures the day's plan in the morning, gets updated when something changes, and produces an end-of-day record that goes to invoicing.

Three things make this work at small scale:

• Single-source updates. The dispatcher is the only person editing the sheet. There's no version conflict because there's no second editor.
• Mental indexing. The dispatcher remembers what the spreadsheet doesn't capture. Truck 102's hydraulics have been acting up. The operator at the Wolfcamp pad doesn't take afternoon deliveries. One of the drivers is at a doctor's appointment until 11.
• Slow-changing day. The morning plan mostly survives. Maybe one or two reroutes. The cost of recomputing everything when something changes is low because not much changes.

A spreadsheet is fine when these conditions hold. The breakdown isn't really about the spreadsheet. It's about what happens when these conditions stop holding.

Where spreadsheets break

Past 8 to 10 trucks, three things change at once.

Multiple dispatchers, multiple updates

Now there's a day-shift dispatcher and an after-hours person. Maybe a third dispatcher handling specific customer accounts. Multi-edit Google Sheets sort of work for this, but the conflicts that get silently resolved by "last write wins" are exactly the conflicts that produce missed loads. One dispatcher reassigns Truck 105 to a Sage Creek pad. The other dispatcher hasn't refreshed the sheet and confirms with the operator that Truck 105 is still going to Diamondback. Both think they're right. The driver shows up at Diamondback with a load Sage Creek is waiting for.

Mental indexing fails

No human holds 12 trucks, 18 drivers, 30 customers, and the day's contingencies in working memory. The dispatcher who could keep it in their head at 6 trucks is now the dispatcher who forgets that Truck 108's annual DOT inspection is due tomorrow and dispatches it anyway. The cost of the forgotten thing is no longer "we had to swap a truck mid-route." It's "DOT pulled the truck over and found an expired sticker."

Day churns

The morning plan survives the morning. By 10 a.m., three operators have called with new pickup windows. By noon, one driver has called out sick. By 2 p.m., a customer has called demanding a same-day delivery they didn't order. The spreadsheet is no longer the day's plan. It's a list of what was supposed to happen, with the dispatcher's verbal corrections layering over the top, and at least one of those corrections didn't make it back into the sheet.

The spreadsheet was never wrong. It was just not the system the operation actually needed.

What you find when the breakdown starts

The signals are operational, not technical. They look like this.

A driver shows up at the wrong location because the dispatcher updated the sheet but didn't call. A ticket gets created without GPS verification because the driver was rushed and forgot to confirm location, and the customer disputes the load three weeks later when the invoice comes through. The office manager finds out a customer was on credit hold when she runs the aging report at month-end, after the truck has already delivered three more loads to them. A driver's H2S certification expired two weeks ago and nobody caught it because the cert tracker is a separate spreadsheet on a different person's computer.

None of these are spreadsheet bugs. They're all consequences of the dispatcher's mental model not matching reality, and the system not catching the mismatch.

What dispatch software actually does differently

The word "software" makes this sound like a tooling upgrade. It isn't. It's a change in where the source of truth lives.

A purpose-built dispatch system stops being a list the dispatcher maintains and starts being a system that reflects current state. Three things change.

• State updates propagate. When a driver completes a load, the system knows. The vehicle is no longer at the well pad. The ticket exists with a timestamp and GPS coordinates. The customer's account has a new charge against it. The next dispatcher who looks at the board sees the current state, not the morning's plan.
• Constraints get enforced. When a dispatcher tries to assign a driver whose certification has expired, the system blocks the assignment. When a customer is on credit hold, the system blocks new tickets. When a vehicle has a failed inspection, the system shows it as unavailable. The dispatcher doesn't have to remember; the system remembers.
• The day's complexity becomes visible. Instead of one dispatcher's mental model of 12 trucks and 18 drivers, the operation has a shared visual representation. The Kanban board, the map view, the status filters. Multiple people can see the same state at the same time. Updates from one person are visible to everyone immediately.

This isn't about replacing the dispatcher. The dispatcher is still making the calls: who goes where, what gets prioritized, how the day's contingencies get absorbed. The system stops the dispatcher from making those calls based on a stale mental model.

What to look for in a replacement

Not all dispatch software is the same. Some of it is generic logistics software bent toward oilfield. Some of it is built for long-haul trucking and has nothing to say about field tickets. Some of it is built for ride-sharing and has nothing to say about anything.

The questions that matter for an oilfield hauling operation:

• Does it know what a field ticket is? A real field ticket has GPS coordinates at pickup and delivery, a service type that maps to your pricing structure, a customer reference, sometimes a permit number, sometimes a load source. Generic dispatch software treats every job as an interchangeable unit of work. Oilfield haulers need their tickets to capture what was actually hauled, from where, to where, and at what rate.
• Does it integrate with safety and compliance? A driver with an expired H2S certification shouldn't be dispatchable. A truck with a failed pre-trip inspection shouldn't be available. If the dispatch system doesn't talk to the compliance system, the dispatcher is back to mental-modeling the constraints, which is where the breakdown started.
• Does it produce invoices? Field tickets exist to bill against. Dispatch software that doesn't produce invoices means double data entry: once in dispatch, once in QuickBooks or whatever AR system your bookkeeper uses. Double entry is where errors live.
• Does it work offline? A driver on a frac pad in West Texas doesn't always have signal. The mobile app needs to work when the network doesn't and sync when the network comes back. Otherwise drivers stop using it, write loads down on paper, and now you have the same data-entry problem the spreadsheet had.
• Does it scale past your current size? The whole point of moving off a spreadsheet is the spreadsheet stopped scaling. The replacement system should still work at 30 trucks, 50 trucks, 100 trucks. Some software is sold to small operators on the assumption they won't grow. The right system is built for growth.

What "the right system" looks like

The Iron Suite (IronHaul for transport, IronGuard for safety, IronLedger for accounts payable) is built for exactly this transition. Mid-market hauling companies running 10 to 80 trucks, who have outgrown spreadsheets but don't want to spend six figures on enterprise software designed for fleets ten times their size.

What that means in practice: GPS-verified field tickets that flow into automated invoicing. A real-time Kanban dispatch board that shows current state instead of morning intent. Driver and vehicle compliance enforcement that blocks bad assignments before they happen. Cross-product visibility, where failed inspections in IronGuard surface as unavailable trucks in IronHaul, and expired certs in IronGuard surface as warnings on dispatch in IronHaul.

If you're running 8 trucks today and a spreadsheet, you might still be fine. If you're running 12 and the day's plan keeps falling apart, the spreadsheet is no longer the system you need.

Back to all articles