The rollout went well. The invoice is paid, the vendor drove off, the head of department breathed out. Six months later it turns out half the team is still doing the actual work in Excel. The new system is on, it's blinking, but it plays no part in the real job.
This isn't unusual. This is a scenario that repeats itself week after week — in wholesalers, in manufacturers, in service companies. People aren't stupid, the vendor didn't cheat, and yet something isn't working. This piece is about why.
At one of our clients — a 28-person freight forwarding company — a new TMS cost 180 000 PLN plus a year of implementation. Eight months after go-live, four of six dispatchers were still running orders in parallel in Excel. The reason turned out to be disarmingly simple: the TMS had no field for "notes for the driver", and every Friday an intern copied data from spreadsheets into the system after hours. Everyone knew. Nobody said anything.
Who was actually supposed to use this
The first mistake happens long before the system is chosen. The decision lands at the board level — based on a slide deck, references and price. The salesperson, the warehouse worker or the dispatcher isn't invited into that room. Yet they're the ones who will live inside this system for eight hours a day.
The result is that we buy a tool "for the company" that doesn't fit the specific job. The CRM vendor demos a beautiful kanban, but nobody asked the salesperson what their day actually looks like: a call at 8:00 from a customer with a complaint, an email with a quote request, a truck that just broke down, four quick text messages in between. Kanban has three columns; their day has fifteen states.
- Invite two or three future users, not just their bosses, into the selection.
- Ask them to walk the vendor through their own "day in the life" — what they do, in what order, where they click today.
- In the demo, check exactly the three or four activities that take up most of their working time.
- Ask outright: "what's missing?" — and take that list seriously, not as a whim.
Training is not adoption
The standard rollout ends with a two-day training. The vendor runs slides, clicks through examples, hands out a PDF manual, signs the acceptance form and leaves. A week later people have a new system, fresh memory and one urgent quote request that's on fire. Guess where they're typing it in.
Training shows where the buttons are. Adoption is something else entirely: you reach it when a person stops thinking "how do I do this in the new system" and just starts doing the job. That takes weeks, not hours. Without planned support during that period — daily, for the first four to six weeks — most of the team will go back to what they know. Excel doesn't need training.
- Plan the first four weeks after go-live as a separate project phase, not "the end of implementation".
- Assign one person inside the company who during that time sits next to users and answers "where do I click here" questions.
- Set up short, 15-minute end-of-day stand-ups — what didn't work today, what we'll fix tomorrow.
- Keep a running list of things to fix, and show every week what's already gone from it.
Excel wins because it listens
Excel beats every system for one simple reason: it does exactly what the user wants, at the pace the user wants. It doesn't ask questions, it doesn't force workflow, it doesn't argue that the "tax ID" field is required. It's obedient. A new system, as a rule, isn't.
That doesn't mean the new system is bad. It means it fits reality worse than a spreadsheet the person built for themselves over three years. If the TMS is missing one field, the dispatcher won't change the process. They'll write the notes in Excel. If the CRM makes the salesperson click through seven screens to save a contact, they'll write it in a notebook two weeks later.
At the freight forwarder in our example, all it took was adding a single "notes for the driver" text field in the TMS and a keyboard shortcut to open it. Cost: half a day of developer time. Effect: Excels vanished in two weeks. Nobody had raised it with the vendor earlier because "it won't work anyway", and the vendor only asked at the quarterly status.
- Treat Excel workarounds as a signal, not disobedience — something is wrong with the tool, not with the people.
- Keep a short path to report "I'm missing one field" — not a two-week ticket, but a conversation with the internal system owner.
- Book a regular (monthly) small-changes session with the vendor — not a "new project", just adjustments.
- Don't make people justify functional needs — if three people ask for the same thing, just do it.
Who is responsible for keeping the system alive
The last missing piece is a specific person — not a job title, not "the IT department", but a first and last name — who is responsible for keeping a given system alive inside the company. In a large company this is called the "system owner". In an SME it doesn't have to be a full-time job: it can be two hours a week for the warehouse manager who already knows the WMS inside out.
That person watches over three things: that data stays current, that user reports actually reach the vendor, and that new employees get an onboarding. Without them, after half a year the system has an outdated catalogue, unresolved tickets from months ago, and a new employee who discovered after a week that "we always do this in Excel anyway".
- Assign one person inside the company as the owner of each major system — and put it in their annual goals.
- Book them a regular (monthly) meeting with the vendor — not in a crisis, just for small improvements.
- Give them real time for the role — two hours a week is the minimum, not "when they have a moment".
- Make them the first person any "it's not working" report goes to — before anyone calls the vendor.
What a well-done rollout looks like
A rollout after which people actually use the system looks different from the typical one. Selection takes longer — because the future user is in the room. Training is shorter — because half the team already saw the system during a pilot. The first four weeks after go-live are scheduled hour by hour, with an internal owner. A list of small changes from users goes back to the vendor every month, not "at the end of the implementation".
It costs a little more work on our side and a little more patience from the board. In exchange you get something you can't buy in a licence: a system that's still being used a year later. It sounds mundane until you count how many companies today have unused software worth 200 000 PLN sitting on the books.
If you're rolling out a new system now, or you already have one your team avoids, half an hour with an outside pair of eyes is usually enough to pinpoint where the problem actually is. We don't sell licences, so we have no reason to sell you another one.
A system nobody uses costs you twice — once at purchase, and once because people burn time doing the same work in parallel in Excel.