Dispatch
Loads, assignment, status and the daily board. The operational heart of a carrier, and the origin of most facts that everything downstream depends on.
Transportation · Custom TMS
A carrier running on Google Sheets
An asset-based carrier was dispatching trucks, invoicing customers, running a shop and paying drivers out of shared spreadsheets. We replaced all of it — but only after the backbone was right.
- Sector
- Asset-based transportation
- Replaced
- Google Sheets and disconnected tools
- Departments
- Dispatch · Accounting · Shop · HR · Compliance · Payroll
- Integrations
- SaferWatch · Samsara · Fuel cards · QuickBooks · Factoring
The situation
The company had outgrown the spreadsheet that built it.
- Hours spent reconciling tabs
- Invoices going out late
- Three people asked to find one fact
A growing carrier was moving real freight with real trucks and real drivers, and the system of record was a set of shared Google Sheets.
That is not a criticism. Spreadsheets are genuinely good at getting a company started — they cost nothing, they change in seconds, and this one had carried the business a long way. Plenty of good operations begin exactly here.
What a spreadsheet cannot be is the operational core of a company where dispatch, accounting, the shop, HR, compliance and payroll all need the same facts at the same time. One load ends up living in several tabs, and the tabs stop agreeing the moment anything changes.
Where it starts to cost
Nothing collapses. It just takes three people and half a morning to answer a question about one load.
Starting point
Everything ran on Google Sheets.
One load existed in several tabs, and the tabs stopped agreeing the moment anything changed. The cost of that is not dramatic — nothing collapses. It shows up as hours spent reconciling, as invoices that go out late because someone is still checking, and as an owner who has to ask three people to find out what is true.
- The same load lived in several tabs, and none of them stayed in agreement
- Dispatch changes were invisible to accounting until invoicing time
- Driver pay was reconstructed at period end from notes and memory
- Maintenance history sat apart from the truck it belonged to
- Compliance dates were tracked by whoever happened to remember them
- Nothing could be locked, audited, or trusted as a single version
How it started
We started by watching, not by writing a specification.
Before any software existed we mapped how the company actually ran — which is different from how anyone describes it running. That meant a lot of interviews, across every department, and sitting with the real spreadsheets rather than a summary of them. Prototypes went in front of people early, because an operator will tell you in ten seconds what a requirements document takes three weeks to get wrong.
- 01
Workflow analysis
We traced a single load end to end — quote, dispatch, delivery, invoice, settlement, driver pay — and marked every point where information was re-typed, guessed at, or held in one person's head.
- 02
Interviews across departments
Dispatchers, accounting, the shop, HR and compliance. The people entering the data and the people depending on it rarely describe the same process, and the gap between those two accounts is usually where the problem lives.
- 03
Prototyping
Working shapes in front of real users, early and repeatedly. Cheap to change while it is still a prototype; expensive to change once a department depends on it.
- 04
Agreement before building
We settled the domain model — what a load is, what a truck is, what a pay period is — with the people who would live in it, before a line of production code.
Architecture
Build the backbone first. Then move the departments in.
The common failure in a project this size is starting with whichever department is complaining loudest, then discovering six months later that the foundation cannot carry the next one. We built the core first — load, truck, driver, money — and got that architecture right while the system was still small enough to change cheaply. Once the spine existed, each department could be moved onto it as an addition rather than as surgery.
- One record per real-world thing: a load, a truck, a driver, a pay period
- Every downstream number derived from that record, never re-entered beside it
- Departments added in sequence, each one shipping before the next started
- The model settled early, so later departments cost less than earlier ones
What moved in
Six departments, one system
With the architecture in place, the operation moved across a department at a time. Each one kept working through the transition, because none of them was asked to move before the thing underneath it was ready.
Accounting
Customer invoicing and receivables derived from the load record rather than re-keyed from it, so the ledger and the operation cannot drift apart.
Shop
Maintenance, work orders and parts tied to the specific truck and its service history — so a vehicle's condition is part of its record, not a separate folder.
HR
Drivers and staff as first-class records, with documents, qualifications and history attached where they belong instead of in a shared drive.
Compliance
Expiry dates, safety data and the paperwork that keeps trucks legal, surfaced before they lapse rather than after someone notices.
Payroll
Driver pay computed from work the system already recorded — miles, loads, deductions — instead of reconstructed by hand at the end of each period.
Connected systems
Connected to the systems the business already paid for
A carrier already runs on a stack of specialist services. None of them needed replacing; they needed to stop being islands.
- SaferWatch
- Carrier and driver safety and compliance data pulled in automatically, instead of being looked up and pasted by a person.
- Samsara
- Telematics and ELD — vehicle position, hours of service and utilisation — read against the load so dispatch and compliance see the same reality.
- Fuel cards
- Fuel transactions matched to the truck and the trip, so cost per load reflects what was actually spent moving it.
- QuickBooks
- Accounting synchronisation, so the operational system and the books agree without a monthly reconciliation ritual.
- Factoring company
- Invoice submission and funding status held against the same load record, so cash position is visible where the work is.
Operational complexity
A carrier is six businesses sharing a yard. Dispatch thinks in loads, the shop thinks in trucks, payroll thinks in pay periods, compliance thinks in expiry dates — and all four are describing the same handful of physical objects. Any system that models only one of those views forces the other three back into spreadsheets, which is how the company got there in the first place.
Systems approach
One custom platform built on a shared core, extended department by department, and wired into the specialist services the business already relied on. The sequence mattered as much as the software: architecture first, then dispatch, then everything that depends on dispatch being right.
Scope
What it involved
- Custom transportation management system
- Dispatch, accounting and invoicing
- Shop, maintenance and work orders
- HR, compliance and document management
- Driver payroll from recorded work
- SaferWatch, Samsara and fuel card integrations
- QuickBooks and factoring company synchronisation
- Migration off Google Sheets, department by department
Working principle
Get the backbone right while the system is still small. Everything after that is addition, not surgery.
Questions we get asked
Before you start a project like this
The questions below come up in almost every first conversation. If yours is not here, it is a good thing to open with.
- Why replace spreadsheets at all if they are working?
- Because the cost is hidden rather than absent. Spreadsheets do not fail loudly — they fail as reconciliation time, late invoicing, pay disputes and an owner who has to ask several people to find out what is true. The trigger is usually not a disaster; it is the point where growth starts costing more administration than it earns.
- Did every department move onto the system at once?
- Deliberately not. The core was built and proven first, then departments moved in sequence, each one live before the next began. That keeps the business running throughout, and it means the model is tested by real use before the next department depends on it.
- Do we have to replace our accounting system too?
- No. QuickBooks stayed. The point of the integration work is that specialist tools which already do their job well should keep doing it — what changes is that they stop being islands and start sharing one operational record.
- What happens to the data already in our spreadsheets?
- It gets modelled properly and migrated. Part of the discovery work is deciding what is genuinely a record, what is a working note, and what should not survive the move at all. Not everything in a spreadsheet deserves to be carried forward.
- How is driver payroll handled?
- Payroll is computed from work the system has already recorded rather than re-entered at period end. Because dispatch, loads and deductions live in the same system, pay becomes a derivation instead of a monthly reconstruction.
Next case study
A brokerage on a platform it could not changeStart with the operation
Talk about your operation.
Every engagement starts the same way, whatever the industry: understanding how the work actually happens.
Start a conversation →