The short answer

A TMS RFP should sort requirements into three tiers. Table stakes are the capabilities every serious vendor must have: order and load management, a dispatch board, a configurable driver app with electronic proof of delivery, telematics and ELD integration, rate management, billing, driver pay, document management, accounting integration, and enterprise security. Nice-to-haves extend the platform into adjacent work: customer portals, trailer and yard management, IFTA, maintenance, and fuel card data. Differentiators decide whether the system actually changes how your fleet operates: whether planning happens inside the TMS or around it, whether your operating rules are enforced on every assignment, whether billing and pay are calculated from the same load data, how integrations are built and maintained, and whether you can get your own data out.

Most RFPs spend the bulk of their line items on table stakes, where vendors look alike. The evaluation should spend most of its weight on the differentiators, because that is where fleets either transform their operation or pay to rebuild the one they already have.

This guide applies to both private fleets run by shippers and for-hire carriers. Where the criteria differ, we call it out.

Why most TMS RFPs miss the point

The typical TMS RFP starts with a requirements matrix built from the current system. Someone exports every screen, report, and workaround from the legacy TMS, turns each into a line item, and asks vendors to check yes or no. The result rewards vendors for matching the old system, including the parts of it that only existed to work around its limits. It can also lead fleets to overlook solutions with broader or more powerful applications.

An RFP should be driven by the fundamental problems the company is trying to solve. If you write an RFP for a horse carriage, you will buy a horse carriage. If you tell vendors you need to get from A to B faster, you might end up with a race car.

Two patterns show up in almost every fleet we talk to.

Workarounds become requirements. A fleet that re-keys load details into a payroll spreadsheet every week will often write "export to Excel" into the RFP, when the real requirement is that driver pay is calculated from the load data already in the system. Before you write a line item, ask whether it describes an outcome you want or a habit the old system forced on you.

Much of the work happens outside the TMS. Most fleets do a large share of their work in other tools, through other services, or in people's heads, then record the result in the TMS. The technology landscape keeps shifting, and work that once needed a separate tool or service can now be handled inside one platform.

Dispatch is the clearest example. Fleets say they dispatch in their TMS, but in most operations we see, the plan is built in Excel, on a whiteboard, or in a dispatcher's head and keyed in afterward. Research by Dr. John Carlsson, Chief Scientist at BeyondTrucks and Professor of Industrial and Systems Engineering at USC, found that the average dispatcher weighs at least 50 constraints when planning a load, based on 30 dispatcher interviews and 12 months of building optimization models. A TMS that cannot see those constraints cannot help with the decision.

The same is true of driver messaging, document imaging, and intermediaries such as EBE or Vector that move paperwork and data between drivers, offices, and customers. On a modern platform, many of those functions are part of the TMS itself, and the separate cost goes away.

The largest costs sit outside software altogether. Many fleets spend more than they need to on fuel, driver pay, and equipment. When the RFP defines the TMS's job as lowering those costs, or earning more revenue from the same trucks and drivers, software can be measured against the numbers that matter most.

So instead of asking only which features a TMS has, ask which problems it can solve that you are paying to solve somewhere else today.

A good RFP starts from the business: why the fleet exists, what service level it protects, and what it costs. Requirements follow from that.

Private fleet or for-hire: what changes in the criteria

Most of the requirements below apply to both. The difference is what the fleet is measured on, and that shifts where the weight goes.

Private fleets should also expect the RFP to answer a question the parent company will eventually ask: is running our own fleet still worth it? A TMS that produces trustworthy cost-per-load and service data is what lets the fleet answer that with evidence.

Table stakes: what every TMS on your shortlist must do

If a vendor cannot demonstrate these with your own data, remove them from the shortlist. Score these as pass or fail rather than on a scale; a vendor should not win the RFP because its invoicing screen is prettier.

One caution on table stakes: "we integrate with X" can mean anything from a live, maintained connector to a CSV file someone uploads weekly. Ask how each integration works, who maintains it, and what happens when the other system changes its API.

Nice-to-haves: valuable, but not where the decision is made

These extend the TMS into adjacent work. Whether each one matters depends on your freight and your existing systems. Score them on a simple scale, and do not let them outweigh the differentiators below.

A practical test: for each nice-to-have, ask whether it is included in the platform, sold as a separate module, or delivered by a partner. All three are legitimate, but they price and behave differently.

Differentiators: the questions that separate TMS vendors

This is where vendors stop looking alike. Each differentiator below includes a question to put in the RFP and what a strong answer looks like. Ask vendors to answer in a live demo with your data, not in a written response.

1. Where do dispatchers actually plan loads?

Many vendors now describe themselves as "AI-powered." The useful distinction is between a TMS where AI was added on top of a legacy data model and one that was built with planning and decisions at its core. In the first case, the optimizer sees only part of the picture, so dispatchers still plan by hand and type the result in. In the second, the system holds the drivers, equipment, orders, rules, and live status together and proposes assignments the dispatcher can accept, adjust, or override.

