The best TMS projects start smaller than you think

There's a well-worn way of introducing transport software, and it goes something like this: You begin with a requirements workshop. Every department describes how they work. A specification document grows to eighty pages. The vendor configures the system to match it. Six or nine months later, everything goes live at once. And then you discover which of those eighty pages described how you actually work, and which described how someone thought you worked, or wished you worked, or used to work in 2019.

This approach has an intuitive logic — get it right before you go live — but it inverts the actual risk. It maximises the time before you learn anything, and it concentrates all the learning into the most stressful possible moment. There's a better way, and it's not complicated: go live with a working core, then customise based on what running it teaches you.

Why starting small works better

Three reasons, in order of importance:

You learn from operation, not from workshops. A dispatcher describing their process in a meeting room gives you an idealised, tidied-up version — not because they're being dishonest, but because that's how memory works. The same dispatcher using the system for two weeks will tell you precisely what's wrong with it, in specific and actionable terms. Real usage is a far better requirements-gathering instrument than any workshop.

Value starts earlier. A system that goes live in month three and covers 70% of your operation delivers more value over a year than one that goes live in month nine covering 95%. The gap compounds — and the earlier system has six extra months of learning behind it.

The organisation absorbs change better in doses. Asking an operation to adopt a new way of working across every process simultaneously is asking a lot, especially of the people who also have to run the business that day. Sequenced change, where each step is small enough to be comfortable, gets adopted. Big-bang change gets worked around.

What "start small" actually means

It doesn't mean starting with a stripped-down system. It means starting with sensible defaults instead of custom configuration.

A transport management system contains a large number of decisions: how master data is structured, how orders are defined, how exceptions are being handled, what the driver sees, which documents get generated when, how customers are notified, etc. Every one of those can be tailored to your operation. Some of them don't have to be at the start.

We ship X4fleet with defaults drawn from a lot of transport operations. They're not arbitrary — they represent how the majority of transport operators work, and for a substantial share of your processes they'll simply be right. Starting there means you can be productive quickly and spend your configuration effort where it actually differentiates you.

The rule of thumb we use: customise where it's a competitive difference, take the default where it's just a habit. The distinction is often clear once you ask the question. Your specific handling of construction site time windows might be genuinely differentiating. The exact colour-coding of your tour board probably isn't — and if it turns out to matter after three months of use, you can change it then, knowing why.

A workable sequence

Every operation differs, but a phased introduction usually follows something like this shape.

Phase 1 — The core, live. Master data (customers, locations, vehicles, drivers, products, etc.), order entry, tour planning, and the driver app. Defaults wherever possible. This is enough to run real transports and to replace the whiteboard or the spreadsheet. Target: weeks, not quarters.

Phase 2 — Connect the neighbours. Interfaces to the systems around the TMS: ERP and accounting, telematics, customer portals, EDI links to regular clients. Deliberately later, because integrations are easier to specify once you know how the TMS is actually being used — and because premature integration hardwires processes you may still want to change.

Phase 3 — Close the loops. Digital proof of delivery, status feedback into the office, customer notifications. This is where the documentation and communication savings start showing up, and where the operation begins to feel different rather than just look different.

Phase 4 — Optimise and specialise. Route optimisation tuned to your constraints, automated planning rules, industry-specific handling, reporting built around the questions you actually ask. This is where the configuration effort pays off, and where you now have the operational experience to direct it well.

Each phase produces a working system. Nothing is left half-built waiting for a later step.

The part where projects get stuck

Two warnings, because a guide that only describes the sunny path isn't much use.

Master data quality is the real project risk. Not the software, not the interfaces — the addresses, the customer records, the vehicle specifications. Operations routinely underestimate how much cleanup this needs, and every downstream feature depends on it. Route optimisation with imprecise geocoding produces plans that don't survive contact with reality. Start this work before you think you need to.

"We'll customise it later" needs to be an actual plan. Starting with defaults only works if there's a scheduled review to revisit them. Without that, "we'll adjust it once we've used it" becomes "we never got round to it", and three years later people are working around a default that stopped fitting in month four. Put the review in the calendar at go-live.

You shouldn't do this alone

One thing that doesn't scale down: experience with what goes wrong.

The sequencing decisions in a TMS introduction — what to include in phase one, which defaults to keep, when master data is clean enough, whether an integration should come before or after go-live — are judgement calls, and they're much easier to make if you've watched them play out before. That's the part our implementation team brings. Not just configuring the system, but pushing back when a scope decision looks like it'll create trouble in month six. We stay involved after go-live for the same reason.

‍

Thinking about how a TMS introduction would look in your operation? Let's talk it through.