Change management: getting teams to adopt a digital tool

Quick answer. A digital tool only creates value if it is actually used. Change management rests on four pillars: clarify the why (the concrete benefit for the teams), involve future users early in the choice and setup, train and support over time, measure real usage and adjust. An excellent tool poorly supported fails; a decent tool well supported settles in.

Digitalisation projects rarely fail because of the tool, almost always because of adoption. Buying software is not enough: the teams must actually use it, and not a watered-down version kept alongside an unofficial spreadsheet. Change management is the discipline that turns spending into a gain. It becomes critical in 2026: with the obligation for all companies to be able to receive electronic invoices from 1 September 2026, many organisations are deploying tools under calendar pressure that the teams have had no time to absorb. This article walks through the method, step by step, with a decision table, a concrete case and the pitfalls we keep seeing in client files.

The best software is worth nothing if it is not adopted.

A tool bought but little used, bypassed or used partially, produces none of the expected gains: not the time saved, not the drop in errors, not the reliability of the data. Worse, partial use costs more than the status quo, because the company pays the subscription, keeps the old system running in parallel and loses the consistency of its data between the two. Resistance to change is not a whim: new habits to rebuild, fear of complexity, a sense of a tool imposed without being consulted, fear of being monitored or of seeing one's role reduced. Ignoring this human dimension is the leading cause of failure of digital projects.

Value therefore comes not from the purchase, but from usage. This is why change management is not an optional extra, but a condition of success, on a par with the choice of the tool or its technical migration to the cloud. A well-equipped but poorly supported project produces what we call ghost software: a licence paid for, never opened.

The method comes down to four pillars, two playing out before deployment, two during and after. None is easily recovered once the project is launched: a pillar neglected upstream costs much more to rebuild later.

Clarify the why and involve early#

Clarifying the why means explaining the concrete benefit for the teams themselves, and not just for the company: fewer re-entries, fewer errors fixed in a hurry, more useful time on value-adding tasks. A change perceived as a constraint with no personal benefit mechanically triggers resistance. The message "this will make us more productive" speaks to management; it must be translated into "you will no longer key in the same invoice twice" to speak to the user.

Involving early means associating future users with the choice and setup, which turns passive recipients into project actors. This involvement increases buy-in and, above all, surfaces the real needs of the field: a setup decided without those who do the daily data entry almost always misses a central use case. A tool chosen with the teams starts with a head start over a tool imposed from above.

Train, support and measure#

Training must suit real uses, never be generic, and be organised around the tasks the teams will actually perform. It relies on internal champions, volunteer users who master the tool, promote it and help their colleagues daily, as well as on support available over time, not just during launch week.

Finally, you must measure real usage: who logs in, which functions are used, where the sticking points are, then adjust. It is this loop of measurement and adjustment that distinguishes a steered deployment from one abandoned after go-live. This logic matches that of a good client portal for exchanging accounting documents: a channel only has value if both parties truly use it, which is verified by the adoption rate, not by the pitch.

Adoption is not observed by gut feeling, it is measured. A few simple indicators are enough to know whether a deployment is taking off or stalling.

These indicators are read as a trend, over at least three months, not as a launch snapshot. The initial peak of enthusiasm misleads: it is the curve at 60 and 90 days that tells whether the tool has entered the habits.

In the projects we support, success is 80% about people and 20% about technology. The recurring mistake is to spend the whole budget on the tool and the migration, then treat support as an adjustment variable, which dooms the project whatever the quality of the software. We therefore handle change management from the framing stage: clarify the benefit, involve the teams, train on real uses, measure adoption to adjust. Internal champions are by far the most effective lever, often more than top-down training: they speak the language of the field and stay available between two data entries. Support is not a cost added to the project, it is the very condition of the return on investment. The same rigour applies to automation and finance hyperautomation tools, whose promise materialises only if the teams let them work in their place rather than re-checking every entry out of habit.

A services SME had deployed a new management tool with no support, counting on its ergonomics alone and on a general half-day demonstration. Six months later, nearly half the team had bypassed it, reverting to their old shared spreadsheets. The project produced no gain: the subscription was paid, the data was split between two systems, and management believed the tool adopted while the real active-user rate was a minority.

The recovery came through change management, not a change of tool. We first clarified the concrete benefit role by role, then identified two volunteer champions, redid a training centred on three real use cases, and set up monthly tracking of the usage rate. The tool had not changed: it was the support that was missing. The tipping point was removing the old duplicate files, which were fuelling avoidance.

In practice: succeeding in the rollout#

• Frame the user benefit role by role before buying, not after, and write it in one sentence each team can understand.
• Associate at least one future user per department with the choice and setup, and make them a declared champion.
• Prefer short training on the company's real use cases over a generic vendor demonstration.
• Set two or three adoption indicators from the start (active user rate, persistence of duplicates, support tickets) and a review point at 30, 60 and 90 days.
• Remove old duplicate supports once the tool is stable: as long as they exist, avoidance persists.
• Frame the use of sensitive tools, in particular AI, with a clear internal charter to secure adoption without overreach.

• Confusing training with support: training is one-off, support runs over time. A single demo does not make an adoption.
• Measuring success by the number of licences bought rather than the rate of truly active users: the licence proves the purchase, not the usage.
• Letting old files live on in parallel: as long as an unofficial duplicate exists, part of the team will go back to it.
• Underestimating the role of front-line managers: a supervisor who does not use the tool sends a stronger signal than any management memo.
• Deploying every function at once: too wide a scope drowns users. A mastered core, then extensions, works better.
• Neglecting the regulatory calendar: deploying in the rush of a deadline, such as electronic invoicing, with no time to absorb it, multiplies the risk of rejection.

For a structuring project that touches the accounting, tax or steering chain, it is better to frame the tool and its adoption with a chartered accountant who knows your flows, and, in groups, to align the tools with the existing organisation, for example when a holding structure imposes consolidations and reporting shared across several entities.