Transportation Management System: What It Is, and Why Most Delivery Fleets Only Need Half of One

A transportation management system (TMS) is software used to plan, execute and optimise the physical movement of goods. Enterprise TMS platforms cover carrier selection, tendering, load consolidation and freight audit. Delivery-focused TMS platforms cover route optimisation, dispatch, real-time tracking and proof of delivery. Most own-fleet operators only need the second half.

Picture an operations manager running 22 vans out of a single depot. She types "transportation management system" into Google, lands on an enterprise vendor page, and reads about multimodal freight tendering, EDI carrier connectivity and a phased ERP integration.

Her conclusion: this category is three sizes too big for us.

So she goes back to the spreadsheet she uses to plan tomorrow's runs. That conclusion is wrong, and it is the most expensive mistake in this whole software category. The rest of this piece is about which half of a TMS you actually need, and how fast that half switches on.

What is a transportation management system (TMS)?

A transportation management system is software that plans, executes and tracks the movement of goods. It decides how a shipment travels, in what sequence, and with which vehicle or carrier, then monitors it in real time and records the outcome.

It sits between the system that holds the order and the customer receiving it.

Think of the stack in three layers. An enterprise resource planning system (ERP) owns the order, the invoice and the financial record. A warehouse management system (WMS) owns everything inside the building: receiving, putaway, picking, packing, stock accuracy.

The TMS owns everything between the dock door and the customer's door.

In supply chain management terms, that covers inbound and outbound movement, and in larger operations it spans multiple modes: land, air and sea. For a courier, a bakery or a building supplier, it means one thing: which driver, which van, which sequence, which time window, and what evidence you hold when the customer says nothing arrived.

TMS for freight vs TMS for last-mile delivery

The word "transportation" hides two very different jobs.

If you buy freight, your problem is procurement. You are choosing between carriers, comparing rates, consolidating pallets into fewer loads, and checking whether the invoice matches what was quoted. The vehicles belong to someone else.

If you run your own vehicles, none of that applies. You already know who is carrying the goods. Your problem is sequence, timing and evidence.

That distinction matters commercially, because the money sits in different places. According to McKinsey's research on parcel economics, published in 2016, last-mile delivery accounts for roughly half of total parcel delivery cost. Read McKinsey's analysis of how customer demands are reshaping last-mile delivery and the pattern is clear enough: the final leg is where the cost concentrates.

Which is why an own-fleet operator who buys the procurement half of a TMS is optimising the wrong end of the journey.

Visibility is not a soft benefit either. The World Bank's Logistics Performance Index scores national economies on six dimensions, two of which are tracking and tracing, and timeliness of shipments. Shipment visibility is measured as a capability, not treated as a garnish.

Core capabilities of a modern TMS: planning and procurement vs execution and visibility

Split the category in two and the buying decision gets much simpler.

Planning and procurement covers carrier selection and tendering, rate comparison, load consolidation, freight audit and settlement, and multimodal movement across land, air and sea, inbound as well as outbound. This is the half that talks to carriers over API or EDI links and reconciles what you were charged against what you agreed.

Execution and visibility covers route optimisation, dispatch, the driver app, real-time tracking and live ETAs, electronic proof of delivery (ePOD), exception and failed-delivery handling, customer notifications, and operational analytics.

Both halves are legitimate TMS capability. Wikipedia, SAP and Oracle all describe roughly this feature set, and they are not wrong.

But they are describing a market where the average buyer moves containers. If your average buyer moves 90 drops a day in a Hino, the second column is the product and the first column is overhead.

TMS vs WMS vs ERP vs route optimisation software

This is where most buying processes go sideways. Four categories overlap at the edges, so teams either buy two systems that do the same job or assume the system they already own covers something it doesn't.

