Bringing employees along doesn't mean convincing them. It means involving them early, communicating honestly, and designing the transition so their daily work genuinely improves, not just the report to management.
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 transformation projects fall short of their goals, and 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 resistance emerges, and what it's really about
Resistance to new tools or processes is often dismissed as laziness. That's rarely the full story. Behind the rejection are usually concrete 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. It's not a kickoff meeting, an email from the managing director, or a colourful presentation with before-and-after slides. It is a process that must run in parallel with the technical rollout, and that 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, in terms that describe their daily work, not in 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 the selection process, not just the 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 result is twofold: 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, it should be stated.
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. Deliberately involving this person, giving early access, training them first, making them the contact point, 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, double data entry, confusion, 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 isn't pressure, it's a clear boundary condition.
- Too much at once: introducing a new CRM, a new project platform, and a new communication channel simultaneously overwhelms the team, and 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 accompaniment during this phase, 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. The relevant metric is not approval but consistent use: 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
Why do so many digitalisation projects fail on employee acceptance?
The most common reason is that the project's focus is on technology, not on the transition. Tools are selected, implemented, and trained, but the question of why employees should prefer the new system over their proven approach goes unanswered. Engaging in early dialogue and taking concrete concerns seriously prevents most of these failures.
When is the right time to involve employees in a digitalisation project?
As early as possible, ideally before the tool decision is made. When at least a few people from the operational team are involved in selection, the tool fits better and those people become internal advocates. If employees are only brought in at the training stage, resistance is usually already in place.
How do you handle employees who actively work against a change?
Active resistance usually hides a specific concern: fear of losing their role, loss of control, or bad experiences from past projects. The first step is always a direct conversation, what exactly is the problem, what would help? In most cases a concrete answer can be found. If someone continues to actively sabotage after enough time and support, that becomes a leadership issue, not a change management issue.
What is a realistic adoption rate when introducing new tools in the Mittelstand?
100 percent acceptance is not a realistic or meaningful target. A realistic goal is consistent use of core use cases by 70 to 85 percent of the team after three months. Reaching that threshold means the project has succeeded. The rest usually follow once the tool is present in daily work and colleagues share positive experiences.