Ask: Walk us through how a dispatcher plans tomorrow's loads in your system, start to finish. Where does the plan get made, and what does the dispatcher do outside the TMS?

A strong answer: The plan is built and changed in the TMS. The system recommends driver, tractor, and trailer combinations; replans when a load cancels or a truck breaks down; and the dispatcher stays in control of the final decision.

2. Are your operating rules enforced on every assignment?

Every fleet has rules that decide which resource can haul which load: a driver's endorsements and customer site approvals, a trailer's last product and wash status, a kosher or food-grade designation, product compatibility, weight limits, and customer-specific requirements. In most systems these rules live in dispatchers' memories. When they are missed, the result is a rejected load, a contaminated trailer, or a safety incident.

Ask: How does your system know that a given trailer, tractor, or driver can or cannot be assigned to a given load? Can we configure our own rules without custom development?

A strong answer: A configurable rules or compatibility engine checks every assignment against your rules and flags or blocks conflicts before dispatch, not after delivery.

3. Does up-to-date compliance data reach the dispatcher at the moment of assignment?

Driver qualification and equipment inspection data often sit in separate compliance systems. The information exists, but it does not reach the person deciding who drives what.

Ask: If a driver's medical card has expired or a trailer is out of inspection, what does the dispatcher see when trying to assign them?

A strong answer: Non-compliant drivers and equipment are flagged on the dispatch board at the time of assignment, using data pulled from your compliance systems.

4. Are billing and driver pay calculated from the same load data?

What a fleet bills and what it pays drivers are often based on different things. A load may be billed per ton, per gallon, or at a flat rate, while the driver is paid by the mile, the hour, the load, or a percentage of revenue, with separate rules for owner-operators. Those rate structures should stay separate. The problem starts when the data behind them is captured twice: weights, miles, wait time, and accessorials entered once for the invoice and again for payroll, so the two drift and someone has to reconcile them.

Ask: Show us one load from dispatch through customer invoice and driver pay, including a detention charge and a weight correction. Where is each number calculated, and where does anyone re-enter data?

A strong answer: Billing and pay keep their own rate structures and bases, and both are calculated from the same load record. A correction to the load updates the invoice and the pay together, and you can see the margin on every load.

5. Does the system help your people make better decisions?

A fleet's results come down to thousands of small decisions every week: which driver and equipment take which load, in what sequence, where equipment gets staged, when and where to fuel or wash, which loads to accept, and how to respond when something goes wrong.

In trucking, the cost of a wrong decision is high. The wrong trailer can contaminate a product. A driver without the right qualification can create a safety and liability problem. A missed delivery can stop a customer's production line or a plant's shipments. A poor assignment can add empty miles, overtime, and wear on equipment that compound across a fleet. Even small improvements in decision quality add up quickly, which is why modern AI, optimization algorithms, and rule-based guardrails are valuable in a TMS to the extent they improve those decisions.

That value depends on the vendor knowing where AI is reliable and where it is not. AI does well with repeatable, data-rich decisions. It struggles where data is missing or late, where the knowledge lives in an experienced dispatcher's head, with true exceptions, and where a confident wrong answer is worse than no answer. A vendor that claims AI handles everything has not run it in a fleet.

Ask: Pick a decision our dispatchers or managers make every day and show us how your system improves it. Then tell us where your AI is likely to be wrong in our operation, how the system signals low confidence or missing data, and what the dispatcher sees when a recommendation should not be trusted.

A strong answer: Recommendations that show their reasoning and tradeoffs between cost, service, and compliance; a clear account of where the AI performs well and where it does not; hard rules that a recommendation cannot override; a person making the final call on exceptions; and results tracked against measures you care about, such as empty miles, loads per driver per day, equipment utilization, and on-time performance.

6. What is the architecture, and who carries the cost of change?

Architecture decides how much the TMS will cost to keep running over ten years. Legacy enterprise TMS platforms are often single-tenant or on-premise. Each customer runs its own version, upgrades are projects, and integrations are built one customer at a time, which makes them expensive and fragile. Multi-tenant cloud platforms run every customer on the same version, so an integration built and maintained once works for everyone.

Ask: Is your platform multi-tenant? How often do customers get new releases, and what does an upgrade cost us? When an integration partner changes its API, who fixes the connector?

A strong answer: One version for all customers, continuous releases at no extra cost, and integrations maintained by the vendor.

7. Can you get your own data out, fully, without asking?

Fleets increasingly want to run their own analytics in Power BI, Tableau, or internally built tools. Many TMS vendors limit access to canned reports and a narrow API, which makes the fleet dependent on the vendor for every new question.

Ask: How do we access all of our operational and financial data for our own reporting and tools? Is it included in the base price?

A strong answer: Read-only access to a full replica of your data, close to real time, included in every plan, plus documented APIs for writing data back.

