There is a specific pattern that plays out in almost every D2C launch we have been involved with. The business invests in a new system. An ecommerce platform, a warehouse management system, a middleware layer, sometimes all three. The software is configured. The team are trained (briefly). It goes live. And within a month, the warehouse team are back on spreadsheets.
Not because they are resistant to change. Because the system does not do what they need it to do, in the way they need to do it.
Enterprise software has an adoption problem that the industry does not talk about honestly. The research suggests that more than half of enterprise software features go unused. That is not because the software is bad. It is because the gap between what the software can theoretically do and what the team on the floor actually needs it to do is filled with workarounds, exceptions, and manual processes.
In a warehouse that has operated as a B2B operation for decades, the team have built up a set of working practices that are deeply embedded. They know how to pick a trade order efficiently. They know how to load a pallet. They know how to handle a short shipment or a damaged case. These processes work because they have been refined over years by the people who do them every day.
When D2C arrives, the processes change. Single-unit picking is different from pallet picking. Consumer packaging is different from trade packaging. Individual shipping labels are different from bulk delivery notes. Returns from consumers arrive differently, in different volumes, with different expectations. The team’s expertise does not transfer automatically. And if the new system was configured without deeply understanding the existing workflows, it will fight the team rather than support them.
The typical implementation process for a new system works like this. A project team (usually a combination of IT, an external partner, and a senior sponsor) selects the software, configures it, tests it in a controlled environment, and rolls it out. The warehouse team gets training: a day or two of sessions showing them how the system works. Then it goes live.
The problems start within the first week. The system handles the standard scenario well enough. But the first non-standard scenario (a partial shipment, a consumer order that needs splitting, a product that is stored in a different location than the system expects) does not fit the workflow. The team asks how to handle it. Nobody knows, because that scenario was not covered in configuration or training. So someone creates a workaround. A spreadsheet. A Post-it note on the pick list. A manual check that adds 30 seconds to every order.
By the end of the first month, there are a dozen of these workarounds. Each one is small. Each one is rational. And collectively they represent a parallel system running alongside the software that the business just paid for. The software is technically live. The team are technically using it. But the actual process is a hybrid of the system and the spreadsheets, and the spreadsheets are doing more of the heavy lifting than anyone in the boardroom realises.
This is not a technology failure. It is a design failure. Specifically, it is a failure to design the system around the real workflows of the people who will use it, rather than around the idealised workflows of the people who configured it.
Most system implementations are led from the top: strategic objectives, data architecture, integration requirements, reporting dashboards. These are all important. But they are all the perspective of the sponsor and the project team, not the perspective of the person standing in the warehouse at 6am trying to pick 200 consumer orders before the courier arrives at 2pm.
The warehouse team’s requirements are intensely practical. They need the system to tell them where the item is, in language they understand, in an order that matches their physical pick path. They need it to handle the thing that happens three times a day that nobody mentioned in the requirements document. They need it to be fast, because they are working to a deadline and every additional click, scroll, or screen costs them time.
If the system was configured without spending time on the warehouse floor, watching how orders are actually picked, packed, and shipped, it will miss these requirements. And the team will compensate with spreadsheets, because spreadsheets are flexible, immediate, and do not require a change request to modify.
The answer is not better software. It is better design, and specifically, design that starts on the warehouse floor rather than in the project meeting.
Before the system is configured, someone needs to spend time understanding how the current operation works: the pick paths, the packing process, the labelling, the exception handling, the shift patterns, the physical layout. Then the system needs to be configured to support that reality, not to replace it with an idealised process that nobody on the floor helped design.
Training needs to go beyond the standard workflows. It needs to cover the exceptions, because the exceptions are where the team loses confidence in the system and reverts to manual processes. If the training does not address the thing that happens three times a day but is not in the user manual, the spreadsheet will.
And someone needs to stay on the floor for the first few weeks after go-live. Not to supervise. To observe, to listen, and to fix the things that were not anticipated. Every warehouse go-live generates surprises. The difference between a system that beds in and a system that gets quietly replaced by spreadsheets is whether someone is there to catch the surprises early and adjust the configuration before the workarounds become permanent.
Spreadsheets are not the enemy. They are a symptom. They tell you where the system is not meeting the team’s needs. The businesses that pay attention to that signal, and act on it quickly, are the ones whose systems actually work. The businesses that ignore it end up with expensive software and a warehouse that runs on Excel. And by that point, convincing the team to trust the system a second time is twice as hard.
