Transportation Management Systems
(TMS)

Overview

A transportation management system — a TMS — is the system that plans, assigns, and tracks transportation work. It decides how deliveries are grouped into loads, which vehicle and driver take each route, what time the deliveries are expected, and how each delivery is confirmed. It records what happened — where each vehicle went, what it carried, when it delivered, what it cost — so the operation runs on a record instead of on memory.

The way transportation work is commonly run makes the case for a system. A day of deliveries is planned by a dispatcher who knows the fleet, the routes, and the customers — from experience. Loads are built on the dispatcher's judgement of what fits together. Vehicles are assigned by who is available. The driver is told the route, and what happens after that is known to the driver and to whoever asks. The operation is only as good as the dispatcher's memory, and the details of what actually happened are only as good as what was written down — if it was.

A TMS changes the basis of the operation from memory to record. Loads are planned with the data: the orders, the locations, the vehicle capacities, the delivery windows. Routes are built to minimise distance and time. Vehicles and drivers are assigned in the system, and the drivers receive their assignments on a device. Every stop is confirmed as it happens, and the delivery is recorded with a proof. The operation's performance — on-time, cost per delivery, empty miles, utilisation — is visible from the record, not reconstructed from memory at month-end.

It is worth being clear about what a TMS does not do. It does not replace the drivers; it directs and records their work. It does not replace the dispatcher's judgement entirely; it gives the judgement the data it needs. And it is not a magic answer to an operation that is fundamentally disorganised; it is a tool that works when the operation is built around it.

The value of a TMS is measured in the things every transportation operation cares about: on-time delivery, the cost per delivery, the utilisation of the fleet, and knowing where every vehicle and delivery is. This page explains how it delivers those.

What We Build

A transportation management system takes the shape of the operation it serves. These are the parts we build, and what each one does.

Order-to-load planning. The system that turns a day's deliveries into loads. The orders — the customer, the location, the delivery window, the weight and volume — are grouped into loads that fit the vehicles, the routes, and the time available. The load plan is built on the data, so the day is planned before the trucks leave, not improvised on the road.

Dispatch. The system that assigns the work. Loads are assigned to vehicles and drivers, with the route, the schedule, and the delivery order. The driver receives the assignment on a device, and the dispatch is recorded in the system. The dispatcher sees the whole fleet from one screen and reassigns as the day's reality demands.

Route planning and optimisation. The system that builds efficient routes. The stops for each load are ordered to minimise distance and time, respecting delivery windows and vehicle constraints. The routes are the plan the driver follows and the record the operation keeps.

Fleet and driver management. The system that holds the fleet's records: the vehicles, their capacities, their maintenance, their documents; the drivers, their licences, their hours, their assignments. The fleet is managed from the record instead of from the memory of who knows what.

Live tracking and ETAs. The system that shows where the vehicles are and when they will arrive. Vehicles report their position, and the operation sees the fleet live: which deliveries are done, which are in progress, which are running late. The ETA the customer is given comes from the vehicle's actual position, not from the dispatcher's estimate.

Proof of delivery. The system that records what happened at each stop. The driver confirms the delivery — the signature, the photo, the note — on the device, and the proof is stored with the delivery. When a customer claims a delivery did not arrive, the answer is the record, not a debate.

Driver app. The device experience the drivers work from: their assignments, their route, their stops, their confirmations, their hours. The driver works from the app, and the operation works from the record the app produces. The driver's day and the operation's record are the same thing.

Cost and fuel tracking. The system that captures what the operation costs: fuel, maintenance, the cost per vehicle and per delivery. The costs are recorded as they happen, so the cost per delivery is known from the record, not reconstructed at month-end. The operation finally sees where the money goes.

Carrier and subcontractor management. For operations that use outside carriers, the system that manages them: the assignments, the rates, the performance, the settlements. The subcontractors work from the same record, and the operation sees their performance as clearly as its own fleet.

Reporting and analytics. The view of the operation's performance: on-time rates, cost per delivery, empty miles, vehicle utilisation, driver performance. The reports are built from the record the operation runs on, so they are true. The manager sees the health of the operation instead of assembling a picture from memory.

The shape of the TMS follows the shape of the operation. A local distribution fleet, a long-haul trucking company, and a business running its own in-house delivery all have different needs. What they share is the same core: planned loads, assigned work, tracked movement, and a record of what happened.

When This Service Makes Sense

A transportation management system is a real investment, and the case for it is specific. Here is when it makes sense, and when it does not.

It makes sense when the operation runs on the dispatcher's memory. The day is planned in the dispatcher's head, the routes are known by the drivers, and what happened is known by whoever asked. The operation is one person's memory away from failure — when they are away, it slows, and when they leave, it loses its planning. A TMS puts the planning and the record in the system.

It makes sense when on-time delivery is a problem. Deliveries run late, customers complain, and the operation cannot say why — because the reasons are not recorded. The late deliveries are not usually the driver's fault; they are the plan's fault. A TMS plans realistically, tracks the actual delivery, and shows where the plan breaks.

