Fleet Dispatch Management Software for the Day That Changes
Allocation is the easy part. Reallocation, eleven times before lunch, is the job. KO Fleetz puts every load, driver and vehicle on one board that updates as the day moves, and keeps the reason behind every change instead of losing it in a phone call.
The allocation was right at seven. By nine it is fiction.
The board gets built the evening before. Loads against registrations, drivers against loads, printed at six the next morning. Then a driver rings in sick, a customer pushes a window to the afternoon, and a tractor unit fails its walkaround on a cracked mirror. Three changes, and the printout is now a historical document.
What replaces it is a person. The dispatcher holds the real allocation in his head, in two WhatsApp groups and in pencil on the margin of the sheet. He is very good at it. He is also the only one who knows, which means the depot runs measurably worse the week he takes leave, and nobody can explain why the tipper went to the quarry job instead of the closer one.
The cost lands later. Somebody asks why that contract lost money and the answer requires reconstructing decisions nobody wrote down. There is no record that the job was offered to two drivers first, or that the vehicle was swapped at 10:40 because of a tail-lift fault. The trip has a cost, and it has no story.
One board that everyone is reading from
Every job exists as an object with a state: unassigned, offered, accepted, running, completed. Assigning it to a driver and a vehicle is a checked action, not a note. Licence class, vehicle capability, capacity remaining and the driver's remaining shift are tested at the moment of assignment, so the mismatch surfaces at the board rather than at the customer's gate.
KO Fleetz treats change as the normal condition. A reassignment updates the driver's device, moves the job on the board, and recalculates the customer ETA from where the replacement vehicle actually is. The previous assignment is not deleted; it stays as a versioned entry with a timestamp and the person who made it.
The module deliberately does not decide the drop sequence inside a job, and it does not silently auto-assign. Ordering stops against time windows is route planning, and searching for the cheapest arrangement of them is route optimization. Dispatch proposes candidates with the reason each one fits, then waits. A board that reassigns loads on its own is a board dispatchers stop trusting by Thursday.
Capabilities
What KO Fleetz dispatch management gives your team
Live allocation board
Loads, drivers and vehicles on one grid, with each job's state visible as it moves from offered to accepted to running.
Eligibility checks at assignment
Licence class, site certification, vehicle capability and remaining shift are tested before the job can be committed to a driver.
Driver acceptance on the device
The driver sees the job, its stops and its paperwork, and accepts it. An offer nobody accepted stays visible as an unstarted job rather than an assumption.
Reassignment history
KO Fleetz keeps the old assignment, the new one, the time and the person on every swap. The question of why that vehicle ran that job has a written answer.
Live customer ETA
Arrival estimates are recalculated from the vehicle's current position and the remaining stops, so a swapped truck does not keep quoting the old plan's time.
Exception queue
Jobs that were never accepted, started late, or stalled between stops are pulled to the top, so the dispatcher works a short list instead of the whole board.
Depot and region scoping
Each depot sees and dispatches its own work, while regional managers see across them. Nobody reassigns a truck from a yard they have never visited.
Workload spread across drivers
Shows hours and jobs already committed per driver for the day, which is what stops the reliable driver quietly absorbing every awkward run.
How it works
How KO Fleetz does it
Step 1: Jobs arrive on the board
Orders come in from your TMS, an uploaded file, or straight into the board by hand. Each carries its stops, weights, windows and any site requirement.
Step 2: Assign against the constraints
The dispatcher picks a driver and vehicle. The platform confirms the pairing is legal and physically possible, or explains which rule it broke.
Step 3: The driver accepts and goes live
Acceptance on the device flips the job to running. From that point the board tracks progress against the plan rather than against a phone call.
Step 4: Work the exceptions
Late starts, refused offers and stalled jobs surface as a queue. Reassign from the same screen, and the driver, customer ETA and record all move together.
Outcomes
What changes
- Everyone sees the same allocation at the same moment
- One board
- Every reassignment keeps who changed it and why
- Written down
- Arrival times taken from the vehicle's real position
- Live ETA
- Dispatch stops living inside one person's memory
- Shareable
Frequently asked questions
Dispatch answers who runs this work and on what. Planning answers what order the stops go in and whether the timings hold. They are separate because they change at different rates: a route may be the same every Tuesday for a year, while the driver and tractor assigned to it change three times in a morning. Keeping them apart means a sick driver does not force you to rebuild a sequence that was never the problem.
Only if you ask it to, and it will always name the alternatives. The default is proposal: KO Fleetz ranks the drivers and vehicles that legally and physically fit, shows why each one qualifies, and leaves the commit to the dispatcher. Automatic allocation works well for repetitive, tightly constrained work such as fixed shuttle runs. It works badly where the deciding factor is that a particular driver knows the site. Dispatchers hold a lot of that knowledge, and a board that overrules it gets abandoned.
The driver app holds the assigned job on the device and syncs when connectivity returns, so a run through a dead zone does not lose the work. Where a driver has no device at all, the dispatcher can accept and progress the job on their behalf; those actions are recorded as dispatcher-entered rather than driver-confirmed, so nobody later mistakes a phoned-in status for a captured one. It is a workable fallback, not an equivalent one.
That is the usual arrangement. Jobs arrive over an API or a scheduled file drop, keeping your order system as the commercial source of truth, and KO Fleetz handles execution: allocation, progress and completion, pushed back on the same channel. Fleets without an order system dispatch directly from the board. The one setup worth avoiding is dual entry, where orders are typed into both. The two diverge within a week and nobody knows which to believe.
He probably is faster, and the board should not slow him down. What it adds is everything that happens after the decision: the driver seeing the change without a call, the customer ETA moving on its own, and the record that explains the day to whoever reviews the contract next month. It also removes the single point of failure. The test is not whether the software dispatches better than your best dispatcher. It is whether the depot still works on his day off.
Yes, and most fleets do for urgent work. The board does not block a phone call; it asks that the outcome lands on the board afterwards, which takes seconds from the dispatcher's screen. The failure mode to watch is the job that was agreed verbally and never entered, because it is invisible to the ETA, the customer and the cost record. Fleets that get value from dispatch software are the ones where the board is the last word, not the only channel.
Put one depot's morning on a live board
Bring a typical day's loads and the vehicles you had available, and KO Fleetz will replay how the reallocations would have looked.