System	What it owns	Who buys it	Typical implementation window	Where double-spend happens
TMS	Movement of goods once they leave the building: vehicle or carrier assignment, route sequence, dispatch, tracking, delivery evidence	Transport and logistics managers, dispatch teams, own-fleet operators	Days to weeks for execution-only scope. Months for enterprise procurement and freight settlement scope	Buying enterprise procurement modules you never use because you own the vehicles
WMS	Everything inside the four walls: receiving, putaway, storage, picking, packing, stock accuracy	Warehouse managers, 3PL site leads	Months, tied to stock migration and cutover	Light despatch add-ons that print labels but stop before routing and proof of delivery
ERP	Orders, purchasing, inventory value, invoicing, finance, the master business record	Finance and IT leadership	Quarters, sometimes longer	Assuming the shipping module optimises multi-stop routes. It rarely does
Standalone route optimisation	Stop sequencing and travel time under constraints such as time windows, capacity and driver shifts	Dispatchers and ops managers in small fleets	Days	Solves planning, leaves driver execution, customer notifications and delivery evidence unsolved, so a second tool gets bought later

Read the last column twice. That is the pattern behind most logistics software regret.

Are you too small for a TMS? A three-tier right-sizing guide

Here is the guide nobody selling enterprise freight software has any reason to publish.

Tier one: the freight-heavy shipper. You move pallets and containers through third-party carriers, across states or borders, sometimes multimodal. You need the full enterprise TMS, procurement included: tendering, rate comparison, load consolidation, freight audit, EDI carrier connectivity. Budget quarters, not weeks, and expect to touch the ERP.

Tier two: the own-fleet delivery or field-service operator. Your vehicles, your drivers, recurring routes, service windows, same-day or next-day promises. Carrier tendering and freight audit are dead weight for you.

What changes your day is route optimisation, dispatch, live tracking, customer notifications and electronic proof of delivery. And that layer goes live in days to a few weeks, because it does not touch procurement or finance systems.

Most own-fleet operators need the execution half, and it deploys in weeks rather than quarters. Say that out loud in a boardroom and half the objections to "we're too small for a TMS" disappear.

Tier three: the mixed model. You run your own fleet for metro and hand long-haul or overflow to carriers. Run the execution layer for the fleet and connect it by API to whatever enterprise TMS or ERP handles the freight side. Hybrid is normal, not a compromise.

What a TMS actually changes in daily operations (and the five metrics to measure it by)

Forget the feature list for a moment. Here is what shifts in the depot.

Planning stops being a morning ritual. Instead of an hour rearranging stops in a spreadsheet, the run sheet is built against real constraints: time windows, vehicle capacity, driver shift length, service duration at each stop.

Dispatch stops being a phone call. Drivers see the sequence in an app, mark stops as complete, capture a signature or a photo, and flag a failed delivery with a reason code rather than a text message at 4pm.

And the office stops guessing. When a customer rings asking where the delivery is, the answer takes seconds, not a round of calls.

Measure it with five numbers and nothing else:

• On-time delivery rate
• Drops per driver hour
• Planning time per route
• Failed-delivery rate
• Cost per drop

If those five are not moving after a quarter, the system is not being used properly, or it was the wrong system. We see both, and the second one is usually a tier mismatch from the guide above. Our breakdown of how a transport management system reduces delivery delays goes further into the delay-specific mechanics.

Three delivery operations, three different TMS workloads

"Delivery" is not one workload. Three real Locate2u customers make that obvious, and the differences are all in the execution layer.

SuperPharmacy runs prescription home delivery. Chain of custody is the job: the right medication reaching the right patient, with a delivery record that stands up to scrutiny. Rate shopping between carriers is irrelevant here. Signature capture, delivery evidence and a defensible audit trail are the entire point.

Franz Building Supplies delivers building materials. Heavy goods, site access constraints, and tradies who need materials before the crew starts rather than sometime today. The constraint set is vehicle capacity, access window and proof that the drop happened where it was meant to.

Gate Gourmet handles airline catering. Time-critical delivery at airport scale, where a schedule moves and the plan has to move with it. That is a live re-sequencing and dispatch problem, running continuously.

Three operations. Zero interest in freight tendering between them. All three depend on the same execution capabilities: routing under constraints, dispatch, live status, delivery evidence.

How to evaluate a TMS: connectivity, implementation time, driver app, operational fit

Start with fit, not features. Work out which tier you sit in first, because a tier-two operator evaluating tier-one platforms will spend six weeks in demos learning about modules they will never switch on.

