Getting Employees On Board with Digitalisation

A company introduces a new CRM. The tool was carefully selected, licences are paid, the technical implementation runs smoothly. Three months later, two out of seven employees use it regularly. The other five are still working with their spreadsheets or the old system, with or without explicit permission.

This is not an exception. Change management research estimates that between 60 and 70 percent of all change projects fall short of their goals. Insufficient employee involvement is consistently cited as the leading cause. In Austrian SMBs, where teams are small and personal routines run deep, this is particularly pronounced.

Why does resistance to digitalization emerge?

Resistance to new tools or processes usually has concrete causes, not just reluctance to change. Behind the rejection are usually these concerns:

• Uncertainty about their own role: 'Will I be able to handle this? Does this make me redundant?'
• Lack of trust in the decision: 'Did anyone actually understand what our work looks like?'
• Past negative experiences: 'It was the same with the last tool, three months later nobody believed in it anymore.'
• Missing value argument: 'Why should this be better than what we have now?'
• Transition stress: 'I already have too much on my plate, and now I'm supposed to learn something new.'

None of these are irrational. They are legitimate concerns that need a clear answer, not a marketing pitch.

What 'bringing people along' actually means and what it doesn't

Bringing employees along is not a one-time event. A kickoff meeting, an email from the managing director, or a colourful presentation with before-and-after slides won't do it. The process must run in parallel with the technical rollout. It deserves the same level of planning effort.

In practice it means: the people who will work with the system every day are asked before decisions are made. They understand why the project is happening. The explanation relates to their daily work, not strategic corporate goals. They have ways to raise concerns without fear of consequences. And they see early on that the new system actually solves problems they themselves experience as problems.

Five measures that work in practice

These are not theoretical recommendations. They are approaches that have made a measurable difference in concrete projects with Austrian service providers, trades businesses, and consulting firms.

1. Involve early, before the decision is made

The most effective measure is also the most frequently skipped: involving employees who will use the system daily in selection as well as training. This can be as simple as giving two or three team members three tools to try and asking what would make their day easier. The tool fits the actual workflows better. And those involved become natural advocates with their colleagues.

2. Communicate the reason transparently

'The company is growing and we need better structures' is not a sufficient explanation. What works: concrete, honest statements. 'Last year we failed to follow up on three proposals because nobody had an overview.' Or: 'The current setup makes it impossible to respond to enquiries overnight. We lose those regularly to competitors.' If the project is genuinely worthwhile, there is a real reason. State it.

3. Tailor training to the actual daily job

Product trainings that rush through all features in two hours are a waste of time. What works: training sessions built around the real tasks of each role. What three things does this person do every day? How do they do those three things in the new tool? Everything else can be covered later. Focusing on the starting use case reduces cognitive overload and significantly increases the chance the tool is actually used after training.

4. Build internal multipliers

In almost every team there is someone who is more open to new tools than others and who colleagues respect. Involve this person deliberately: give them early access, train them first and make them the contact point. This costs little and delivers a lot. Questions get answered by someone the team trusts. Problems get solved internally before escalating into fundamental criticism.

5. Make small wins visible early

If the first weeks after go-live consist mainly of extra work, such as double data entry alongside recurring confusion and technical issues, that's a systemic risk. The transition must be planned so that measurable improvements are visible within four weeks: a task that used to take 30 minutes now takes 10. A request that used to go through three pairs of hands now arrives directly. Actively communicating these moments in a brief team meeting or an internal message sustains momentum.

What doesn't work

Honestly: some measures commonly used in change projects deliver little in practice:

• Information sessions without dialogue: if employees listen for 60 minutes and get five minutes for questions, they don't leave as supporters.
• Commitments by email: an email saying 'Please everyone use the new CRM' does not generate usage.
• Parallel operation with no end date: if the old system remains available indefinitely, the new one will never be seriously tried. A clear shutdown date sets a clear boundary condition without applying pressure.
• Too much at once: introducing a new CRM, a new project platform, and a new communication channel simultaneously overwhelms the team. None of the three rollouts succeeds properly.

Timeline and realistic expectations

A realistic acceptance phase for a new tool in a team of five to fifteen people takes eight to twelve weeks. The first four weeks are the most critical. This is where it's decided whether the tool is perceived as useful or as a burden. Active support during this phase, through accessible contact people, quick issue resolution, and open communication, saves weeks of resistance later.

No team will be 100 percent on board. There will always be people who prefer the old way, out of habit, conviction, or reasons that have nothing to do with the tool. That's not a failure. What matters is consistent use rather than approval. Are core processes being captured in the new system? Is data being maintained? Does daily work function? If yes, the project is a success. Even if not everyone is enthusiastic.

Frequently Asked Questions