James Ledbetter
A transportation management system is one of the most significant technology investments a carrier can make. It is also one of the most frequently regretted ones.
Carriers buy a TMS for the wrong reasons, against the wrong requirements, on the wrong timeline — and then find themselves a year later with a system no one fully uses, that doesn’t talk to their other tools, and that hasn’t delivered the efficiency gains they were sold on. I’ve seen this cycle repeat across operations of every size.
The fix isn’t a different TMS. It’s understanding what a TMS is actually for and what it cannot do.
My professional opinion, stated plainly: most carriers who buy a TMS to solve a process problem walk away with an expensive system and the same process problem. The process has to come first.
What a TMS Is — and Isn’t
A transportation management system is software designed to manage the planning, execution, and visibility of freight movements. Depending on the platform, it may handle load planning, carrier selection, rate management, shipment tracking, documentation, billing, and reporting.
What it is not is a strategy. It is not a decision-maker. It does not create the operational discipline your team needs — it creates visibility into whether that discipline exists.
If your dispatchers are planning loads inconsistently, a TMS will show you that inconsistency more clearly. It will not fix it. If your billing process is a mess, a TMS with an invoicing module will process billing faster — but if the underlying data is wrong, faster is not better.
This distinction matters because the reasons carriers give for wanting a TMS are almost always process problems in disguise:
- “We need better visibility” — often means the tracking process is fragmented or no one owns it
- “We need to reduce billing errors” — often means the documentation and check-call process lacks standards
- “We need to plan loads more efficiently” — often means the planning function lacks defined criteria and accountability
- “We need better reporting” — often means data isn’t being captured consistently in the first place
None of these are solved by software. They are solved by process design, and then supported by software.
When You Actually Need a TMS
That said, there is a genuine threshold at which a TMS becomes the right investment. It’s a complexity threshold, not a size threshold.
A carrier running 15 trucks on well-defined lanes with established shipper relationships can operate very efficiently with a basic dispatch system, spreadsheets, and strong dispatcher execution. Adding a full TMS to that operation creates administrative overhead without proportional benefit.
The same carrier at 50 trucks with multiple load types, dedicated and spot freight, multiple shippers, and a need to report on performance across lanes and customers is a different story. At that point, human planners are holding more information than they can optimize without algorithmic support, and the cost of tracking errors and reporting gaps becomes significant.
Indicators that a TMS is the right next step:
- Load planning takes disproportionate dispatcher time relative to the number of trucks
- You cannot quickly generate lane-level cost and revenue reports
- Billing errors or disputes are a consistent time drain
- Customers are requesting shipment tracking visibility you can’t provide efficiently
- You’re running multiple freight types or service levels that create planning complexity
- You’re trying to grow but feel like operational bottlenecks are limiting capacity
Indicators that you’re not ready for a TMS:
- You haven’t defined your standard dispatch processes in writing
- Your data entry discipline is inconsistent across the team
- You’re looking at a TMS because you feel like you “should have one”
- You’ve recently had dispatcher or operations turnover and don’t have stable processes yet
- You’re underwater on current operational problems — a TMS will add complexity, not reduce it
Defining What Your TMS Must Do
Before you talk to a single vendor, write down — specifically — what problems you are trying to solve and how you will measure whether the system is solving them.
This sounds obvious. Most carriers skip it and go straight to demos. Demos are designed to impress, and every TMS will look capable in a vendor demo. What you need is a requirements document that reflects your actual operation.
A useful requirements document includes:
- Core workflows you need the system to support (load planning, dispatch, tracking, billing, reporting — rank them by priority)
- Integration requirements: what systems does the TMS need to talk to? (ELD, accounting software, load boards, customer portals)
- User roles and access levels — who will be in the system and what will they do?
- Volume expectations — loads per day, trucks, drivers, stops
- Reporting requirements — what data do you need to see, on what cadence, for whom?
- Budget, including implementation, training, and annual subscription
- Timeline and resource constraints — who on your team will manage implementation?
With a requirements document in hand, you can evaluate vendors against your actual needs rather than their feature lists. You will also be positioned to ask better questions and catch limitations that a polished demo obscures.
Evaluating Options Without Over-Buying
The TMS market spans a wide range — from basic dispatch and billing tools that cost a few hundred dollars a month to enterprise platforms with six-figure implementation costs. The right choice is not the most capable system. It is the most appropriate system for your actual operation and your team’s ability to use it.
Evaluation criteria that matter:
Integration depth, not breadth. Every vendor will show you a list of integrations. What you need to know is whether the specific systems you use are supported, how that integration actually works (real-time sync vs. batch file transfer), and who is responsible when it breaks. Ask for references from carriers using the same integrations you need.
Implementation support. A TMS that takes eight months to fully implement is not delivering value for eight months. Ask specifically: what does implementation look like for an operation like ours? Who does the data migration? Who trains the team? What does go-live support look like?
Adoption realism. The best TMS fails if your dispatchers don’t use it correctly. Ask vendors about typical adoption timelines and common failure points. Talk to other carriers who are 12-18 months post-implementation — not 30 days post-implementation. The honeymoon is not informative.
Reporting flexibility. Pre-built reports are rarely exactly what you need. Can you build custom reports without IT support? Can you export data to your own tools? Visibility into your own data should not require a support ticket.
Contract terms. Multi-year contracts with limited exit provisions are common in TMS sales. Understand what you’re signing. If the system doesn’t perform, what are your options?
Integration Realities
Integration is where TMS implementations most commonly disappoint, because the expectation and the reality diverge.
An integration between your TMS and your ELD should mean that driver hours, location data, and load status flow automatically. In practice, integrations often require configuration work, have data latency, break when either system updates, and require ongoing maintenance. Your internal resource for managing this should be identified before you sign a contract.
The same is true for accounting system integrations. If your TMS invoicing module needs to sync with QuickBooks, Sage, or a custom accounting platform, that integration needs to be tested against your actual transaction types before you commit — not accepted on the basis of a vendor’s assurance that it “supports” the integration.
Questions to ask about every integration:
- Is this a native integration or a third-party connector?
- What data flows in each direction, and how frequently?
- Who supports it when it breaks — the TMS vendor or the other vendor?
- Can we see it demonstrated with real data from our system?
Getting Adoption Right
A TMS with 60% adoption produces 60% of the value at 100% of the cost. Adoption is not a training problem alone — it is a change management problem.
Dispatchers and operations staff who have developed their own workflows over years will not automatically embrace a new system, especially if it adds steps to processes they’ve optimized manually. Resistance is rational. Overcoming it requires more than a training session.
What drives real adoption:
- Involvement of key users in requirements definition and vendor selection — people commit to what they helped choose
- A champion on the team who is accountable for system use and can support peers
- Clear standards for what must be done in the system vs. outside of it
- Visible management attention to adoption metrics in the first 90 days
- A feedback loop where user complaints surface quickly and get addressed
For carriers running our fleet operations and supply chain advisory, TMS evaluation and implementation support is something we do alongside clients — not just recommending a platform but helping design the process changes and adoption plan that make the investment work.
The Process-First Principle
To restate my core argument plainly: the carriers who get the most value from a TMS are those who already have disciplined, documented operational processes and are buying software to scale and support those processes. The carriers who get the least value are those who are hoping the software will create the discipline they don’t yet have.
This isn’t a criticism of TMS products. It’s an honest observation about what software can and cannot do. Software is a multiplier. If your process is strong, a TMS multiplies that strength. If your process is weak, a TMS gives you faster and more expensive evidence of that weakness.
Fix the process first. Then buy the software to support it.
If you’re not sure whether your process is ready, that’s a good question to bring to a consultant before you bring it to a vendor. Vendors have an interest in selling you their system. A good consultant has an interest in making sure the investment produces results.
Frequently Asked Questions
Q: How do I know if we’re big enough to need a TMS? Size is less relevant than complexity. The right question is whether your operational complexity has outpaced what your current tools and team can manage efficiently. Signs include chronic billing errors, planning delays, poor lane-level reporting, and dispatchers who can’t easily answer basic performance questions.
Q: What does a TMS typically cost for a smaller carrier? Costs range widely — from modest monthly subscriptions for basic dispatch and billing tools to enterprise platforms with significant implementation costs. Evaluate total cost of ownership over three years, including implementation, training, integration, and annual subscription. The monthly subscription price is often the smallest part.
Q: Should we build our own system or buy one? Building custom transportation software is expensive, slow, and rarely cost-effective for carriers who are not also technology companies. Proven platforms — even imperfect ones — nearly always make more sense than custom development for standard transportation operations.
Q: How long does TMS implementation typically take? A realistic implementation timeline for a mid-size carrier is three to six months to functional use, with another three to six months to reach full adoption and data quality. Plans that promise faster timelines often involve shortcuts that surface later as data problems or user workarounds.
Q: Can LAN help us evaluate TMS options? Yes. We work with carriers to define requirements, evaluate options against those requirements, and design implementation and adoption plans. We’re not affiliated with any TMS vendor. Start with a free consultation.
Take the Next Step
Choosing a TMS is a significant decision with a long tail — the right choice pays dividends for years; the wrong one creates persistent cost and frustration. Getting it right starts with honest process assessment, clear requirements, and vendor evaluation grounded in your actual operation.
If you want help thinking through whether you’re ready for a TMS and how to evaluate your options, LAN is ready to have that conversation. We’ll tell you what we see — including if the timing isn’t right.
Learn more about how we support carriers and fleets with operations and technology decisions, and explore our full range of logistics consulting services.
Disclaimer: TMS features, pricing, and integration capabilities change frequently. Verify current vendor offerings and validate integration compatibility with your specific systems before purchasing.