Then check connectivity honestly. Does it integrate with what you already run, natively, or does every connection become a project? Ask which systems are supported out of the box, whether there is a public API, and whether carrier links use API or EDI if you need them at all.

Ask about implementation the way you would ask a builder about a deadline. What does week one look like. Who does the data setup. When does the first driver run a real route.

Then put the driver app in front of an actual driver. Not the ops manager. The driver.

If it takes more than a minute to complete a stop and capture evidence, adoption will fail and the data behind your five metrics will be junk.

Finally, test exception handling. Nobody home, gate locked, wrong address, damaged goods. How does the driver record it, who gets notified, and does the reason code end up in a report you can act on. Gartner Peer Insights reviews for the transportation management systems market are a useful neutral read here, because verified buyers tend to talk about integration effort and support quality rather than feature counts.

Worth noting on the demand side: the International Transport Forum's Transport Outlook 2023 projects global freight demand more than doubling by 2050 under current policies. Whatever you buy needs to still work when your volume is not what it is today.

Where Locate2u fits: the delivery-execution layer, honestly scoped

Locate2u is the execution and visibility half, built properly. Route optimisation, dispatch, a driver app operators actually adopt, live tracking with customer-facing ETAs, photo and signature proof of delivery with geo-stamped records, exception handling, and reporting on the five metrics above.

It is the strongest option in that layer, and not narrowly. The interface is built for a dispatcher at 6am rather than a systems analyst. Native integrations cover Shopify, WooCommerce, ShipStation, Xero, ServiceM8 and Zapier, with a public API for everything else. It runs a three-van operator and a 1000-plus driver fleet on the same platform, so growth does not mean re-platforming. It handles parcels and heavy goods, not one or the other. And it works across Australia, New Zealand, the UK, the US and Canada, with Australian-built engineering and support behind it.

What it is not: a freight procurement platform. Locate2u does not run carrier tendering, rate shopping, freight audit or EDI-based freight settlement. Those are capabilities of enterprise TMS platforms, and if you genuinely buy a lot of third-party freight, you need one of those as well. Connect the two by API and let each do its job.

If you have already decided which half you need and want to compare specific products, our round-up of transportation management software platforms covers the shortlist side of the decision.

Transportation management system FAQs

What is a transportation management system in simple terms?

A transportation management system is software that plans, executes and tracks the movement of goods. It decides how shipments travel, in what sequence and with which vehicle or carrier, then monitors delivery in real time and records the outcome.

What is the difference between a TMS and a WMS?

A warehouse management system controls what happens inside the building: receiving, storage, picking, packing and stock accuracy. A TMS controls what happens once goods leave it, covering route planning, dispatch, carrier selection, tracking and proof of delivery.

Is a TMS the same as route optimisation software?

No. Route optimisation is one capability within a TMS. A full TMS also covers dispatch, real-time tracking, proof of delivery, exception handling and analytics. Standalone routing tools solve sequencing but usually stop before driver execution and delivery evidence.

Does a small delivery business need a transportation management system?

It usually needs the execution half, not the freight-procurement half. If you run your own vehicles on recurring routes, carrier tendering and freight audit add cost without value. Route optimisation, dispatch, live tracking and proof of delivery are what change daily operations.

How long does a TMS implementation take?

It depends on scope. Enterprise programmes involving ERP integration, EDI carrier connectivity and freight settlement commonly run for months. A delivery-execution TMS covering routing, a driver app, tracking and proof of delivery can be live in days to a few weeks.

What features should I look for when choosing a TMS?

Start with tier fit, then assess integration options and which systems are supported natively, implementation effort, driver app usability, exception and failed-delivery handling, and reporting on on-time rate and cost per drop.

The practical takeaway

If you buy freight, you need a full enterprise TMS and you should budget accordingly. If you run your own vehicles, you need the execution layer, and being small is not a reason to stay on the spreadsheet.

Work out your tier before you sit through a single demo. It will save you a quarter of wasted evaluation.

When you are ready to see what the execution layer looks like against your own routes, book a walkthrough with our team, or check the Locate2u pricing tiers to sanity-check the numbers first.