In brief
‘Transport management software’ and ‘TMS’ are not two categories separated by a regulation. They are commercial and functional terms that often overlap. That is why choosing based on the product name alone is not very useful.
For a small business, the most practical distinction is this:
- simple management software organises day-to-day internal work well;
- a more structured TMS tends to handle greater complexity in networks, carriers, rates, integrations, exceptions and cost control.
It is not a quality scale. A more complex system is not automatically better: it is better only if that complexity is needed.
There is no legal boundary between management software and TMS
No law states that software must have ‘10 functions’ to be called a TMS, or that management software cannot do planning. The term TMS describes a family of solutions, not a certification.
Consequently, an SME should put the commercial name aside for a few minutes and ask:
- which processes it covers;
- how well it covers them;
- what data it requires;
- how many people need to use it;
- how much it costs to implement and maintain;
- how easy it is to leave it and retrieve the data.
Practical comparison
| Area | Simple management software for a small fleet | Structured TMS |
|---|---|---|
| Customers and locations | Core | Core |
| Orders | Core | Core |
| Drivers and own vehicles | Often core | Depends on the target market |
| Daily plan | Core | Core, often more sophisticated |
| Driver app/communication | Possible | Possible/integrated |
| Third-party carriers | Limited or absent | Often advanced |
| Tenders/procurement | Rare | Common in enterprise systems |
| Complex rates | Basic or absent | Often advanced |
| Optimisation | Limited/optional | More common |
| Freight audit | Rare | Possible/advanced |
| ERP/WMS/EDI/API | Simple or selective | Often essential |
| Implementation | Days/weeks in simple cases | May require a dedicated project |
| Configuration | Limited | Often extensive |
| Training | Limited | More structured |
The table is indicative: each product must be checked individually.
The real dividing line: process complexity
The number of trucks matters, but it is not enough. Two businesses with ten vehicles each may have opposite needs.
Company A
- regular customers;
- relatively stable routes;
- own fleet;
- few office staff;
- orders received by email;
- main need: organise the order, truck, driver and changes.
Lightweight management software may be perfectly adequate.
Company B
- ten own vehicles but also 80 external carriers;
- hundreds of orders;
- different rates by area, weight and customer;
- EDI flows;
- customer portal;
- carrier invoice audits;
- contractual KPIs.
Here, the number of trucks no longer describes the complexity. A more structured TMS may be justified.
Five signs that simple management software is enough
1. The main problem is scattered information
If the real pain is copying orders from email into Excel and then calling drivers, the priority is to have a single source.
2. The fleet is mostly owned
There is no need for a carrier procurement engine if no procurement is carried out.
3. Planning is decided through the dispatcher’s experience
A good calendar and clean data can create more value than an optimisation engine that takes months to parameterise.
4. Few people work in the office
A system with dozens of roles, approvals and workflows can become an obstacle.
5. Few integrations are needed
If importing an Excel file, exporting data and connecting one or two services is enough, an enterprise architecture may be unnecessary.
Five signs that something more structured is needed
1. A lot of transport is bought from third parties
Carrier selection, commercial terms, performance and availability become core processes.
2. Rates can no longer be managed manually
Many combinations of area, weight, pallets, fuel, tolls and extras require structured rules.
3. The order must pass through several systems
ERP, WMS, EDI, customer portals, tracking platforms and administration require integration governance.
4. Errors have a systematic cost
Duplicate invoices, unexpected costs, SLAs, penalties and high volumes make automated control useful.
5. Management needs consolidated data
It is not enough to know ‘what the trucks are doing today’: costs, performance and capacity across complex networks need to be measured.
The cost is not just the fee: calculating TCO
To compare two solutions, it is useful to estimate the Total Cost of Ownership over at least three years.
Consider:
- user/vehicle/order licences;
- setup cost;
- data migration;
- training;
- consulting;
- API/EDI development;
- additional modules;
- premium support;
- costs for environments/testing;
- any devices;
- people’s internal time;
- maintenance of integrations;
- contractual price increases;
- the cost of exit/future migration.
Software costing 100 euros a month that requires 15.000 euros in customisation does not cost 100 euros a month. Conversely, slightly more expensive standard software may be less costly if it avoids a project and ongoing maintenance.
The risk of oversizing
Oversizing has concrete effects:
- more fields to complete;
- more training;
- processes adapted to the software rather than to the work;
- operators returning to Excel ‘to do it faster’;
- dependence on consultants;
- more difficult upgrades;
- disproportionate fixed costs.
A warning sign is when the company has to fill in information that nobody will use in order to manage an ordinary order.
The opposite risk: staying with fragile tools for too long
Undersizing also has a cost. If Excel has become the central system but:
- there are five versions of the file;
- changes and orders get lost;
- nobody knows who changed what;
- there are no roles/access rights;
- drivers receive data separately;
- the file is rebuilt after every error;
- the owner is the only person who ‘knows how it works’,
the cost does not show on an invoice, but it exists in hours, errors and dependence on people.
The move to management software should happen before the file becomes impossible to replace.
Example: 8 trucks versus a carrier network
Business with 8 own trucks
It receives 25 orders a day. Two people plan. The main problem is knowing, in a shared way, which driver will make which collection and communicating changes.
Priorities:
- structured order;
- daily plan;
- driver/vehicle master data;
- driver updates;
- history;
- export.
Simple management software can cover almost all the value needed.
Operator coordinating 120 carriers
It receives 800 orders a day, buys capacity on the market, uses several price lists, integrates ERP and WMS, and has to check invoices and SLAs.
Priorities:
- integration;
- procurement;
- rates;
- assignment;
- exceptions;
- tracking;
- cost audit;
- analytics.
Here, the TMS project is part of the company’s operational structure.
Decision matrix
Assign 0 to 2 points for each item:
| Question | 0 | 1 | 2 |
|---|---|---|---|
| How many systems need to integrate? | 0-1 | 2-3 | 4+ |
| How many third-party carriers do we manage? | almost none | some | many |
| Rate complexity | low | medium | high |
| Number of exceptions | low | medium | high |
| Procurement need | none | occasional | core |
| Cost audit | simple manual | partial | systematic |
| Workflows/approvals | almost none | some | many |
| Network | local/simple | national | complex multimodal/international |
The score does not produce a mathematical truth. It is meant to make the company describe its own complexity before looking at software.
Checklist
- Are we choosing based on the name ‘TMS’ or on processes?
- Which three problems need to be resolved within 90 days?
- How many people will actually use the system?
- How many integrations are essential?
- Do we mainly manage our own fleet or third-party carriers?
- Do we have complex rates?
- What does the project cost over three years, not just the fee?
- Can we start small and add modules?
- Can we export the data if we change supplier?
- Does the system require more discipline than the organisation can support today?