Best TMS software: how to choose a transportation management system

TMS software is bought by three different buyers — shippers, carriers and brokers — and most products are designed around one of them. Choosing well means deciding which side of the freight transaction the system has to serve, where rating and settlement are calculated, who runs the software, and what freight the data model covers.

Every product on a TMS shortlist will say that it plans loads, tracks shipments and produces charges, and every one of them is telling the truth. What decides the purchase sits underneath that description: which side of the freight transaction the product was designed for, where the money is calculated, who runs the software, and what kinds of freight the data model was built to carry. None of those four show up as a row on a feature grid, and all four are visible before a demonstration if you know where to look.

So this page is organised around the decisions rather than around checkmarks. What each named product does is stated in its vendor's own words with a link to where they said it, nothing here is ranked, and no prices appear: a figure lifted from another company's page goes stale without notice, and a stale price is a false statement about somebody else's business. It ends with the operations Shyftbase is the wrong answer for.

What every TMS agrees on, and where the agreement stops

The common core is real. An order becomes a shipment, a shipment becomes a load on a vehicle, the load becomes a sequence of stops, and the sequence becomes a set of charges to somebody and a set of payments to somebody else. Any system worth the name does that much, which is why feature lists in this category read almost identically.

The divergence begins one level down, at the question of whose freight it is. A shipper's TMS is organised around buying transportation: rating carriers, tendering loads, auditing the invoices that come back. A carrier's TMS is organised around selling it: dispatch, driver and equipment availability, and getting paid for the move. A broker's or 3PL's system is organised around standing between the two, which means it holds a customer rate and a carrier cost against the same load and lives on the difference.

Vendors are usually explicit about this if you read their product pages instead of their homepages. Trimble publishes separate transportation management products for carriers and for shippers, along with TruckMate and TMW.Suite, and organises its site around carriers, shippers, service centres, and 3PLs and brokers as distinct audiences^[trimble-tm]. McLeod Software describes core products — LoadMaster, PowerBroker and an LTL product — that can be configured separately or together, with integral accounting and financial management, for trucking companies, logistics service providers and private fleets^{[mcleod-solutions]}. Turvo takes the opposite approach and describes one platform that 3PLs, brokers, shippers and carriers all work on together^{[turvo-what-is]}. Those are three coherent answers to the same question, and they are not interchangeable.

The four decisions that actually differ

A feature grid will not separate these products, because at the altitude a feature grid is written they all do the same things. Four questions do separate them, and each can be answered from public material before anyone books a call.

The money question deserves the most attention because it is the hardest thing to see in a demonstration and the most expensive thing to get wrong. Ask it about the specific product being demonstrated rather than about the vendor's portfolio, because the two answers are often different. SAP presents transportation planning, interactive freight tendering and freight settlement as parts of one application, and presents carrier collaboration and shipment tracking as related SAP Business Network solutions alongside it^[sap-tm]. Both shapes are legitimate and they carry different implementation footprints, which is the sort of difference a portfolio slide hides by drawing every box the same size.

The deployment question is asked less often than it should be, and it is usually answerable from public pages rather than in a meeting. McLeod states that its solutions may be hosted on-premise or in a third-party cloud environment by the customer, or hosted and managed by McLeod through its own cloud service^{[mcleod-solutions]}. If an IT policy or a customer's security review requires one particular shape, that constraint decides the shortlist before any capability does — so ask every vendor for their deployment options in writing rather than inferring them.

What each of these systems says it is built for

The table below is each vendor's own description of its product's scope, taken from the page linked in it. It is not a scorecard, and nothing in it says which product is better at anything.

Two of these are enterprise supply-chain suites and read that way. Oracle describes Oracle Transportation Management as managing transportation activity throughout a global supply chain and covers planning from simple point-to-point movements through multimodal, multileg and cross-dock operations^[oracle-otm] — scope that is genuinely necessary if your freight crosses an ocean before it reaches a truck, and considerable overhead if it never does.

Shyftbase belongs to the narrower group and the boundary is the point of it. It is a transportation management system for land-based freight — planning and routing, the leg between facilities, the leg to the door, and the billing and carrier settlement that follow both — with no air, ocean, port or customs scope of any kind. The reason to draw the line there is that planning and money share one data model: a shipment planned in the network module is rated, invoiced through automated freight billing and settled through carrier and driver payables without an export in between. Shyftbase was founded in 2019 and moves millions of shipments a year.

How to run your own evaluation

Do not evaluate on a demonstration dataset. Choose one real week from the last quarter — ideally a bad one — and ask every vendor on the shortlist to run it, with the screens a dispatcher and a billing clerk would actually be looking at rather than a slide.

Ask for four artefacts from that week, in one sitting and in one system: a rate applied to a real lane, a customer invoice for a completed move including an accessorial charge nobody expected, a carrier settlement statement for the same move, and the audit trail behind a plan that changed after dispatch. Then ask which of the four the system produced itself and which came from a second product, a services team or a spreadsheet. The rate is the easy one to show. The answer for the other three is the comparison.

Four more questions are worth asking in every call. What happens when a load changes after dispatch — a re-plan inside the system, or a phone call and a manual correction later? Who performs the implementation, and how long does it take from contract to first live shipment? Which fields does the accounting integration write back, in writing, field by field? And what does leaving cost: can you export rate tables, historical shipments and delivery documents in a usable form, and who owns them?

Implementation length is where answers diverge most, so pin it down: ask for the number, the assumptions behind it, and what has to be true of your data for it to hold — in writing, from each vendor, rather than from a brochure. Shyftbase's own answer is weeks rather than months for most mid-market operations, and it publishes no price at all — what a quote actually turns on is a short list of variables, and having answers ready shortens every conversation that follows.

The limits of this comparison, and where Shyftbase is the wrong answer

This page ranks nothing and carries no ratings, no scores and no prices, because there is no measurement behind any of them that a reader could check. What it does carry is what each vendor says about its own product, cited to where they said it — which is evidence about intent and design, not about how well any of it works on a Tuesday in your building. It is also written by a vendor in the category, and no amount of careful phrasing removes that conflict. Read it as one.

Shyftbase is the wrong answer in several situations that are easy to recognise. If any leg of the journey is ocean or air, the land-based boundary above rules Shyftbase out, and a suite whose own page states multimodal and multileg planning — as Oracle does^[oracle-otm] — is where to start instead. If the difficult transaction is a customs declaration rather than a mode, that is a different shortlist again: nothing cited on this page speaks to cross-border filing, and the supply chain software comparison names a vendor whose own page puts it in scope. If an IT policy requires the software inside your own data centre, start with vendors who publish an on-premise deployment option, which McLeod does^{[mcleod-solutions]}. If the business is buying and reselling capacity all day and the software's main job is coordinating companies you do not own, a platform written for exactly that — Turvo describes itself as collaborative logistics for 3PLs, brokers, shippers and carriers^{[turvo-what-is]} — is a closer match than a system built around running one company's own network. If the binding constraint is inside a warehouse rather than on the road, the shortlist is a different category altogether, and the way those categories get confused is worth reading first. And if a long installed base in your exact segment is the deciding criterion, ask each vendor on the shortlist for customers who look like you, and weigh those answers rather than the page you read them on — this one included.