It makes sense when the cost per delivery is unknown. The operation does not know what a delivery costs, because the costs are scattered across fuel cards, maintenance invoices, and payroll. The margin on a contract is guessed. A TMS records the costs against the vehicles and the deliveries, and the cost per delivery becomes a known number.

It makes sense when the fleet is not being utilised. Vehicles run half-empty, or sit idle while a customer waits, and nobody sees it because the picture is assembled at month-end. A TMS shows the utilisation live — which vehicles are earning, which are not — and the planning uses the data to fill the fleet.

It makes sense when the operation wants to grow. Growth adds vehicles, drivers, and deliveries, and the memory-based operation cannot scale: more vehicles mean more improvisation, more things forgotten, more hours on the phone. A TMS carries the volume and the record that growth demands.

It makes sense when customers are asking for visibility. Customers want to know where their delivery is and when it will arrive, and the operation cannot answer without calling the driver. A TMS with live tracking answers the customer from the system, and the questions stop interrupting the operation.

It probably does not make sense when the operation is very small and simple. A single vehicle and a handful of daily stops may be better served by a simpler tool than a full TMS. The honest answer for a very small operation can be a well-run spreadsheet and a good driver.

It probably does not make sense without the discipline to run on it. A TMS works when the operation works through it — loads planned in the system, drivers working from the app, deliveries confirmed in the system. If the team is unwilling to change how it works, the system will be a more expensive version of the phone and whiteboard it replaced.

It probably does not make sense when the process is the problem. If the operation has no consistent process — no defined way of planning, assigning, or confirming — a system will record the absence of a process. The process should be defined first, and the system built around it.

The honest test is whether the operation's memory is costing it money. If deliveries run late, costs are unknown, the fleet is under-used, or the dispatcher is the whole plan, a TMS addresses the exact cost. If the operation is small, on time, and profitable, there is no urgent case.

Common Business Problems

The problems that lead businesses to a TMS are the everyday costs of running transportation on memory. These are the patterns we see.

The dispatcher carries the whole day in their head. Every morning, the plan for the fleet exists in one person's mind — the loads, the routes, the drivers, the timing. When that person is away, the operation half-works. When they leave, the operation loses its memory. A TMS puts the plan in the system, where it exists without any one person carrying it.

The late deliveries that no one can explain. The operation is running late, and nobody can say why — because the reasons are not recorded. Was it the route, the load, the vehicle, the traffic, the window? The question is answered with a shrug, and the same lateness happens the next day. A TMS records the actual deliveries and shows where the plan breaks — and the lateness stops being a mystery.

The route that is built on guesswork. The day's stops are ordered by whoever plans them, by feel — the order that seemed sensible, the route that was used last time. The fleet drives more miles than it needs, and the drivers know it. A TMS builds the routes on the data — the stops, the windows, the distances — and the extra miles are planned away.

The empty miles nobody sees. A vehicle returns empty, or runs half-full, and the cost of it is invisible because the operation never measures utilisation. The picture at month-end is assembled from memory and shows nothing. A TMS shows the utilisation live, and the empty miles become a visible, addressable cost.

The proof that does not exist. A customer claims a delivery did not arrive, or arrived damaged, and the operation has no record of what happened. The dispute is settled by the customer's word and the driver's word, and the operation loses either way. A TMS captures the proof at the stop — the signature, the photo, the note — and the dispute is settled by the record.

The customer's question the operation cannot answer. Where is my delivery? The customer asks, and the operation calls the driver, and the answer takes an hour — by which time the customer has already called twice. A TMS with live tracking answers the question from the system, instantly and honestly.

The cost that is only known at month-end. Fuel, maintenance, overtime — the cost of the operation is assembled at month-end from scattered sources, and the number arrives too late to change anything. The cost per delivery, the cost per vehicle, the margin on the contract — these are guessed. A TMS records the costs against the work as it happens, and the numbers are known while they can still be acted on.

The vehicle that was not available. The delivery was promised, and when the day came the vehicle was in the workshop — because the maintenance was not scheduled, or the document had lapsed, or no one knew it was due. The failure was a record that was never kept. A TMS holds the fleet's records, and the maintenance and documents are scheduled instead of discovered.

The operation that grew and broke. The business added vehicles and deliveries, and the memory model stopped working: loads were missed, vehicles were double-assigned, deliveries were forgotten. The operation outgrew the way it was run. A TMS carries the volume and the discipline that growth demands.

The subcontractor who cannot be trusted. The operation uses outside carriers, and their performance is known only by reputation — on-time, reliable, or not, according to whoever has worked with them. The settlements are argued. A TMS manages the subcontractors on the record — the assignments, the performance, the rates — and the reputation is replaced by data.

Typical Features

The features below are what a TMS does in daily use. They are the practical core of the system, described by what they change in the operation.

