General
The Complete Guide to Choosing a TMS: Why the Category Has Split Into Five Platform Types
Key Takeaways
- TMS is a label applied to at least five structurally different platform types built for different operational models. Feature checklists cannot distinguish between them.
- The decisive question is your data model. Operations organized around shipments with one origin and one destination need a different architecture than operations organized around routes with 20 to 50 stops per driver per day.
- Most TMS disappointment is archetype mismatch rather than implementation failure. The platform did what it was designed to do, and it was designed for someone else.
- Answering five questions before the first demo will disqualify three or four of the five archetypes immediately, which is a better use of an evaluation than scoring eight vendors on the same 200 rows.
- Within the right archetype, evaluation should run against your real operational data rather than the vendor’s demo script.
Why TMS comparisons fail most buyers
The standard evaluation process is well established: build a feature checklist, issue an RFP to eight vendors, score the responses, select the highest total. It produces a defensible procurement file and, frequently, the wrong platform.
The reason is structural. A feature checklist assumes all vendors compete on the same dimensions, which assumes TMS is one category. It is not. A vendor scoring highly on every row of a generic checklist can be architecturally mismatched to your operation in a way no row will reveal, because the mismatch is in the data model rather than in the feature list.
Consider what “manages carrier relationships” means to two different platforms. To an enterprise shipper TMS it means rate management, tendering, contract compliance, and freight audit across modes. To a last-mile execution platform it means allocating individual orders to carriers at dispatch time and re-allocating when a route runs late. Both answer yes to the checklist row. They are not doing the same thing, and a buyer who needs the second will be badly served by the first.
This is not hypothetical. A Fortune 50 parcel and logistics provider moving more than a million freight shipments a year implemented a replacement freight platform intended to handle routing within its own stack. It could not run dispatch. The platform was not defective; it was the wrong archetype for the job, and the operation ended up deploying a separate all-mile decisioning layer alongside it, eventually governing 4,500+ drivers under one policy and moving weekly execution from 75 percent to 92 percent across 51 service-center locations.
The financial stakes justify getting this right at selection rather than discovering it in production. A Gartner-commissioned analysis indicates the average TMS user can expect to save 5 to 15 percent of annual freight costs, with more than 40 percent of adopters breaking even within 6 to 12 months and a further 25 percent within 18.
Also Read: How to Evaluate a Modern TMS in 2026: A Practical RFP Framework for US Enterprises
Archetype 1: Enterprise shipper TMS
Built for large shippers managing complex carrier networks across freight modes, from full truckload and less-than-truckload through ocean, air, and parcel, with meaningful procurement leverage.
Core architecture. Carrier network breadth, rate management and tendering, freight audit and payment, and multimodal visibility aggregation. The organizing object is the carrier relationship and the shipment, not the delivery event.
Optimizes for freight spend, carrier compliance, audit accuracy, and network-wide visibility.
Where it underperforms. Stop-level dispatch, real-time driver management, and customer-facing delivery workflows. This is not a gap to be closed in a release; the data model is shipment-centric, and a shipment with one origin and one destination is a poor representation of a route with forty stops.
Buyer profile. Large shippers with dedicated logistics procurement functions and established ERP estates the TMS must integrate into.
Representative vendors. SAP Transportation Management, Oracle Transportation Management, Blue Yonder, MercuryGate.
Archetype 2: Freight broker and asset-light 3PL TMS
Built for brokers and non-asset 3PLs matching loads to carriers at high transaction volume.
Core architecture. Carrier marketplace connectivity, load board integration, automated tendering and rate confirmation, and margin tracking per load. The organizing object is the transaction.
Optimizes for load-to-carrier match speed, margin per load, carrier onboarding throughput, and dispatcher productivity.
Where it underperforms. Multi-stop route management and end-recipient visibility. A transaction model does not extend naturally to a route, because a route is a sequence with dependencies rather than a set of independent matches.
Buyer profile. Freight brokers scaling volume, non-asset 3PLs, digital freight platforms.
Representative vendors. Turvo, McLeod Software, and broker-focused platforms within larger logistics technology portfolios.
Archetype 3: Last-mile execution TMS
Built for retailers, logistics operators, and D2C brands running high-frequency multi-stop delivery, frequently same-day or next-day, where stop-level execution data matters as much as carrier selection.
Core architecture. Route optimization engine, real-time dispatch and driver tracking, stop-level event capture, customer notification, and exception management at the stop. The data model is stop-centric and driver-centric.
Optimizes for on-time and first-attempt delivery rate, cost per stop, driver productivity, and customer-facing metrics including ETA accuracy and proof of delivery.
Where it underperforms. Long-haul freight procurement, rate management at network scale, freight audit and payment, and ocean or air visibility. These are not last-mile problems and last-mile platforms are not built for them.
Buyer profile. Retailers running owned or contracted last-mile fleets, FMCG and grocery operators, D2C brands with tight SLAs, and logistics operators with dense urban route networks.
Representative vendors. Locus, Bringg, FarEye, Onfleet.
Also Read: Agentic TMS vs Legacy TMS: A 2026 Decision Framework for Enterprise Logistics Leaders
Archetype 4: 3PL multi-client TMS
Built for asset-based 3PLs and contract logistics providers operating on behalf of multiple shipper clients, where one infrastructure must support separate configurations, rate structures, and reporting per client.
Core architecture. Multi-tenant client management, client-specific rate cards and carrier assignments, visibility partitioned by client, and per-client billing and invoice generation.
Optimizes for efficiency across the client portfolio, client retention through reporting transparency, margin per client, and onboarding speed for new accounts.
Where it underperforms. Depth for any single client’s specialized operation. Multi-client architecture trades depth per client against breadth across clients, which is the correct trade for the buyer and a poor one for a single-shipper operation.
Buyer profile. Regional and national 3PLs, contract logistics providers, fulfilment operators serving multiple retail clients. The segment is substantial: Armstrong & Associates puts the global 3PL market near 1.3 trillion dollars, with 94 percent of domestic Fortune 500 companies using at least one 3PL.
Representative vendors. 3Gtms, Descartes, and multi-tenant platforms within larger logistics technology portfolios.
Archetype 5: Mid-market and e-commerce shipping platform
Built for growing e-commerce brands and mid-market shippers needing carrier rate shopping, parcel integrations, and basic visibility without enterprise cost or implementation weight.
Core architecture. Rate shopping and label generation, multi-carrier parcel integrations across national and regional carriers, connectivity to e-commerce and order management platforms, and basic tracking with exception alerts.
Optimizes for carrier rate savings, label automation, order-to-ship cycle time, and speed of integration with the commerce stack.
Where it underperforms. Owned-fleet route management, driver-level dispatch, freight procurement, and complex contract management. These platforms are built for parcel shipping rather than for logistics operations management, which is a category distinction rather than a maturity one.
Buyer profile. D2C brands without owned fleets, e-commerce operators, and smaller shippers evaluating a first platform.
Representative vendors. ShipStation, EasyPost, Shippo.
Five questions that identify your archetype
Answer these before the first demo. Most buyers will eliminate three or four archetypes immediately.
- What is your primary fulfilment model? Owned-fleet last mile, contracted carrier network, freight brokerage, or parcel shipping. This single answer determines archetype more reliably than any feature requirement.
- What is your optimization target? Cost per shipment points to archetypes 1 and 2. Cost per stop points to archetype 3. Margin per load points to archetype 2. Shipping rate points to archetype 5.
- Is your data model shipment-centric or stop-centric? If operations are organized around consignments with one origin and one destination, you need a shipment-centric platform. If they are organized around routes with 20 to 50 stops per driver per day, you need a stop-centric one. Retrofitting either into the other is where implementations go wrong.
- Who consumes your visibility data? Your freight and procurement team, your shipper clients, or your delivery recipients. Each implies a different visibility architecture and a different notion of what “real-time” needs to mean.
- Which integration is non-negotiable on day one? ERP for enterprise shippers, load boards for brokers, e-commerce platforms for mid-market, WMS and a driver application for last mile.
Integration capability is worth weighting heavily, because it is where deployments stall. Gartner found that 56 percent of chief supply chain officers cite integrating AI with legacy systems and processes as a major challenge, and 50 percent report limited internal expertise to implement and manage it.
Where Locus sits, and why last-mile evaluation is different
Locus, the world’s first Decision-Intelligent, Agentic TMS, sits in archetype 3, and last-mile buyers should run a materially different evaluation from general TMS buyers.
The metrics that decide a last-mile platform do not appear on a generic TMS checklist. First-attempt delivery rate, ETA accuracy measured at the stop, driver utilization per route, exception detection lag, and whether customer notification fires from actual driver progress rather than from a status milestone. None of these are freight metrics, and a scoring model built for freight will not surface them.
The integrations that matter are different too. WMS connectivity for route-ready order batching rather than ERP connectivity for financial posting. Driver application quality and offline reliability in the field, which is an operational risk rather than a feature. Customer-facing notification APIs. Proof-of-delivery capture with the evidence a dispute actually requires.
Locus’s architecture reflects those priorities. DiSCO runs eight named agents on a continuous Sense, Decide, Execute, Learn cycle, with the Dispatch agent planning and re-sequencing against 250+ real-world constraints per computation, the Capacity and Carrier agents allocating across owned fleet and contracted carriers in one decision, and the Customer agent managing the promise when a plan changes. The Fireworks Routing Engine generates plans in under five minutes at enterprise volumes and plans up to 100,000 routes simultaneously. Control Tower gives supervisors a live view across concurrent routes, and the Driver Companion App carries sequence, navigation, and proof of delivery in the field. Six governance mechanisms bound autonomous action: explainability, traceability, evaluation, autonomy levels, an execution sandbox, and human-in-the-loop override.
Locus has been recognized by Gartner for seven consecutive years, featured in the 2026 Hype Cycle for Supply Chain Execution and Logistics Technologies, named a Leader in TMS by QKS Group (SPARK Matrix), and ranked #1 in Route Planning on G2’s 2026 Best Software Awards. In October 2025, Ingka Investments, the investment arm of Ingka Group, the world’s largest IKEA retailer, acquired Locus. Locus continues to operate independently.
Archetypes are frequently complementary rather than competing. A leading North American retailer supplying a multi-hundred-store footprint across ocean, rail, and road ran six disconnected systems before consolidating onto one decision layer, retaining ERP and WMS as systems of record, and reported 99 percent-plus on-time store delivery, exceptions resolved in under two hours, and break-even inside the first year. Large operations commonly run an archetype 1 platform for procurement alongside an archetype 3 platform for execution, and that layering is a deliberate architecture rather than a failure to consolidate.
Signs you are already in the wrong archetype
Most readers of a page like this have a platform already. Five symptoms indicate archetype mismatch rather than implementation debt, and the distinction matters because the remedies are completely different.
Your team maintains a parallel spreadsheet for the thing the platform was bought to do. Not for a niche exception, but for a core daily task. This is the clearest single indicator, because it means the operating model and the data model disagree.
Plans are routinely overridden and the override reasons repeat. Recurring overrides mean the system cannot express a constraint your operation genuinely has. If the constraint cannot be added, the model does not accommodate it.
Reporting requires exports and joins. When answering a routine operational question means pulling two extracts and reconciling them, the platform is holding the wrong object as its primary record.
Implementation keeps extending to add capability that felt standard. Scope growth toward features that seemed table stakes at purchase usually indicates the vendor is building outside their archetype for you.
Adoption stalled and nobody can say precisely why. Teams do not reject software that fits their work. Persistent low adoption with vague complaints usually means the tool asks people to work in a shape their operation does not have.
The remedy differs by cause. Implementation debt is fixable with configuration, training, and time. Archetype mismatch is not, and continuing to invest in it is the expensive path. The realistic options are layering a second platform for the mismatched function, as the Fortune 50 provider did, or replacing.
Also Read: What is an Agentic TMS? A Practical Guide for Enterprise Logistics Leaders in 2026
How to run the evaluation once you know your archetype
Four practices that separate useful evaluations from theatrical ones.
Demo against your data, not their script. A last-mile buyer should bring fifty real stops from a recent operating day, including the awkward ones, and ask the vendor to plan and re-plan them live. Demo scripts are built to avoid exactly the cases that will decide your deployment.
Evaluate integration against your actual stack. Not an API checklist, but the specific WMS, OMS, ERP, or commerce platform that must connect on day one, and whether the connector is pre-built or a project. Ask who builds it, who maintains it when the other vendor changes their API, and whether either is billable.
Ask for references with your operational model, not your industry. A grocery retailer running owned-fleet delivery has more in common operationally with a parcel carrier than with a grocery retailer using 3PL fulfilment. Industry-matched references frequently validate nothing relevant.
Pilot on real data before signature. Most failures are detectable in a pilot designed around your genuine edge cases. They are rarely detectable in one designed around the vendor’s comfortable scenarios.
Weight architectural direction alongside current capability. Gartner projects that 60 percent of enterprises using supply chain management software will have adopted agentic AI features by 2030, up from 5 percent in 2025, and separately predicts that more than 40 percent of agentic AI projects will be cancelled by the end of 2027 due to escalating costs, unclear business value, and inadequate risk controls rather than to capability limits. Both point the same way: the platform will change, and how well it is governed matters more than which features shipped this quarter.
TMS archetype quick reference
| Dimension | Enterprise shipper | Freight broker / asset-light 3PL | Last-mile execution | 3PL multi-client | Mid-market e-commerce |
|---|---|---|---|---|---|
| Primary use case | Multimodal freight procurement and execution | Load-to-carrier matching at volume | Multi-stop delivery execution | Logistics operations across multiple clients | Parcel shipping and rate shopping |
| Data model | Shipment-centric | Transaction-centric | Stop and driver-centric | Client-partitioned shipment | Order and parcel-centric |
| Optimization target | Freight spend, audit accuracy | Margin per load, match speed | Cost per stop, first-attempt rate | Margin per client, portfolio efficiency | Shipping rate, label throughput |
| Key integrations | ERP, carrier contracts, financial systems | Load boards, carrier networks | WMS, OMS, driver app, notification APIs | Client systems, billing, carrier networks | E-commerce platforms, parcel carriers |
| Visibility consumer | Freight and procurement teams | Brokers and their shipper customers | Delivery recipients and operations | Shipper clients | Merchant and end customer |
| Implementation weight | High, ERP-coupled | Moderate | Moderate, field rollout dependent | High, multi-tenant configuration | Low |
| Representative vendors | SAP TM, Oracle TM, Blue Yonder, MercuryGate | Turvo, McLeod Software | Locus, Bringg, FarEye, Onfleet | 3Gtms, Descartes | ShipStation, EasyPost, Shippo |
Read the data model row first. It predicts fit more reliably than any other row, and it is the one dimension a vendor cannot change for you.
Frequently Asked Questions (FAQs)
How do you choose a TMS?
Identify your archetype before evaluating vendors. Answer five questions: your primary fulfilment model, your optimization target, whether your data model is shipment-centric or stop-centric, who consumes your visibility data, and which integration is non-negotiable on day one. Those answers usually eliminate three or four of the five platform types, after which a feature comparison within the remaining archetype becomes meaningful.
What are the different types of TMS?
Five: enterprise shipper TMS built around freight procurement and audit; freight broker and asset-light 3PL TMS built around load-to-carrier transactions; last-mile execution TMS built around multi-stop routes and stop-level events; 3PL multi-client TMS built around serving multiple shipper clients on shared infrastructure; and mid-market e-commerce shipping platforms built around parcel rate shopping and label generation.
Why do TMS implementations fail?
More often from archetype mismatch than from implementation error. A platform designed around shipments will struggle to manage routes with forty stops per driver, and the failure surfaces as poor adoption and manual workarounds rather than as an obvious defect. The second common cause is integration capability, with Gartner finding 56 percent of chief supply chain officers cite legacy integration as a major challenge and 50 percent report limited internal expertise.
What is the difference between a freight TMS and a last-mile TMS?
The data model. A freight TMS organizes around shipments with an origin, a destination, and a carrier relationship, optimizing procurement, tendering, and audit. A last-mile TMS organizes around routes, stops, and drivers, optimizing sequencing, first-attempt success, and customer-facing execution. They are not tiers of the same product, and large operations frequently run both, with the freight platform handling procurement and the last-mile platform handling execution.
Can one TMS handle both freight and last-mile?
Some platforms claim coverage of both, and the practical test is which data model the system is actually built on, since one of the two will be an extension. For operations where both matter materially, layering a procurement-oriented platform with an execution-oriented one is a common and deliberate architecture rather than a failure to consolidate.
What should you ask in a TMS demo?
Ask to see your own data planned live, using a genuinely difficult recent operating day rather than the vendor’s scenario. Ask which specific systems in your stack have pre-built connectors and which require a build, who maintains those builds, and whether maintenance is billable. Ask for references matched on operational model rather than industry. And require a pilot on real data, designed around your edge cases, before signature.
General
Last-Mile Delivery is a Time Problem, Not a Distance Problem, and the Industry is Optimizing the Wrong Thing
Aug 20, 2026
Route optimization targets road distance, which is the smallest controllable variable in urban last-mile. Why stop dwell time drives cost, the four stop archetypes, and how to measure what your operation is not measuring.
Read more
General
Best Logistics Companies Using AI-Driven Dispatch: An Enterprise Buyer’s Guide (2026)
Aug 20, 2026
Evaluating AI-driven dispatch platforms? Compare the top 8 logistics companies by orchestration depth, route optimization, visibility, and enterprise scalability.
Read moreInsights Worth Your Time
The Complete Guide to Choosing a TMS: Why the Category Has Split Into Five Platform Types