Strategy& and BVL surveyed 115 logistics providers in November 2025. 96 percent have started digitalization. 10 percent scale. A third fails on staff reservations, half on missing priorities.
The study names reasons. I name the three mistakes in which those reasons become concrete in a project, the way we see them at forwarders. And how to spot them in week 2, while there is still time.
The most common pattern: management hands the topic to IT. IT builds a pilot, clean, isolated, with test data. After three months there is a demo. Dispatch sees it for the first time and says: "That is not how it works here." The customer's corrections come on Tuesdays. Customer C is never confirmed automatically. Customer D puts the pallet count in the subject line.
How to spot it: in week 2 there is an architecture diagram but no list of exceptions from dispatch.
What helps: dispatch counts and writes along in weeks 1 and 2. At a portal confirmation that produced 23 steps where the first conversation had named three. The service is then built for 23, not for three.
The service reads the order correctly, checks against the customer master and finds the customer three times: "Hanse Maritime GmbH", "Hanse Maritime", "HanseMaritime Hamburg". It books to the wrong one. Or it does not book at all because it cannot decide, and the review list has 40 entries on day one.
How to spot it: in week 2 nobody can say how many duplicates the customer master has, and nobody has 20 real example files.
What helps: the check against the master belongs inside the service, and the first two weeks of review list are a master-data cleanup, not a project failure. At the wholesaler from the order capture case study, 80 percent of orders were booked without a human touch after three months. Noticeably fewer in the first weeks, and the difference was the master, not the service.
Order capture, portal, arrivals, invoices and advance notices in one project. It sounds efficient, and every vendor likes to sell it that way. In practice five review lists mix, five accesses hang on the same three people, and after eight weeks nothing runs in production, but everything runs at 70 percent.
How to spot it: the project plan has five columns and one person for access.
What helps: one process in four weeks, then the next. The order is in Five processes a forwarder can automate first. The second process is cheaper than the first, because access, master and protocol are already there. Just not at the same time.
It hides inside all three: the alarm hangs on the run, not on the result. The service starts every morning, a prior step fails silently, and it ends without a booking. Days later someone notices. We lived through that ourselves: a service that ran and delivered nothing for a week, because the step before it had stopped without a message. Since then the watchdog counts what was booked, notified or confirmed. Zero on a working day with input is an outage, however green the run icon is.
A caveat: the three mistakes come from projects at forwarders and warehouses with 20 to 500 employees. In a group with its own development department a fourth one appears that is missing here: the project three departments have to release at the same time.
Which of the three mistakes did you see in your last project? Write me the number and the process. I will tell you how we would set it up on the second attempt. Ask for a process check: 30 minutes, no sales pitch.