Planned loads, built on the data. The day's orders are grouped into loads that fit the vehicles and the routes, before the trucks leave. The plan is visible, complete, and shared — the operation knows what is running today because the system holds it. The day is planned instead of improvised.

One screen for the whole fleet. The dispatcher sees every vehicle, every driver, every load, and every stop from one view — the assignment, the progress, the issues. The operation's state is visible at a glance instead of collected by phone. The dispatcher's job becomes managing the operation instead of reconstructing it.

Routes that respect the constraints. The stops are ordered to minimise distance and time, within the delivery windows and the vehicle limits. The route is the plan the driver follows and the record the operation keeps. The extra miles are planned away, and the deliveries are planned to be on time.

Assignments the drivers work from. The driver receives the day's work on a device — the stops, the order, the windows, the confirmations. The driver works from the assignment, and the operation works from what the driver confirms. The phone calls to drivers for direction and status are replaced by the system.

Live position and honest ETAs. The vehicles report their position, and the operation sees where everything is. The ETA is built from the vehicle's actual progress, not the dispatcher's guess. The customer's "when will it arrive?" is answered from the system, and the answer is honest.

Proof captured at the stop. The delivery is confirmed on the device — the signature, the photo, the note — and stored with the delivery. Every delivery has a proof, and the disputes that used to be settled on reputation are settled by the record.

Costs recorded against the work. Fuel, maintenance, and the other running costs are recorded against the vehicles and the deliveries. The cost per delivery and the cost per vehicle are numbers from the record, not reconstructions at month-end. The operation finally knows what its work costs.

Maintenance and documents scheduled. The fleet's records are held in the system — the vehicles, their maintenance schedules, their documents, the drivers' licences and hours. What is due is scheduled and visible, so the vehicle that was in the workshop on the day it was needed becomes a thing of the past.

Subcontractors on the same record. Where the operation uses outside carriers, they work from the same record — the assignment, the confirmation, the performance. The operation sees the subcontractors' performance on the data, and the settlements are based on the record. The reputation-based relationship is replaced by a data-based one.

Reports that tell the truth. On-time rates, cost per delivery, empty miles, utilisation, driver performance — the reports are built from the record the operation runs on. The manager sees the operation's real health instead of the assembled picture at month-end. What gets measured can finally be managed.

Access by role, with a record of who did what. The dispatcher plans, the manager sees the whole operation, the driver sees their own work, the customer sees their deliveries. Access is controlled, and actions are recorded against the person who took them. The shared system is trusted because it is accountable.

Reliability through the working day. The system is built to keep working through the day's volume — the dispatch, the tracking, the confirmations — without failing on the busiest days. A TMS that fails when the fleet is running is not a system; it is a bottleneck with a login.

These are the features that matter in the operation. The measure of a TMS is whether the day is planned before the trucks leave, whether the deliveries are confirmed in the record, and whether the costs and performance are known instead of reconstructed. Everything else is detail.

Our Approach

A transportation management system changes how an operation plans and records its work, and the way we build it respects the people who run it. The dispatchers and the drivers are part of the design, because the system only works when they work through it.

Understand the operation from the people who run it. We start by working with the operation — the dispatchers, the drivers, the managers — to learn how the day actually works: how loads are planned, how vehicles are assigned, how routes are built, how deliveries are confirmed. The system is designed around the real operation, not a textbook version of transport.

Make the record the foundation. The core of the system is the record — the loads, the assignments, the deliveries, the proofs, the costs. We design it deliberately, because the whole operation runs on it. The screens and the driver app come after. If the record is right, the operation runs on it; if it is wrong, no interface fixes it.

Design for the drivers first. The drivers are the ones who work in the system every hour of their day, and the driver app is designed for their reality: simple, fast, and reliable, with their stops, their route, and their confirmations. A driver app that is a burden is a driver app that is not used — and the record dies with it.

Support the dispatcher, not replace them. The dispatcher's judgement is the operation's asset, and the system gives it the data it needs: the loads planned on the data, the fleet visible on one screen, the issues surfaced as they happen. The dispatcher works through the system, and the operation is not hostage to one person's memory.

Integrate with the systems around it. The TMS connects to the order system and the ERP — the orders arrive for planning, the delivery confirmations and proofs return. Where carriers and telematics are involved, the system connects to them. The TMS is part of the operation's flow, not an island.

Migrate the fleet's records honestly. The vehicles, the drivers, the documents, the customers — the fleet's context is brought into the system, checked, and built on. The new system starts with the operation's reality, not empty. The data is yours and remains yours.

Train and launch with the operation. The dispatchers and the drivers are trained on the real workflows, and the launch is managed so the operation starts on the right foot. The first weeks of real use are when the system and the operation learn each other, and we stay close through them.

Keep it improving after launch. The TMS is maintained and improved after it is live — the routes refined, the reports expanded, the integrations extended as the operation changes. A TMS that stops being maintained stops being used, and the operation quietly goes back to the phone and the whiteboard.