In most transport companies, dispatch still rests on the experience of one or two people, a spreadsheet and a phone. It holds up until the first real peak, a breakdown, or the day the dispatcher who “kept everything in their head” leaves. For an operations director the cost is measurable: every empty run, missed slot and idle driver drains the margin, and manual planning simply never catches it.
In our experience, this area rarely calls for a product revolution. Far more often it needs good software and engineers who understand logistics. We do not run a dispatch desk of our own, but we have built operational-grade systems on industrial and backend projects, so we know how to design a dispatch system and a route optimisation layer, and how to staff a project that actually reaches production.
Why does manual dispatch hurt so much?
Manual assignment does not scale in a straight line. At ten jobs a day a dispatcher handles everything by instinct; at a hundred, instinct runs out, and the number of vehicle-job-time-window combinations grows exponentially. What the company pays for is not the mistakes but the lack of visibility: nobody can tell whether the plan on the board is 5% or 25% worse than optimal.
There is also the fragility that comes with it. When the assignment rules live only in one person’s habits, the company loses them the day that person walks out. Software writes those rules down, versions them and shares them across the team, which turns decisions into something repeatable and auditable.
What is a dispatch board and how does it speed up assignment?
The heart of any dispatch system is the board, a single operational view where the dispatcher takes in a full day of fleet activity. We design it to bring jobs, vehicles, drivers and their working hours together in one place. It usually carries:
- a job pool filtered by status, region and priority,
- a timeline of vehicles and drivers showing availability and hours,
- drag-and-drop assignment with instant conflict validation,
- real-time statuses: planned, en route, delivered, delayed.
An interface like this does not replace the dispatcher; it takes the mechanical work off their plate. The system makes sure two jobs never land on the same slot and a route never exceeds payload, while the person decides where context actually matters.
How does route planning and optimisation work?
Beneath the board sits an engine that frames route planning as an optimisation problem. In the literature this is the VRP family (Vehicle Routing Problem), with variants that account for payload, time windows and multiple drivers. In practice we do not chase a perfect answer, which is computationally infeasible at real scale, but one that is good enough within an acceptable time.
The engine has to respect hard constraints it may never break, and soft ones it tries to minimise:
- payload and capacity per vehicle (weight, pallet spaces, volume),
- time windows for deliveries and pickups on the customer side,
- driver working time and mandatory breaks (regulatory compliance),
- job-to-vehicle compatibility (reefer, ADR, tail lift, dimensions).
As the objective function we typically take minimising total cost: distance, time and empty runs. We reach for optimisation solvers (engines such as OR-Tools) and heuristic algorithms, matching the approach to the size of the fleet rather than the other way around.
How does the system handle time windows and slots?
Time windows are where theory meets daily reality. The customer wants delivery between 8 and 10, the warehouse only has a free dock at set hours, and the driver has to make it before the end of their shift. A well-designed system treats a slot as a resource that can be booked, released and replanned the moment reality drifts from the plan.
Here we build a mechanism that continuously checks whether the schedule is still feasible and flags at-risk deliveries before they turn into late ones. When traffic hits or an express job arrives, the engine recalculates the route incrementally instead of rebuilding everything from scratch, which lets the dispatcher respond in minutes rather than hours.
How do you automate subcontractor assignment?
Larger firms rarely move everything on their own fleet, so the system also has to understand subcontractors and external carriers. At that point the assignment logic stops being only about routes and starts weighing the purchase cost of the service, availability and partner reliability.
In modules like these we usually design a job exchange or a tendering mechanism, where the system offers a job to a defined group of carriers, collects responses and suggests a choice based on the client’s rules. We also automate the settlements and paperwork (transport order, proof of delivery), so working with a subcontractor does not spawn a second workflow in email and Excel.
How do you integrate a dispatch system with telematics and a TMS?
A dispatch system does not live in a vacuum. Its value only grows once it connects to the rest of the company’s IT landscape. Most often we wire it into:
- telematics and vehicle GPS (position, fuel consumption, driving style),
- TMS and ERP systems (orders, counterparties, invoicing),
- a driver mobile app (jobs, navigation, status, e-POD),
- external map and traffic APIs for realistic travel times.
We design these integrations through an API and event layer, so a position from telematics updates the status on the board, and a proof of delivery from the driver’s phone closes the job in the TMS. Data then flows in one direction instead of being retyped between systems.
Where does AI genuinely help in route optimisation?
AI is often oversold, so we treat it as an addition to a solid rule-based engine rather than a replacement for it. It earns its place where prediction and learning from history matter: forecasting real travel time from past trips, estimating unloading time at a given point, or predicting job volume for the coming days so the fleet can be planned ahead.
Our competence in models and data is real within the RITS Group, so we can design and plug in such a layer once the client’s data is ready for it. More often, though, we advise sorting out dispatch and data first and adding prediction only afterwards, because a model fed with chaos will not improve decisions.
Which skills do we provide for a project like this?
We will not claim a finished dispatch rollout here; what we provide are the people who build such systems. We shape the team around the brief, and a typical one includes:
- an architect / backend developer (Java, .NET or Node) for the engine and APIs,
- an optimisation specialist fluent in VRP and solvers (OR-Tools, operational models),
- a frontend developer for the dispatch board and operational views,
- an integration / DevOps engineer for telematics, TMS and deployments.
This setup lets us step into either a greenfield build or the development of an existing tool, when the client is missing a specific competence on their own team.
How do we do it at RITS?
We work as a nearshore partner from Poland, in a close time zone, which matters for an operational project because logistics changes have to be discussed the same day. We verify skills before the start and plug the team into the client’s working rhythm, code reviews and meetings without a long ramp-up. Our recruitment usually closes in around three weeks, stretching only for non-standard requirements.
We most commonly deliver this in two ways: as custom software built by our team, or as team augmentation when the client has their own engineers and needs to add missing roles, such as a route-optimisation specialist.
Where do you start with route and dispatch optimisation?
Start from the single most expensive problem: empty runs, late deliveries, or dependence on one dispatcher. That tells you whether you first need a board and cleaner assignment, or an optimisation engine straight away. In parallel, check your data quality, because without reliable positions, times and vehicle parameters no algorithm will compute a sensible route. We covered the differences between engagement models in our article on IT engagement models.
Planning a dispatch system or route optimisation? Let’s talk - we’ll match a team and an architecture to your fleet and processes.