8. How is each integration actually built?

Not all integrations are equal. Some are off the shelf. Some need field mapping to your setup. Some, especially ERP and EDI, need real integration engineering. A credible vendor will tell you which is which and price it accordingly.

Ask: For each system on our integration list, is the connector off the shelf, configured, or custom? What is the EDI approach for our trading partners, and how do you avoid disrupting our customers during cutover?

A strong answer: A clear tier for each integration, a named owner, and an EDI plan chosen for minimum disruption and cost, whether that means connecting directly, moving to a new EDI provider, or migrating from your current one.

9. Does the system capture why decisions were made?

Most systems record what happened: which driver took which load. Few record what the dispatcher knew at the time and why they chose that option. That context is what makes planning teachable to new dispatchers and what lets the system improve its recommendations over time.

Ask: When a dispatcher overrides a recommendation, what does the system record, and how is that used?

A strong answer: Overrides and their reasons are captured and used to refine rules and recommendations.

10. Does the vendor start with your process or with its software?

Implementation decides whether a new TMS transforms the operation or rebuilds the old one on a new screen. Vendors that lead with process analysis, mapping how work actually flows today and which steps exist only as workarounds, tend to deliver more change than vendors that lead with a configuration checklist.

Ask: Describe your discovery process before configuration begins. Who on your team does it, and what do we get at the end?

A strong answer: A documented current-state and future-state process map, agreed with your team before go-live planning, and a named lead who has run fleet operations.

How to weight the scorecard

Treat table stakes as a gate, then put most of the weight on what actually differs between vendors. A starting point you can adjust:

Private fleets often shift weight toward ERP integration and cost allocation. For-hire carriers often shift it toward billing and pay, EDI, and asset utilization. Either way, ownership stability deserves a direct question: several established TMS products have changed hands or come under strategic review, and a change of owner can change pricing, support, and roadmap.

How to run the evaluation

A requirements matrix alone will not separate vendors. These steps will.

1. Write down the business case first. One page on why the fleet exists, which customers or plants it serves, the service level it protects, and its current cost per load. Share it with every vendor. Vendors who do not ask about it are telling you how they will run the implementation.

2. Get senior operations in the room. RFPs run only by IT or procurement tend to measure features. Include the person who owns fleet performance and at least one experienced dispatcher.

3. Hold discovery before demos. Let shortlisted vendors spend time with your dispatchers, billing team, and drivers. Their questions will tell you how deeply they understand fleet operations.

4. Run a future-state exercise. After discovery, ask each finalist to describe what your fleet operation should look like in three years and in seven years: how planning, dispatch, compliance, billing, and reporting would work, which tools and manual steps go away, and what changes in cost, service, and loads per dispatcher. Then ask how their platform gets you there, phase by phase. A vendor that can describe its software but not your future operation is likely to configure your old process on a new system.

5. Run scripted demos on your own hardest week. Pick real loads with your toughest constraints: multi-stop runs, equipment restrictions, a late cancellation, a driver out sick. Give every vendor the same script and data.

6. Hold a separate integration session. Bring your IT lead and go system by system through ERP, telematics, accounting, EDI, and BI. Ask who builds and maintains each connector.

7. Call references that look like you. Same size, same type of freight, same kind of switch. Ask what the first 90 days looked like and what they would do differently.

8. Ask for a go-live plan before you sign. A credible vendor can show a dated plan with phases, owners, data migration, parallel running, and cutover criteria.

Frequently asked questions

What are the must-have features of a TMS? Order and load management, a live dispatch board, a configurable driver app with electronic proof of delivery, telematics and ELD integration, rate management, billing, driver pay and settlements, document management, accounting integration, reporting, and enterprise security. Most fleets also need EDI, whether with shipper customers or, for private fleets, with the parent company's systems.

What is the difference between an AI-native TMS and a TMS with AI features? A TMS with AI features adds tools on top of an existing system, so planning still happens largely outside it. An AI-native TMS is built so that the data model, the rules, and the decision engine work together, and the plan is made and changed inside the system.

Should a private fleet use the same TMS as a for-hire carrier? It can, if the TMS handles ERP-driven orders and internal cost allocation as well as customer billing. Many carrier-focused systems do not, so private fleets should test those workflows specifically.

How long should a TMS RFP take? Plan for discovery, scripted demos, an integration session, and reference calls. Allow enough time for each vendor to see your operation before demoing, and ask finalists for a dated go-live plan before you sign.

What is the biggest mistake fleets make when replacing a TMS? Rebuilding the old system's workarounds in the new one. Start from the outcomes the business needs, not from a list of screens in the current system.

About BeyondTrucks

BeyondTrucks builds an AI-native TMS for private and specialized enterprise fleets. We wrote this guide because we answer RFPs every month and see how much the structure of the RFP decides the outcome. If you are building yours and want to see how we answer the ten differentiator questions above, we are happy to walk through them with your data.