Introducing custom software to the team without resistance

01 — Team

How to get the team on board

• Involve early, don't just inform early. Whoever handles the process daily knows where the exceptions are. This information only exists beforehand, not after go-live.
• Take resistance seriously. It's almost never directed at technology, but at extra work or the fear of being replaced. Both need to be addressed openly.
• Don't introduce anything that creates extra work. Systems that require additional data entry will be circumvented — and rightly so.
• Designate one person as the first point of contact. Not as ownership, but so questions don't fall through the cracks.
• Make success visible. If after four weeks no one knows whether it delivered results, what sticks is the memory of the disruption, not the benefit.

02 — Participation

What we need from you

• A contact person who can make decisions — not just forward them.
• Access to the affected systems, in time and not on launch day.
• Real examples from daily business — the messier, the more useful for testing.
• Two to four hours for coordination, distributed over the project duration.
• An answer to the question of what success means. Without it, nothing can be assessed afterward.

03 — Measurement

How you measure success

• Define the one number beforehand. Without a baseline value, nothing can be proven afterward. Two weeks of tracking is enough for a reliable reference point.
• Processing time per case. The most direct metric: How long does the affected process take today, how long afterward.
• Percentage of cases that complete without intervention. This ratio typically rises significantly in the first weeks when refinements are made — it's the best early indicator.
• External response time. How quickly does someone who inquires receive an initial binding answer.
• What you should not measure: Team satisfaction in the first two weeks. Every transition feels worse initially than it actually is.