The demo is not the decision
Most TMS decisions get made in a conference room during a polished ninety-minute demo. The sales engineer clicks through a perfect load: clean customer, clean lane, one stop, no accessorials, invoice prints, everyone nods. Six months after go-live, the dispatch floor is fighting the system on multi-stop loads, billing is rekeying detention by hand, and payroll is running a spreadsheet next to the settlement module.
That gap is not usually because the software is bad. It is because nobody tested it against the way your company actually moves freight. A TMS is the system of record for orders, dispatch, rating, invoicing, driver pay and much of your safety and fuel data. Picking one is closer to choosing a business partner than buying a tool, and the selling process is built to make it feel simpler than it is.
This guide walks through a selection process we have seen work for truckload and LTL carriers, brokerage operations, drayage outfits and private fleets. It is written for the owner, CFO, operations manager or IT lead who will live with the result.
Step 1: Write requirements from your operation, not their brochure
Vendors will happily hand you a requirements template. It will list every feature they have and, quietly, few of the ones they don't. Start instead from your own work.
Walk the floor
Sit with each role for a few hours: customer service and order entry, dispatch and planning, brokerage reps if you have them, billing, AR, payroll and settlements, safety and compliance, maintenance, and the people who pull reports for leadership. Watch what they actually do. Write down every spreadsheet, sticky note, side database and manual rekey. Those workarounds are your real requirements, because they mark the places your current system fails.
Separate must-haves from preferences
Sort every requirement into three buckets:
- Must have. The business cannot run without it. Examples: rating your customers' actual tariff structures, fuel surcharge tables tied to the weekly DOE diesel index, the driver pay methods you use today, the EDI transactions your largest shippers require, IFTA mileage by jurisdiction.
- Should have. Meaningful value, but you could work around it for a while. Examples: a customer portal, automated detention billing, document imaging tied to the invoice.
- Nice to have. Useful, but not worth paying a premium or delaying go-live for.
Be ruthless. A list with two hundred must-haves is a list with no priorities. Twenty to forty true must-haves is typical for a mid-sized carrier.
Requirements checklist by area
| Area | Questions to answer before you talk to vendors |
|---|---|
| Order entry & rating | How are your contract rates structured (per mile, flat, CWT, zone, pallet)? Minimums? Multiple tariffs per customer? How is FSC calculated? |
| Dispatch & planning | Multi-stop, relays, power-only, team drivers, LTL consolidation, drop-and-hook, split loads? How do you track HOS and ELD positions? |
| Brokerage | Carrier onboarding and compliance checks, rate confirmations, carrier pay, margin per load? |
| Billing & AR | Accessorial approvals, detention rules, consolidated invoices, EDI 210, document requirements, AR aging and collections? |
| Settlements & payroll | Mileage pay (loaded and empty), percentage pay, hourly, stop pay, owner-operator deductions, escrow, fuel advances? |
| Safety, fuel & maintenance | IFTA, fuel card imports, DVIR, inspections, driver qualification files, PM schedules? |
| Integrations | Accounting package, ELD/telematics, fuel cards, mileage software, imaging, EDI trading partners, load boards? |
| Reporting | Which ten reports does leadership actually read? Who writes new ones, and can you query the database directly? |
Step 2: Build a weighted scoring matrix before the first demo
Decide how you will score vendors before you see any of them. Otherwise the scoring bends toward whichever demo felt best. A simple weighted matrix works well:
- Group requirements into six to ten categories.
- Assign each category a weight that adds to 100, based on business impact.
- Score each vendor 0 to 5 per category, using written evidence from the scripted demo and references.
- Multiply score by weight and total it.
Here is an illustrative example. The weights are placeholders; yours should reflect your operation.
| Category | Weight | Scoring guide (0 to 5) |
|---|---|---|
| Rating, FSC & billing fit | 20 | 5 = rated your real tariffs and accessorials in the demo with no workarounds |
| Dispatch & planning fit | 20 | 5 = handled your hardest load types live, on your data |
| Settlements & payroll | 15 | 5 = produced a correct settlement for your most complex pay setup |
| Integrations & EDI | 15 | 5 = existing, in-production connections to your ELD, accounting and key trading partners |
| Reporting & data access | 10 | 5 = direct, documented data access plus a usable report writer |
| Implementation & support | 10 | 5 = named team, realistic plan, references confirm support quality |
| Vendor viability & contract | 10 | 5 = stable company, fair terms, clean data exit |
Two rules make the matrix honest. First, any must-have that fails is a knockout, regardless of total score. Second, have at least three people score independently and compare before discussing. If dispatch and billing score a vendor very differently, find out why.
Step 3: Run scripted demos on your own data
This is the single most valuable step, and the one most often skipped. A scripted demo means you hand each finalist the same set of real scenarios ahead of time, along with sample data, and they show you how their system handles each one.
What to send the vendor
- Five to ten real customers, with their actual rate structures and accessorial rules (anonymize names if you prefer).
- A week of real loads: simple ones, plus your multi-stop, team, relay, LTL or drayage moves.
- Your current fuel surcharge table and the method you use to apply it.
- Two or three driver pay setups, including your most complicated owner-operator settlement.
- One messy real-world exception: a load that changed after dispatch, a TONU, a rejected delivery, a rebill.
A demo script that exposes fit
- Enter and rate an order for a contract customer with fuel surcharge and two accessorials. Show the rate audit trail.
- Dispatch a multi-stop load with a driver whose hours are tight. Show how HOS and current position appear.
- Change the load after dispatch: add a stop, change the consignee. Show what happens to the rate, the driver and the customer notification.
- Deliver with detention. Show how arrival and departure times are captured and how detention reaches the invoice.
- Invoice it, including required documents, and send it the way that customer requires (paper, email, portal or EDI 210).
- Settle the driver for the week, including a deduction and a fuel advance. Print the statement.
- Post to accounting and show the journal entries.
- Pull a report: revenue per mile by customer for last month, built live, not pre-loaded.
Score each step during the demo while it is fresh. Note every time the presenter says "we'd configure that," "that's on the roadmap" or "a lot of customers handle that with a custom report." Those phrases are not disqualifying, but each one is a cost, a delay or a risk you should price.
Watch the clicks, not the slides
Ask the dispatcher and the billing lead who will use the system every day to sit in the front row. Their read on how many screens and clicks it takes to do routine work is worth more than any feature list.
Step 4: Check references the vendor didn't hand-pick
Every vendor has three happy customers on speed dial. Talk to them, but also ask for companies that look like you: similar size, similar freight, similar integrations, and ideally one that went live in the last eighteen months. Industry peers, trade associations and user groups are good places to find users the vendor did not suggest.
Questions that get past the polite answers:
- How long did implementation actually take versus the original plan, and why?
- What did you have to change in your process to fit the software?
- What is still being done in spreadsheets?
- When something breaks on a Friday night, who answers and how fast?
- How have renewal prices and add-on fees changed since you signed?
- Have you ever needed to pull your own data out in bulk? How did that go?
- If you were starting over, would you choose the same system?
Step 5: Contract and data ownership questions
The contract is where a good selection is protected or quietly undone. Have your attorney review it, and make sure the business side asks these questions before signing:
Your data
- Does the agreement state clearly that your operational and financial data belongs to you?
- Can you export all of it, at any time, in a documented, usable format, not just PDFs or screen reports?
- If you leave, what termination assistance is included, for how long, and at what cost?
- For hosted systems: where is data stored, how often is it backed up, and can you get a copy of your database?
- Is direct read access for reporting allowed, or only through paid APIs?
Money and terms
- Is pricing per user, per truck, per load or a flat subscription? What happens as you grow or shrink?
- What is the renewal escalator, and is it capped?
- Which items are billed separately: EDI partner setups, per-transaction fees, integrations, API calls, document storage, extra environments, premium support?
- Who pays if implementation runs over because of the vendor's delays?
- What uptime and support response commitments exist, and what remedy applies if they are missed?
Step 6: Calculate total cost, not license price
The quote is never the full cost. Build a five-year view that compares each finalist, and include the cost of staying where you are as a baseline.
| Cost bucket | What to include |
|---|---|
| Software | Licenses or subscription, modules, user or truck growth, renewal escalators |
| Implementation | Vendor services, configuration, data conversion, custom reports and forms, travel |
| Integrations | ELD, accounting, fuel card, mileage, imaging, EDI partner onboarding, ongoing per-transaction fees |
| Infrastructure | Hosting or servers, databases, backups, networking, security tools |
| Your people | Staff time for requirements, testing, training and go-live; temporary help or overtime |
| Transition risk | A realistic allowance for slower billing and dispatch during the first weeks |
| Ongoing | Support, administration, upgrades, new reports, retraining for turnover |
Internal staff time is the line most often left out, and it is frequently one of the largest. Billing and dispatch leads will spend real hours on testing and training, and someone has to cover their desks.
Red flags checklist
- The vendor won't run your script or use your data.
- Critical must-haves are "on the roadmap" with no committed date.
- The implementation plan has no named people or a suspiciously short timeline.
- References are all from companies very different from yours.
- The contract is vague about data export or termination assistance.
- Every integration you need is described as "possible" rather than in production elsewhere.
- Pressure to sign by month-end or quarter-end in exchange for a discount.
When the decision is close, the tiebreaker should be implementation and support quality, not features. A slightly weaker system implemented well beats a stronger system implemented poorly. Our TMS go-live checklist covers what comes after the signature.
How Strong Tower Consulting helps
Strong Tower Consulting runs vendor-neutral TMS selections for carriers, brokers and private fleets. We document requirements by walking your floor, build the scoring matrix with your team, write the demo scripts, prepare your sample data, sit in every demo, run independent reference checks and review the commercial terms with your attorney. Since 2008 we have worked inside these systems at the database, in the dispatch office and on go-live week, so we know which questions expose real fit.
- TMS Selection & Advisory: requirements, scripted demos, scoring and negotiation support.
- Business Analysis: process mapping and requirements documentation.
- TMS Implementation & Go-Live: conversion, testing, training and on-site go-live support once you choose.
- Legacy TMS Advisory & Migration: an honest look at whether you should replace at all.
Independent by design
Strong Tower Consulting never requires you to buy our software. Our sister company, Exspeedite, builds a TMS, and we disclose that relationship up front. If another product fits your operation better, or if your current system can do the job with some cleanup, we will tell you. See how we work.
Frequently asked questions
How long should a TMS selection take?
For most small and mid-sized carriers, a disciplined selection runs roughly two to four months: a few weeks for requirements, a few weeks for a short list and scripted demos, then reference checks and contract negotiation. Rushing the requirements step is the most common reason selections go wrong.
How many vendors should we demo?
Screen widely on paper, then bring three, or at most four, vendors to full scripted demos. More than that and your team stops comparing carefully and starts remembering whoever presented last.
Should we let the vendor run their standard demo?
Let them do a short overview if they insist, but the demo that counts should follow your script, using your own customers, lanes, rates and loads. A standard demo shows what the vendor does well. A scripted demo shows whether it fits how you move freight.
What contract terms matter most in a TMS agreement?
Data ownership and export rights, termination assistance, renewal price caps, what is included versus billed separately (EDI partners, integrations, API access, storage, support tiers), uptime and support commitments for hosted systems, and who pays for implementation overruns.
Does Strong Tower Consulting require us to buy Exspeedite software?
No. Strong Tower Consulting is independent advisory. Our consulting never requires buying our sister company's software, and if another product is the better fit for your operation, we will tell you.