Skip to content
Back to blog
ITSMAdoptionImplementation

Your ITSM tool is live, now what? Adoption decides whether the implementation succeeds

Ruben van der Graaf4 min read

Going live with an ITSM tool is the start, not the finish. Learn how adoption, ownership and upkeep stop your new tool from repeating the old way of working.

The implementation is finished, the project has been delivered and the new ITSM tool is running. Six months later the conclusion is often sobering: the same way of working as before, just in a different screen. Categories are used incorrectly, the portal is avoided and the reports mean nothing to anyone. The tool is live, but the change never landed. This article shows why adoption is the real work and how to set up the period after go-live properly.

Why go-live is not the finish line

Enforcing a tool is easy; changing a way of working is not. At go-live the technology changes, but habits simply move along. Whoever always took incidents by email does the same in the new tool, and registers them afterwards. Whoever never took categories seriously now picks the top one from the list.

The project team has usually left after go-live, exactly when the questions begin. And without someone adjusting the configuration based on how people actually work, the gap between tool and practice grows every month.

The three pillars after go-live

Ownership: someone has to own it

An ITSM tool without an owner is guaranteed to deteriorate. Appoint someone responsible for the configuration and its fit with the work. Not necessarily a full-time job, but a clear role: this person collects pain points, prioritizes changes and guards that the configuration stays simple. Without an owner, every request for an extra field or mandatory step gets granted, and within a year the tool has silted up.

Usage: look at how people actually work

Reports tell you what was registered, not how things are going. Sit with the team. What do people click around? Which fields do they fill with nonsense because they are mandatory? Which workflows run outside the tool, through email or chat? Each of those detours is a signal: the configuration does not fit the work. That is not a user error, that is improvement information.

Upkeep: small and continuous instead of big and someday

Your tool's configuration is never finished. Services change, teams change, and what made sense at go-live no longer holds a year later. Plan a fixed, small rhythm: implement a few improvements every month based on what users raise. That keeps the tool aligned with the work and shows users that giving feedback pays off.

How to approach adoption concretely

  1. Measure real usage, not licenses. How many incidents come in through the portal versus email or phone? How many knowledge articles get opened? That is your baseline.
  2. Fix the biggest annoyance first. Ask the team what gets in the way most and repair it visibly. Nothing builds support better than a quickly resolved annoyance.
  3. Make the right route the easiest one. As long as emailing feels faster than the portal, email wins. Prune forms down to what is genuinely needed.
  4. Repeat the explanation after a few months. The instruction at go-live landed while everything was new. A short refresher once habits have formed often has more effect than the original training.

What it delivers

A tool that fits the real work pays for itself: fewer detours, more reliable data and reports you can actually steer on. The team stops fighting the system and the investment in the implementation starts to return. That is the difference between a tool that is live and a tool that works.

Frequently asked questions

How much time does maintaining the configuration take after go-live? Less than most organizations fear. A fixed half-day per week for the owner plus a monthly improvement session is enough for most environments to keep the tool aligned with the work.

Our adoption is already low, is it too late? No. Start with the baseline and the biggest annoyance. Users come back once they notice the tool helps them instead of hindering them. That does require visible improvements, not announcements.

Is low adoption not a reason to pick a different tool? Rarely. Whoever does not change the way of working takes the problems along to the next tool. First check whether the configuration and the habits are the problem; they almost always are.

Is your ITSM tool live but real usage lagging behind? book a call and we will look together at where the configuration and the daily work diverge.

Further reading

Want to apply this in your own organization?

Schedule a no-obligation conversation. Together we look at where you stand and what the first step is.

Get in touch