In many fleets, dispatch still works like this: a dispatcher phones the driver, the address goes out by chat app, and a whiteboard shows who runs which trips today. That holds up while the fleet is small. What commonly happens as vehicles and branches are added is that jobs get missed or sent twice, drivers can't find the site, and afterwards nobody can say for sure which vehicle went where. Here are seven things to settle when moving dispatch into a system, drawn from the fleet platform we built for Yong Fan, whose features include dispatch, route planning, trajectory queries and in-vehicle video.
Half of what makes a dispatch system pleasant to use is its master data. If every job means retyping the address and explaining what to deliver, the system is just a different place to type.
The fleet operator web portal we built for Yong Fan has separate functions for managing sites, goods, vehicles and drivers. When rolling out, get this data in order before real dispatching starts.
The work order is the heart of dispatch. We recommend it answers at least:
If your workflow needs more — contact person, booked time slot, notes about the site — list it before you start and ask the vendor whether the work order can hold it. This varies a lot by industry: delivery logistics and construction vehicles need different fields.
In the Yong Fan project, route planning was first listed as a separate feature and later merged into the dispatch system: create the work order, plan the route, then send it straight to the driver.
In general, a route is planned for a specific work order. Keeping both in one flow makes it less likely that routes and jobs drift apart, and dispatchers don't have to cross-check between separate features.
Dispatch ends up in the driver's hands. Some systems have a complete back office while drivers still rely on phone calls. The driver app in Yong Fan's platform provides work orders, a list of sites and a planned-route map.
The other side to decide is whether drivers report back — arrived, completed, photos or signatures. That has to be designed around your workflow, and it shapes how much drivers have to tap. We suggest first listing what absolutely must be recorded, then deciding which buttons drivers press; ask for too much and drivers may stop using it properly.
With dispatch and GPS tracking in one system, it's easier to check afterwards what actually happened. When a customer says the goods never arrived and the driver says they did, you need to pull up that vehicle's trajectory for the day. The platform we built for Yong Fan lets you query trajectories by vehicle and export them as images and reports for reconciliation or complaints; how work orders and trajectories are compared is something to have a vendor demonstrate before you start.
When evaluating a system, ask the vendor to show it: take one of yesterday's work orders, pull up the trajectory of the vehicle that ran it, and see how easily the two can be compared.
As soon as there's more than one fleet operator or branch, decide this up front: each operator sees only its own vehicles, drivers and work orders, and people who manage several operators can view them together or separately. In Yong Fan's platform, a fleet manager can manage several fleet operators and add store managers and drivers; a store manager runs one operator and can only add drivers. The full five-role design is in designing permissions for a fleet platform.
We recommend piloting dispatch with one fleet operator or branch, then expanding once it works:
During the pilot, there's no need to stop phone dispatch right away. Running both for a short while makes the change easier for dispatchers and drivers.
"Dispatch" and "ride-hailing" are often mentioned together, but they serve different people and need different features:
| Fleet dispatch system | Ride-hailing system | |
|---|---|---|
| Who places the order | Dispatchers at the operator or company | Members of the public |
| How jobs are assigned | Dispatcher assigns vehicle and driver per work order | Usually matched automatically to a nearby free vehicle |
| Users | Managers, drivers | Passengers, drivers, the operator |
| Usually also needs | Sites, goods, routes, trajectory reports | Passenger app, fare calculation, online payment, ratings |
This article is about dispatch, and our track record is fleet-operator dispatch, not ride-hailing. The two share foundations such as GPS tracking, device integration and live maps, but the passenger side and payments are separate work. If you're planning a ride-hailing service, also confirm your operating model complies with the relevant regulations. When evaluating vendors, ask which of the two they have actually built.
Before talking to vendors, prepare: a list of your regular sites, a list of goods you often deliver, one real dispatch sheet or chat-app dispatch message, which vehicles and drivers belong to which operator, and "what do we most often need to look up afterwards". With these, a vendor can demonstrate using your actual situation instead of a feature list.
Choosing a fleet system also means comparing devices, video and regulatory reporting — see how to choose a fleet management system. Our dispatch, tracking and video features are on the Fleet GPS & Video Management page. Or tell us how you dispatch today and we'll give you initial recommendations.