Build & Systems · Consulting
Custom Dispatch & Fleet Systems: Software Built by Someone Who Has Run the Board
Dispatch tooling designed from the dispatcher's seat, not from a requirements document written by someone who has never taken a 6am breakdown call.
The problem
What this usually looks like
The board lives in a spreadsheet, a whiteboard and one dispatcher's memory. Drivers are assigned by whoever shouts loudest, ETAs are guesses relayed by phone, and proof of delivery is a photo in somebody's texts. The off-the-shelf transportation platform you looked at costs more than the trucks and still does not match how you actually run. So the office rekeys the same load into telematics, the accounting system and a customer portal, and every one of those hand-offs is a place where the number goes wrong.
How I approach it
I have run national logistics and fleet dispatch, so the design starts from the work: what the dispatcher needs on one screen at 6am, what the driver can realistically do on a phone in a yard, and what accounting needs at month end. I map the current process before writing anything, build the smallest system that removes the worst manual step, and put it in front of dispatchers early rather than at the end. Integration comes next, so telematics, the accounting system and the customer view read from the same record instead of three retyped copies.
Scope
What I actually do
Map the current dispatch process end to end, assignment, tendering, tracking, exceptions, delivery and billing, and identify where the data is being retyped.
Build the load and route board: live status, driver and equipment availability, assignment rules, and the constraints that actually govern your operation.
Build driver assignment logic that reflects your rules, hours, qualifications, home time, equipment fit and assignment fairness, rather than a generic optimiser nobody trusts.
Implement ETA calculation and exception alerting so a late or stopped load raises a flag before the customer calls.
Build mobile proof-of-delivery capture: signatures, photos, timestamps, geolocation, damage notes and paperwork, uploaded from the driver's phone.
Build fuel, deadhead, empty-mile and revenue-per-mile reporting so the cost of a lane is visible instead of estimated.
Integrate telematics and ELD providers, accounting and invoicing systems, and customer-facing tracking so one record flows through all of them.
Deploy, train dispatchers and drivers, and document the system so it survives staff turnover.
Deliverables
What you get
- Process map of current dispatch operations with the manual hand-offs marked
- Working dispatch and load board application deployed in your environment
- Driver mobile proof-of-delivery capture
- ETA and exception alerting with defined escalation rules
- Fuel, deadhead and lane profitability reporting
- Telematics and accounting integrations with documented data flow
- Dispatcher and driver training plus written system documentation
Outcomes
What changes
- The board is visible to the whole office instead of living in one person's head
- Delivery exceptions surface before the customer reports them
- Load data is entered once rather than rekeyed between systems
- Proof of delivery is attached to the load instead of sitting in a phone
- Lane and equipment costs become measurable, so pricing decisions have numbers behind them
Engagement
How we work together
Full custom dispatch system design and build
Phased build starting with the single worst manual process
Integration work connecting the systems you already run
Build plus ongoing support and iteration after go-live
Questions
Straight answers
How is this different from your dispatch operations consulting?
Dispatch operations consulting fixes how the department runs, the run sheets, the escalation ladder, the training and the coverage model. This service builds the software that department uses. Most companies need the process fixed first, because automating a broken process just makes it break faster.
Why not just buy an off-the-shelf TMS?
Buy one if it fits. Plenty of fleets are well served by a commercial platform, and I will tell you when that is the cheaper answer. Custom work makes sense when the platform costs more than the problem, when it forces a workflow that does not match how you dispatch, or when you need it to talk to systems the vendor does not support.
Will it work with the telematics and accounting software we already use?
That is usually the main point of the build. Integration depends on what your providers expose through their APIs, so I confirm that during the mapping stage before anything is committed, and I document exactly which fields move between which systems.
What does the build actually start with?
A process map and a conversation with the people doing the job. I want to see the real board, the real spreadsheets and the real 6am problem before anyone writes a specification. Then we build the smallest piece that removes the worst manual step, put it in front of dispatchers, and expand from there.
Related
Services that usually go with this
Logistics & Supply Chain Consulting
Twenty years on the board, not twenty slides about best practice.
Dispatch & Fleet Operations
Dispatch is a contact sport. I have run the board, not just audited it.
Operations Dashboards & Reporting
One page, every number defined once, that nobody in the meeting can argue with.
Hiring instead of contracting? See the full-time roles, or the ATS-formatted resume.
Contact
Tell me what you are hiring for
- Call: +1 519 278 5085
- Email: tim@timarmstrong.ca
- Based: London & Southwestern Ontario, Ontario, America/Toronto (Eastern Time)
- Availability: Available nationally across Canada, on-site, hybrid or remote
- Serving: London · Stratford · Woodstock · Kitchener: Waterloo · Cambridge · Guelph · Brantford · Sarnia · Chatham-Kent · Windsor · Toronto · Mississauga and Canada-wide