What is a Transport Management System?
A TMS is a category of software used to plan, execute and control the movement of goods. It may connect transport orders, routes, resources, documents and financial data, but exact coverage differs by product and configuration.
That variation matters when comparing suppliers. Oracle’s overview of the category describes standalone, integrated and suite-based offerings and notes that execution capabilities vary widely. The TMS label alone does not prove that a product fits your operation.
When is a TMS worth evaluating?
There is no universal truck, job or user count at which a TMS becomes mandatory. Inspect the process instead:
- the same information is entered in several places;
- job status depends on calls and manual synchronization;
- documents and billing are reconstructed from different sources;
- cost or margin arrives after the decision point;
- handover depends on one person’s private explanations.
These signals do not make a purchase inevitable. They justify measurement and evaluation. The TMS vs Excel guide for transport companies shows how to test whether the problem lies in the tool or in the way work is governed.
How do you choose a TMS? Seven selection criteria
The seven criteria below turn a feature list into a comparable evaluation. Start with written requirements and results that can pass or fail. ISO/IEC 25010:2023 provides a general model for specifying and evaluating software-product quality, while ISO/IEC 25040:2024 provides a general evaluation framework. The criteria and tests below are a practical transport-operations method, not a reproduction of either ISO standard.
1. Workflow and exception fit
A carrier operating its own fleet and a freight forwarder should not run the same script. The carrier tests vehicle and driver assignment. The forwarder tests subcontracted partners and the separation of buy-side cost from sell-side revenue. A commercial dossier or transport file must remain distinct from the transport order or job being executed.
Question: can the system carry your flow from request to documents and billing when the vehicle, driver, partner, date or location changes?
Evidence: a scenario written by your team and executed with your roles and exceptions.
Rejection signal: the demonstration avoids the exception, changes the required process or moves the result into an unexplained manual file.
2. Data, migration and quality
Before requesting a proposal, inventory the data to be moved: customers and suppliers, contacts, locations, vehicles, drivers, rates, open jobs, documents and history. For each set, name the source, owner, format, validation rules and post-import reconciliation. The fleet record-keeping guide can help prepare vehicle and document data.
Question: who cleans, transforms, imports and validates each dataset?
Evidence: field mapping, rules for duplicates and missing values, a test import and a reconciliation report between source and destination.
Rejection signal: “migration included” without an accepted format, volume, owner, error treatment and acceptance condition.
3. Integrations and failure ownership
“An API is available” does not define an integration. For every link to ERP, accounting, telematics, a customer platform or another service, record the source, destination, direction, frequency, authentication, fields, errors, retries, monitoring, cost and owner of the fix.
Question: what happens when the source responds late, sends an invalid value or becomes unavailable?
Evidence: applicable technical documentation, one successful test transfer and one controlled failure, the operator-visible error and a named owner.
Rejection signal: the integration depends on future development but has no scope, cost, deadline, owner or failure behavior.
4. Security, privacy and resilience
The evidence should be proportional to the impact of data leakage, corruption or service unavailability. The NCSC guidance for choosing a cloud provider recommends testing supplier assertions, the scope and freshness of certifications, shared responsibilities and measurable commitments. It is a cloud due-diligence reference, not a statement of Romanian or EU law.
Question: how are identity, roles, administrative access, audit information, vulnerabilities, incidents, backups and restoration controlled?
Evidence: architecture and security documentation, current subprocessor information, scope and date of independent assurance, incident handling and evidence from the latest restoration or recovery exercise. The buyer’s legal, privacy and security owners should review the proposed data, support and resilience terms.
Rejection signal: a certification logo without scope or date, backup promises without restoration evidence, or unclear responsibility between supplier and customer.
5. Usability, adoption and support
A polished screen does not prove that dispatchers, operators, billing staff and managers can finish their work. Include representative users and their real tasks, including role administration, data correction and shift handover.
Question: can users finish important tasks without the demonstrator doing the work for them?
Evidence: representative users execute the scenarios, while the supplier defines configuration, training, administration, support hours, escalation and later changes.
Rejection signal: success depends on a consultant performing the workflow, while the buyer’s administration effort remains unknown.
6. Export, portability and exit
Do not ask only whether an export exists. Request a representative set: master data, open work, history and documents. Check the format, readability, identifiers, relationships, missing fields, elapsed time and what happens to data and copies after the service ends.
Question: can the team recover its information in a form it can understand and use outside the product?
Evidence: an executed and inspected export where available before signing. When it is not available, require a measurable result, remediation period and clear termination and transition rights in the proposed terms, then repeat the test during the acceptance window before migration becomes difficult to reverse.
Rejection signal: “export on request” without content, format, time, cost, owner and treatment of documents or history.
7. Full cost and objective acceptance
Compare the same period and scope. Include configuration, migration, integrations, training, licences, support, administration, changes, contract costs and residual manual work. Do not convert freed capacity automatically into cash savings or use a market ROI in place of your own evidence.
Question: what does each party pay for and deliver before, during and after launch?
Evidence: the final proposal, order form, SLA and proposed schedules define inclusions, exclusions, owners, acceptance, remediation, support, term changes and exit. Before signing, verify that the final agreed contractual documents retain the evaluated conditions and have the relevant terms reviewed by the buyer’s legal, privacy and security owners.
Rejection signal: the licence price is clear, but migration, integration, support, acceptance or residual work has no boundary and owner.
What evidence should you require?
For workflows, integrations and portability, this practical scale can help. It is not a standard and does not apply to security, resilience or contracts.
| Level | What you received | How to interpret it |
|---|---|---|
| W0 | no answer | the requirement cannot be evaluated |
| W1 | assertion, slide or checkmark | declared but unverified capability |
| W2 | standard flow demonstrated with applicable documentation | evidence for the standard case, with stated limits |
| W3 | the buyer’s representative scenario using synthetic or effectively anonymised data, with result, deviation, limits and owner | direct evidence for the evaluated case |
Other claims need different evidence:
| Claim | Appropriate evidence |
|---|---|
| Security and privacy | architecture, processes, subprocessors, current and applicable independent assurance, proposed terms |
| Resilience | declared objectives, backup scope, restoration or recovery exercises, incident communication |
| Cost and contract | final proposal and schedules, inclusions, exclusions, owners and measurable acceptance and exit conditions |
Record mandatory requirements separately. A failed essential flow, an integration with no owner, an unacceptable security risk, an unusable export or an unbounded cost must not disappear inside a good average score. You may weight non-mandatory criteria, but the weights and thresholds should come from your operation.
Which scenarios should a supplier run?
Use synthetic or effectively anonymised representative data by default. Remove identifiable driver, contact and customer data and commercial secrets. If sensitive real data is necessary, involve the buyer’s legal, privacy and security owners before transfer and establish purpose, access, retention, deletion and applicable obligations.
| Scenario | What it should demonstrate |
|---|---|
| Carrier, normal flow | request or transport order, operating record, vehicle and driver plan, status, document and billing or reporting handoff |
| Freight forwarder, normal flow | dossier or transport file kept distinct from the transport order, subcontracted partner, buy/sell separation, partner documents and client/supplier billing handoffs |
| Owned-fleet exception | late vehicle, driver, date or location change without losing current state, history, permissions or downstream consistency |
| Subcontracted exception | partner or term change while retaining correct responsibilities, documents and commercial values |
| Exit and portability | representative export of master data, open work, history and documents with usable relationships and identifiers |
Record the result rather than the intention:
| Criterion or mandatory gate | Input and expected result | Actual result and deviation | Evidence and owners | Residual work | Verdict |
|---|---|---|---|---|---|
| example: vehicle change | job remains consistent after reassignment | completed during evaluation | capture, audit information; supplier + dispatcher | record it | pass / fail |
Do not assume every supplier offers a pre-contract pilot. Use the strongest available validation: scripted demo, sandbox, UAT, limited pilot, references and documentation. If an important test cannot run beforehand, require measurable acceptance, remediation, termination and transition in the proposed terms and execute the test before migration becomes difficult to reverse.
Five traps when choosing a TMS
- Buying the longest feature list. Correction: tie every requirement to a workflow, evidence and owner.
- Accepting the happy-path demonstration. Correction: the supplier runs exceptions written by your team, not only presentation-ready data.
- Treating “API available” as a complete integration. Correction: verify direction, fields, errors, retries, monitoring, cost and responsibility.
- Comparing only the licence. Correction: include migration, configuration, training, integrations, support, administration and residual manual work.
- Signing before defining acceptance and exit. Correction: run the available tests and put outcomes, remediation, termination and transition into measurable terms.
How do you make the final decision?
- Remove solutions that fail a mandatory requirement.
- Compare the actual evidence for each criterion, not the impression left by a presentation.
- If you use weights, document why they reflect your operation.
- Record residual manual work, limits and the owner of each risk.
- Select the strongest documented case and retain acceptance, remediation and exit conditions in the final documents.
The right system is not the one that promises the most features. It is the one that proves the essential workflows and has operating, technical and commercial boundaries your company can accept. To apply the method to three concrete options, read the Routena vs fireTMS vs Excel comparison.
