The Decision You Can't Easily Undo
Most TMS platforms on the market work. Dispatch boards dispatch. Invoices go out. Settlements calculate. If your shortlist consists of established products, you are not choosing between software that works and software that does not.
You are choosing fit. That is where most decisions go wrong.
Carriers rarely regret buying a broken product. They regret buying one built for a different kind of operation, one their dispatchers and drivers quietly refuse to use, or one the company outgrows within a year. None of that is obvious in a demo. It becomes obvious six months later, when the system meant to run the business becomes one more thing the business has to fight.
That is what makes the decision heavier than it first appears. Switching a TMS is not like switching a fuel card. Your load history, customer and broker records, rate data, and your team's daily habits all settle into the system. Pulling them back out is slow, expensive, and risky.
Buy the wrong TMS and you pay twice: once to adopt it, and again to escape it.
The stakes are higher now because the margins are thin. ATRI's July 2026 update found that truckload margins improved during 2025 but remained below 1%. When rates are soft and costs keep rising, a back office that wastes time and delays billing is not a minor inconvenience. It is a leak in a boat already sitting low in the water.
This guide is designed to help you make the decision once and make it well. It will not name the "best" product, because no such product exists in isolation. There is only the system that fits your fleet, your operating model, and the company you expect to be running two years from now.
That is the decision. Everything that follows is about getting it right.
Before You Shop: Are You Even Buying the Right Category?
Before comparing products, answer two questions. They determine whether you are shopping in the right aisle at all.
Do you actually need a TMS yet?
Not every operation does, though few vendors will tell you that.
If you run a handful of trucks and your spreadsheets, whiteboard, and memory are still keeping pace, you may not have reached the buying point. Software solves coordination problems that emerge with scale. Without the problem, there is no reason to pay for the solution.
The real signal is rarely a specific truck count. It is a breaking point.
Billing slips, and cash flow tightens because invoices go out late. Dispatch becomes a trail of texts and sticky notes, with no clear view of where each driver stands. A broker leaves because you cannot provide reliable tracking. You add trucks, and the person handling settlements can no longer keep up.
The moment the manual process begins costing you money or customers, the decision changes. Before then, you may simply be buying software for a problem you do not yet have.
If you are past that point, the next question matters just as much.
What Is a Carrier TMS, and How Is It Different?
"TMS" describes more than one kind of software. Choosing from the wrong category is a common and expensive mistake.
A carrier TMS is built around the asset-based workflow. You own or operate the trucks, and the system carries a load from dispatch through delivery, invoicing, and driver or owner settlement.
A broker or freight-forwarder TMS is built around a different job: sourcing capacity and managing carriers. The two may look similar on a feature list, yet behave very differently in daily use. If you run trucks, confirm that the product was built for carriers rather than adapted from brokerage software.
The other category mistake can be even more costly. A telematics or ELD platform should not automatically be treated as a complete back-office TMS.
Motive and Samsara are the names most operators know, and both are strong at what they do: GPS visibility, HOS compliance, safety, and dash cams. Samsara began with a connected vehicle gateway for GPS, diagnostics, and fleet visibility. Motive began as KeepTruckin with an electronic logbook app before expanding into ELD hardware, telematics, safety, and broader fleet-management workflows.
In many trucking operations, Motive or Samsara serves primarily as the ELD, telematics, safety, and vehicle-data layer connected to a TMS. Both support operational workflows, but neither should be assumed to replace a carrier TMS that provides the complete back-office lifecycle, including native invoicing, accounting workflows, and driver or owner settlements.
Once you know you need a carrier TMS, rather than a broker tool or a telematics platform expected to do a different job, the field narrows according to your operating profile.
Broadly, owner-operators and the smallest fleets are served by simple, low-cost tools. Small-to-mid asset-based carriers and dispatch companies are the natural market for modern cloud TMS platforms. Enterprise systems tend to make sense when workflow complexity, integration requirements, reporting needs, and implementation resources justify their weight.
Fleet size is a useful signal. It is not a reliable cutoff by itself.
Know your operating profile before speaking with vendors. Otherwise, you risk being sold up into complexity or down into a system you will quickly outgrow.
Why Smart Operators Still Choose the Wrong TMS
Experienced operators make poor TMS decisions too. Not because they are careless, but because the buying process rewards the wrong instincts.
Here is where good operators tend to go sideways before the first demo is even over.
They think more features mean a better system. A longer feature list feels safer. Often, it signals the opposite. Feature-heavy platforms are usually built for complex operations. For a 20-truck fleet, that can mean a harder implementation, a steeper learning curve, and screens crowded with functions no one will use.
Depth you do not need is not a bonus. It is weight.
The useful question is not, "Which system does the most?" It is, "Which system does what we need without making us work around everything we do not?"
They over-buy and under-buy for the same reason. Both mistakes begin with misjudging size.
Over-buying is the small fleet that purchases enterprise software, takes on a heavyweight implementation, and pays for capabilities it may never use. Under-buying is the growing carrier that chooses a bare-bones owner-operator tool, then reaches its operational or technical limits as the fleet expands.
They look like opposite decisions. They are the same mistake: choosing for the wrong scale. Because switching is so disruptive, both usually end the same way. The carrier buys twice.
They underweight the one factor that decides everything. Adoption.
A TMS your dispatchers and drivers will not use is wasted money, regardless of how well it performed in the sales presentation. Buyers often discount this during evaluation and regret it later.
If dispatch finds the new board slower than the old process, people will drift back to familiar habits. If the driver app is clumsy, drivers will stop uploading documents and updating statuses. The data you expected never arrives, and the system quietly becomes incomplete.
The best TMS is the one your team opens every day. Everything else is theory.
They confuse the telematics platform they already have with the TMS they still need. This is both a category mistake and a mindset trap.
"We already have Motive. Doesn't that cover it?"
It may cover much of the truck-side workflow. That does not mean it covers the complete back-office lifecycle your operation requires.
Treating an ELD or telematics platform as a TMS without checking the full workflow can leave the operation with half a system and the false comfort of believing the search is over.
Avoid these four traps, and the evaluation becomes much clearer.
How to Choose a TMS: The Criteria That Actually Matter
The following criteria separate fit from noise for fleets in the 1-to-100+-truck range. Weight the top of the list heavily. The lower items still matter, but they rarely decide the outcome.
- It is built for asset-based carriers
- Your team will actually use it
- Data goes in once and flows everywhere
- It integrates with your existing stack, specifically
- It fits how you actually pay people
- It fits where you are headed, not only where you are
- Everything else: reporting, compliance, support, contract terms
1. It is built for asset-based carriers. This is non-negotiable. If the foundation is wrong, nothing else matters. The system should carry a load through the real operating lifecycle, from dispatch to delivery, invoice, and settlement, as a native workflow rather than a workaround attached to broker software.
2. Your team will actually use it. Adoption deserves the second-highest weight because it determines whether every other capability produces value.
Judge the dispatch board by speed. That is where dispatchers spend their day. Judge the driver app by a simpler standard: will a driver actually open it to upload a BOL or update a status?
A system the team resists rarely fails dramatically. It fails quietly.
3. Data goes in once and flows everywhere. This is where much of the real time savings comes from.
Once a load is entered, its information should move forward into tracking, invoicing, and settlement without being re-keyed at every stage. Carriers that report the largest gains after leaving spreadsheets, including shorter billing cycles and faster payment, are often describing this one mechanic.
Vendors may publish claims about faster load entry or greater load volume. Treat each number as a vendor-specific claim and ask for its methodology, baseline, and customer evidence.
The better platforms treat single entry as the default rather than a feature to configure, and Derekto is one of them.
The operating principle remains sound: enter once, use everywhere.
4. It integrates with your existing stack, specifically. "Integrates with ELDs" is not a useful answer.
The question is whether the platform integrates with your ELD, the one already installed in your trucks. Confirm native connections to your specific provider, your accounting system, such as QuickBooks if that is what your company uses, your factoring company, fuel cards, and the load boards you actually use.
A good TMS should connect to the operation you already run. It should not force employees to re-enter data by hand or require you to replace hardware you have already paid for.
Check integrations by name, not by category.
5. It fits how you actually pay people. This is often treated as a secondary detail. It should not be.
If you work with both company drivers and owner-operators, the settlement logic is not simple. An owner-operator leased to and operating under your authority is commonly paid through a settlement. A separate motor carrier operating under its own authority may instead pay a dispatch-service fee through invoicing, deductions, or another arrangement defined by its contract.
Those are different money flows. Some systems handle one cleanly and push the other into a workaround.
If you run a dispatch company or any mix of owner-operators, ask the vendor to demonstrate both flows using your real compensation structure. Include per-mile pay, percentages, per-load pay, detention, deductions, and reimbursements.
This is precisely the kind of operating detail that survives a generic demo and breaks during the first real settlement run.
6. It fits where you are headed, not only where you are. The goal is scalability without over-buying.
The system should support the fleet you operate today and the fleet you realistically expect to operate two or three years from now. It should neither cap out too early nor bury the company in enterprise complexity before that complexity is useful.
That is the balance: not too large, not too small, but sized to the actual trajectory of the business.
7. Everything else. Reporting depth, including cost per mile and profit by truck or lane, ideally available in real time rather than only at month-end. IFTA handling. Document storage and validation. Support quality. Contract terms. Data portability if you leave.
Each can break a tie. None should override the six criteria above.
The pattern is simple: fit and adoption belong at the top. Features belong below them. Operators who reverse that order are the ones most likely to buy the wrong system.
Running the Evaluation Without Getting Sold To
Good criteria only matter if the evaluation process is disciplined.
Too many buyers take a few demos, listen to polished presentations, and choose the vendor whose salesperson they liked most. A better process keeps the buyer, not the vendor, in control.
Start by auditing your own operation
Before opening a product website, map how work happens today.
Who handles dispatch, and through what process? Who creates invoices, and how long does it take? Who runs settlements? Where do loads fall through the cracks? Which problems are merely irritating, and which are costing the company money?
Those gaps are your requirements. Write them down before speaking with vendors. Every product should be measured against them.
Turn your pains into must-haves and nice-to-haves
Divide the requirements into two groups.
Must-haves are disqualifying. If the system cannot handle one, it is out, regardless of how impressive everything else looks.
Nice-to-haves are useful but negotiable.
This distinction prevents a common buying mistake: becoming impressed by a feature that solves no current problem while overlooking a missing capability that will create friction every day.
Make the demo about your reality, not their script
A standard demo is a controlled tour of the product at its best, using the vendor's data and the vendor's preferred workflow.
Do not accept that as the evaluation.
Send the vendor your must-have list and actual pain points in advance. Ask them to demonstrate how the system handles your scenarios: your load, your settlement structure, your broker, your operational problem.
A vendor that cannot or will not demonstrate your reality has already given you useful information.
Test one real task end to end
Feature lists conceal gaps. Workflows expose them.
Choose one task that matters and run it from beginning to end. If the system claims to read rate confirmations automatically, upload a real rate con, preferably a messy one, and watch how quickly and accurately it extracts the data.
One real workflow reveals more than a hundred checked boxes.
Get the right people in the room
The owner should not make this decision alone.
The people who will determine whether the system succeeds need to participate in the demos: a dispatcher who will live on the board, the person responsible for accounting, and a driver trusted to give an honest opinion about the app.
They will notice dealbreakers the owner may miss. Bringing them in early also makes adoption easier later. People are more likely to use a system they had a hand in choosing.
Check references before you sign
Ask each finalist to introduce you to a carrier of similar size that has used the system for at least a year.
Then ask practical questions. How did implementation actually go? How quickly does support respond when something breaks at 4 p.m. on a Friday? Has the platform been reliable?
A vendor confident in its product will make the introduction. Hesitation is also an answer.
TMS Pricing and Implementation: The Reality After You Sign
The demo is the easy part.
Two issues often surprise carriers and create regret: what the system really costs and what it takes to put it into operation. Neither receives enough attention before the contract is signed.
Give them yours.
The pricing model matters more than the sticker
Every vendor leads with a monthly number. That number is only the visible part of the cost.
What matters is the pricing model underneath it, because that determines what happens as the company grows.
TMS pricing generally takes several forms: per-truck pricing based on fleet size; per-user or per-seat pricing based on the number of people who log in; usage-based pricing tied to loads or transactions; and flat-fee-plus-add-ons, where the base subscription covers core functions and additional modules cost extra.
The same advertised price can produce very different totals depending on the model and the way your operation expands. A per-seat plan may be inexpensive when three people use it, then rise sharply when you hire another dispatcher and add two office employees. A per-truck plan scales with the fleet whether or not the office headcount changes. A usage-based plan changes with the volume running through the system.
The monthly price may also exclude setup, onboarding, modules you assumed were included, and the cost of a longer contract.
Published TMS prices are not directly comparable because vendors charge by user, truck, driver, load, module, or total platform subscription. Some publish a monthly minimum. Others use usage-based pricing or provide custom quotes.
Compare written quotes using the same fleet size, modules, contract term, implementation scope, and expected usage. Otherwise, you are not comparing the same thing.
The lesson is to price the model at the fleet size you are growing toward, not only the fleet size you have today.
Implementation is where rollouts live or die
The implementation gap between products can be enormous.
Cloud-TMS onboarding can range from days to several months, depending on data migration, integrations, configuration, training, and the scope of the rollout. Initial data loading is not the same thing as a complete operational implementation.
Complex enterprise implementations can require substantially more configuration, migration, integration work, training, and customer-side project management than lighter deployments. The specific burden depends on the product edition, the selected modules, and the operation adopting it.
Require every vendor to provide a written implementation schedule, staffing plan, services estimate, and scope of work. Do not rely on a general market benchmark or a sales promise about how quickly companies "usually" go live.
Match the rollout to the operation. A growth-stage carrier should not accept enterprise deployment weight unless its actual workflow requires it.
Two rules that save your billing
Data quality and migration are among the most consequential rollout risks.
Move inaccurate customer records, outdated broker information, or bad rate data into the new system, and the first invoices out of it will be wrong. That is the moment when the company can least afford mistakes.
Clean the data before it moves. Decide deliberately what belongs in the new system and what should remain archived in the old one.
One useful control is a time-limited parallel run, particularly for invoicing, settlements, and financial outputs.
Where operationally feasible, keep the old system available alongside the new one long enough to reconcile a complete billing cycle. Define the reconciliation criteria, the employees responsible, and the cutover date in advance.
A full duplicate-entry process is not right for every operation. Some fleets will be better served by a pilot group, staged cutover, module-by-module launch, controlled reconciliation, or read-only access to the legacy system.
What matters is not following one universal method. It is proving that the outputs reconcile before the old process disappears.
One more rule: obtain a signed scope of work before configuration begins. "We will work out the details during setup" is how surprise fees appear and promised workflows become assumptions.
The Decision Framework
At this point, you have defined the requirements, run disciplined demos, and calculated what the system will cost to buy and launch.
Now make the decision without allowing instinct or the smoothest salesperson to make it for you.
Score it, don't feel it
Take the criteria above, weight them for your operation, and build a simple scorecard.
List the factors as rows. Mark each as a must-have or a nice-to-have. Rate every finalist from one to five. Then total the scores.
This does two things. It limits the influence of emotion on a decision that is easy to make emotionally, and it gives you a clear explanation for a partner or lender who asks why one system was chosen over another.
Know which profile you actually are
Different fleets should buy different systems. The right answer depends on the operation.
If you operate a carrier with complex workflows, demanding integrations, deep reporting requirements, and the internal resources to support a substantial implementation, enterprise systems can justify their weight.
McLeod has served the transportation industry since 1985, and Trimble's TMW.Suite is an established enterprise-level TMS. Both offer comprehensive functionality for complex operations, although implementation scope varies by product, configuration, integrations, and customer requirements. Trimble also offers a newer cloud TMS positioned for growing full-truckload carriers, so buyers should evaluate the specific product rather than treating every Trimble system as the same category of purchase.
If you run a hybrid operation, combining a brokerage with an asset fleet, a platform designed for both sides may fit better than a pure carrier system. Rose Rocket is a relevant candidate because it supports both carrier and brokerage workflows within a configurable platform.
If fleet visibility, safety, and compliance matter more than back-office workflow, particularly when their hardware is already installed, Samsara and Motive are among the most prominent platforms in the telematics, ELD, safety, and visibility category.
Remember what you are evaluating. Both can support meaningful operational workflows, and both commonly connect with external TMS products. Confirm separately whether the platform covers the complete dispatch-to-settlement lifecycle your company needs.
If you want broad workflow automation across carrier, broker, dispatch-service, or hybrid operations, Alvys is worth evaluating. It includes operational accounting functions such as invoicing, IFTA reporting, reconciliation, and settlements, while also supporting integrations with external accounting systems. Buyers should confirm whether those capabilities meet their complete general-ledger and accounting requirements.
If you are an owner-operator or run only a few trucks, you may not need a full TMS yet. A simpler, less expensive tool, or the process you already have, may remain the right answer until the operation reaches its breaking point.
Where Derekto Fits
Derekto sits in the middle of that map. It is built for small-to-mid asset-based carriers and dispatch companies running roughly 1 to 100+ trucks, operations that have outgrown spreadsheets but have no reason to take on enterprise deployment weight.
It brings dispatch and load management, automatic rate-con reading, load tracking, document handling, invoicing, driver and owner settlements, IFTA, and mobile workflows for drivers and dispatchers into one system.
Two details make it relevant to this profile.
First, the system is deliberately sized for the range, so carriers are not paying for enterprise weight they are unlikely to use.
Second, Derekto models two owner-operator workflows separately: settlements for owner-operators leased to and operating under the carrier's authority, and dispatch-service billing for motor carriers operating under their own authority.
For a dispatch company or any operation with a real mix of owner-operators, that is the detail worth testing against every other product on the shortlist.
Evaluate it by the same standard as the others. Provide your must-haves. Ask for a demonstration using your actual settlement workflow. Upload a messy rate con and time the result. Score it against the field.
If Derekto is the best fit, the scorecard should show it. If another platform fits better, the scorecard should show that too. That is the point of using a disciplined process.
You can look closer at dispatch and load management, driver and owner settlements, invoicing, load tracking, IFTA, document management, and the driver and dispatcher app, or book a demo and bring your own scenario.
The One Thing to Carry Out of Here
If you remember one thing six months from now, remember this: buy for fit and adoption, not features, and choose for where the company is headed.
Nearly every regret in this decision begins with breaking that rule.
The fleet that chose the longest feature list and drowned in it. The fleet that bought too small and had to switch again a year later. The fleet that purchased a capable system its dispatchers never opened.
None of them bought a bad product. They bought the wrong fit.
You now have a way to avoid that outcome: a test for whether the operation is ready, a way to identify the correct software category, criteria that reflect how the business actually runs, a demo process that keeps the buyer in control, a realistic view of cost and implementation, and a scorecard that replaces instinct with evidence.
Run the process. Score the finalists. Trust the result, even when it points somewhere unexpected.
Choose once. Choose for fit. Do not make the same decision again next year.