The most expensive internal software is the kind that runs flawlessly and still goes unused. The new tool is launched, but jobs keep living in the group chat, hours keep landing on paper slips, and after three months a single conscientious person maintains a system whose data is therefore never right. From our projects we know that adoption comes down to a few rather concrete points, and most of them are settled before the first day of development.

The one rule: the tool must be faster than the old way from day one

People do not change how they work because of an announcement, and not because of a training session. They change when the new way costs less effort at the moment of use than the old one. A technician who used to report a job with a ten-second chat message will not fill in a form with twelve fields, no matter how much the office would gain from the analysis. And software routine is spread more thinly than the office assumes: according to the European Commission (Digital Decade, as of 2026), only 55.6 percent of the EU population has at least basic digital skills. Whoever builds an internal tool is also building for the other near-half.

This leads to an uncomfortable design rule: the person entering data has to get something out of it themselves, and the entry has to compete with the old way. Three required fields instead of twelve, suggested values instead of blank ones, and in return an immediately tangible benefit, say the technician seeing their weekly hours without adding anything up in the evening. Everything else the office wants to know has to respect that trade.

Bring the biggest skeptic on board before anything is built

Every team has the person who thinks nothing of new software, often because they have lived through two failed rollouts already. The reflex is to route around them. The better move is the opposite: exactly this person belongs in the first conversations, because they know the exceptions and edge cases of daily work best, and their objections are usually requirements in disguise.

“That won’t work here, because jobs often come in without a customer number” is not a rejection. It is a precise description of what the tool has to handle. A skeptic whose objection is visibly addressed in the software surprisingly often becomes its most credible advocate, more credible than any announcement from management.

Launch with real data, not an empty system

An empty tool is pure extra effort on day one: you are supposed to enter things but get nothing back, because nothing is in there yet. Those first weeks decide the system’s reputation in the company.

That is why migrating existing data belongs in every project: the running jobs, the customer list, the articles from the old spreadsheet. It is unglamorous work and costs a few project days, but a planning board that shows the real upcoming week from the first minute explains itself. Nobody explains an empty board.

The old Excel file needs an expiry date

The most common death of internal tools is parallel operation. As long as the old file lives on, “just to be safe”, some people enter data here and others there, neither source is complete, and soon the new system counts as unreliable, even though it does exactly the right thing with what it is given.

A transition phase is normal and sensible. But it needs an announced end: from a fixed date, the file becomes read-only and the new way is the only way. No vendor can make that decision; it is management work. We raise it early in projects, because we have seen tools fail on precisely this missing cut-off date, not on a single line of code.

Budget for the refinement round; it is not a complaint

No matter how good the preparation was: the first weeks of real use will reveal that a field is missing, an order of steps is awkward, an edge case occurs more often than assumed. That is not the sign of a bad project but the normal course of one, and the most valuable feedback you will ever get on this tool.

In practice this means: deliberately budget an adjustment round after launch, and make sure feedback has a short path, a message, not a form. A team that sees its Tuesday remark implemented by Friday treats the tool as its own. That feeling, more than any feature, is what decides usage in the end.