Where digitising a freight forwarder actually starts

When a freight forwarder decides to "sort the systems out", the first move is almost always the wrong one: looking for a tool. Demos get booked, prices compared, colleagues asked what they use.

The advice you find while searching sounds much the same — "define your goals", "map your processes", "involve the team". All of it true. None of it tells you what to do on Monday.

This is about what actually decides whether the project works. It shows up early, and it is almost never the technology.

Where does digitisation actually start?

Short answer: not with choosing a tool, but with deciding where the truth lives.

In most forwarding companies, the answer to "what is the status of this shipment" depends on who you ask. The manager knows one thing, the spreadsheet says another, the client was told a third. Nobody is wrong — there is simply no single place that is correct by definition.

Until that is settled, any system will only add a fourth version. So the first real step is not software. It is an agreement: which record wins when they disagree.

Which data will you need — and why is it usually missing?

Short answer: the same data you already have, in a consistent shape. The shape is what is missing.

In practice the same four gaps repeat almost everywhere:

• Clients and carriers are recorded inconsistently. The same company appears under three spellings, and only someone who has worked there for years can reconcile them.
• Pricing rules live in people's heads. Surcharges, exceptions and "we calculate differently for this client" are nowhere written down; they are passed on verbally.
• Documents sit in email. Contracts, CMRs and invoices are available, but not attached to a specific order in a way anyone else could find.
• Statuses are undefined. Everyone uses the same words while meaning different things by "loaded" or "closed".

None of these is a technical problem. Every one is an agreement problem — which is why no tool solves them, and why leaving them unsolved stalls any implementation.

What has to be decided before choosing a tool?

Short answer: three things — who owns each process, what a correct record looks like, and what you will not do.

The third matters most and is skipped most often. Projects expand not because something is missing but because everything is attempted at once. What actually works is starting with one process that repeats daily and where mistakes cost money — usually the order lifecycle from enquiry to invoice.

Everything else waits. Not because it does not matter, but because until the first process works end to end, the second one only doubles the unfinished work.

Why do projects stall on something other than technology?

Short answer: because implementing a system reveals that the process you meant to automate never existed — it was a habit.

That is not a criticism. Habits work while the company is small and the same people are doing the job. The problem appears when the habit has to be written down precisely enough for a system, or a new hire, to carry it out. That is the moment it becomes clear the decision was made slightly differently each time.

So the most useful early work is descriptive, not technical: write down how decisions are actually made, not how they ought to be. The gap between those two lists is the real scope of the project.

What should you actually do in the first week?

Short answer: buy nothing.

The sequence we recommend:

1. Log the interruptions for one week. Every time someone asks "where is this shipment" or data gets entered twice, write it down. By Friday you have a real list rather than an opinion.
2. Lay out the order journey. From enquiry to paid invoice, with every step a person touches.
3. Mark where the truth diverges. Those points are your project.
4. Only then talk about tools — holding a list, not a question.

The first three steps cost nothing but attention, and they determine more than any tool choice will.

Off-the-shelf or your own?

Short answer: starting off-the-shelf is usually right — the question is how long it will fit.

We covered that separately in when an off-the-shelf TMS stops fitting a freight forwarder. And if everything currently runs on spreadsheets, the threshold is described here: when to move from spreadsheets to one system.

What such a system looks like in practice is shown in our client's case: the AgoAuto case study.

Once you have the list, the next question is which of those processes are worth automating at all. The signs are set out here: which processes are worth automating — and which are not.

If you would like the first three steps done alongside you — get in touch. We start with your process, not with a tool.