In this article
Why TMS implementations fail
Transport management system projects go wrong in the same ways, again and again. The vendor demo looked exactly right. The price was manageable. Three months after go-live, the planning team is working around the system rather than in it, the customer portal is not being used, and the promised efficiency gains are nowhere to be seen.
The root causes are almost always the same: the requirements were not properly defined before the selection, the contract did not protect the business against the most common implementation risks, and nobody with independent authority was watching the project during delivery.
The logistics sector is particularly exposed to this because the businesses making these decisions are run by people who are excellent operators - they know their routes, their margins, their drivers - but who have not bought an enterprise software system before and are negotiating against vendors who do it every day.
"The vendor knows their contract better than you do. They have signed hundreds of them. You are signing your first one. That asymmetry needs to be corrected before you sign anything."
Before you look at any system
The most common mistake is starting with the shortlist. By the time you have been to three vendor demos, you are already being sold to - and your view of what you need has been shaped by what the vendors have shown you rather than by what your operations actually require.
Before any vendor conversation, work through these questions honestly:
- What problem are you actually trying to solve? Planning efficiency, driver utilisation, customer visibility, invoicing accuracy, compliance? Be specific. A TMS that is excellent at route optimisation is not necessarily excellent at customer portal integration.
- What does your current process look like? Map it. Where are the manual steps, the errors, the delays? The new system needs to address those specific points - not a generic version of your operation.
- What data will the system need? Customer data, job data, vehicle data, driver data. Where does it currently live, how clean is it, and who owns it? Data migration is routinely the most underestimated part of a TMS project.
- Who will own this internally? A TMS implementation without a named internal owner with authority to make decisions will drift. Someone needs to be accountable for the project alongside their day job, or the project needs dedicated resource.
The main systems in the UK market
The UK haulage and logistics TMS market has several established players, each with different strengths. This is not a comprehensive review - requirements vary significantly - but it gives a starting framework.
Mandata
UK-focused, strong in general haulage. Good planning tools and driver communication. Well-established in the mid-market. Strong support network.
Paragon
Route optimisation strength. Better suited to high-volume, multi-drop operations. Strong analytics. More complex to implement than some alternatives.
Microlise
Strong telematics integration alongside TMS functionality. Good for businesses where vehicle tracking and driver behaviour are central requirements.
Freight Software / Haulage Expert
Entry to mid-level. More accessible for smaller operators. Less feature-rich but quicker to implement and easier to manage with a smaller team.
The right system depends entirely on your operation - fleet size, job type, customer requirements, integration needs, and internal IT capability. A system that works well for a 30-vehicle general haulier may not be the right choice for a 150-vehicle temperature-controlled operation with complex customer portal requirements.
How to run a selection process
A well-run TMS selection takes eight to twelve weeks from requirements definition to contract signature. Compressed timelines produce bad decisions.
Step 1: Write a requirements document before talking to vendors
This does not need to be a 50-page specification. It needs to cover: the core planning and dispatch workflow, integration requirements (accounts, telematics, customer portals), reporting needs, user numbers and access levels, and data migration requirements. Two to three pages of honest operational description is more useful than a generic RFQ template downloaded from the internet.
Step 2: Run a structured demo against your requirements
Give each vendor your requirements document before the demo and ask them to demonstrate specifically how their system handles each point. A vendor who redirects to their standard demo despite having your requirements is telling you something.
Run the demo with the people who will actually use the system - the planners, the drivers' manager, the accounts team - not just the IT director and the MD. The people who will live in the system every day will identify gaps that senior management will miss.
Step 3: Reference check with comparable operations
Ask for references from businesses with a similar fleet size, job type, and integration requirement to yours. Call them. Ask specifically: what went wrong during implementation, what took longer than expected, and what would you do differently.
Step 4: Scope the implementation in writing before signing
The contract covers the licence. The implementation scope is often a separate statement of work, and it is in that document where the risks hide. Make sure data migration, training, integration development, and post-go-live support are all explicitly scoped, costed, and agreed in writing before you sign anything.
Contract traps to watch for
Go-live date without a definition of "go-live". Some vendors define go-live as the system being technically available, not as your operation being running on it. Make sure the contract defines go-live as the point at which your business is operationally live on the system, not the point at which the vendor has done their part.
Data migration as a separate commercial item. Data migration is frequently scoped out of the core contract and priced separately as a change request once the project has started. Agree the data migration scope and cost in the original contract.
Automatic renewal clauses. Many TMS contracts auto-renew for 12 months unless notice is given 90 days before the renewal date. Make a diary note on day one.
Support SLAs that do not reflect operational reality. A four-hour response time for a critical system failure sounds acceptable until you are standing in the yard at 4am with 40 jobs that cannot be dispatched. Understand what the SLA actually means and whether it works for your operational hours.
Go-live and the first 90 days
Go-live day is not the end of the project. It is the most operationally demanding part of it. Your team is learning a new system while still running the business. Customers still need their deliveries. Drivers still need their jobs.
The businesses that get through go-live well are the ones that planned for it. That means running parallel operations for at least one to two weeks before cutting over fully, having vendor support on-site or on-call for the first week, and having clear escalation routes when something does not work.
The first 90 days after go-live are where adoption either takes hold or where the workarounds start. If your planners are still using the spreadsheet alongside the TMS six weeks after go-live, that is not a user training problem - it is a system configuration or usability problem that needs to be resolved before it becomes permanent.
When to bring in independent oversight
For most haulage businesses, a TMS project is the largest technology investment they will make in a decade. The total cost - licence, implementation, data migration, training, internal resource - is typically £80k to £300k depending on scale. Getting it wrong means repeating that cost within three years.
Independent project oversight - someone who is not the vendor and has no stake in the sale - makes sense when the project is above a certain scale or when the internal team does not have experience managing enterprise software implementations. That person reviews the vendor's implementation plan, challenges assumptions, flags risks before they become problems, and provides the business with an honest view of whether the project is on track.
It does not need to be expensive or full-time. A two to three day diagnostic at the requirements stage and periodic reviews during implementation is often enough to prevent the most common failures.
Looking at a TMS and want an independent view?
We advise logistics and haulage businesses on system selection and implementation oversight. No vendor relationships. Plain English.