📝 ESSAY
📍 IN BRIEF
Adoption decays because the roles that own it are filed as supporting roles. They carry one of the heaviest workstreams in the delivery method without the standing authority to hold the line, and the authority they borrow from the programme is handed back the day the programme closes.
Most ServiceNow programmes do not lose adoption at go-live. They lose it in the months afterwards, quietly, once the training is finished, the communications have stopped, and the numbers that looked healthy in week four begin drifting back towards email, spreadsheets and the old ways of working. Nobody decides to abandon the platform, it just becomes optional.
I have spent years inside ServiceNow delivery and governance structures, close enough to watch this pattern survive good funding, good consultants and genuinely good change plans. That repetition is what pushed me past the usual explanations, because the cause turns out to be written into the delivery model itself, in plain sight.
Here is the anomaly the conventional view cannot explain. Change work on these programmes is not thin. Anyone who has sat inside a well-run ServiceNow delivery knows the shape of it: organisational change is one of the heavier workstreams on the plan, with its own named leads for change, training and communications, and a complete arc that runs from setting a change strategy and assessing readiness through communication and training to measuring whether adoption actually happened. Organisations work through that plan diligently, and adoption decays anyway. When the work is demonstrably being done, the volume of work is not the problem.
The work is chartered. The authority is not.
The delivery model gives change roles the workload of a first-class function and the standing of a service.
The standard role model sorts everyone on a ServiceNow programme into three columns. Business roles carry outcomes and mandates that outlast any single project, the sponsor, the process owners, the programme and project managers. Platform roles own the technology, from the platform owner through to the developers. Everything else lands in the third column, the supporting roles, and that is where all three change roles sit. The Change Enablement Lead, the Training Lead and the Communications Lead share a column with testers and analysts, the specialists a project borrows for a while and then releases.
Look at what the model actually asks of these roles and the mismatch becomes hard to unsee. The Change Enablement Lead is expected to design the strategy that makes adoption happen, engage executive leadership, coach the sponsors themselves and build a network of champions to counter resistance. That is strategy-shaped work aimed at the most senior people in the organisation, handed to a role classified as support. Between them, the three change roles carry roughly one in eight of everything the method expects a programme to do. The workload of a principal, filed as a service.
The reporting lines complete the picture. In the standard model, the Communications Lead measures whether messages landed and reports the results to the Change Enablement Lead and to the stakeholders around the programme. Reporting is the operative word, because the model gives the change roles plenty of people to inform and nobody they can oblige. A function whose findings can be politely received and set aside will, in time, be treated the same way itself.
Borrowed authority expires at go-live
While the programme runs, change roles borrow its authority. The programme takes it back when it closes.
During delivery, the classification barely shows. A steering committee is sitting, the sponsor is visible, escalation paths are open, and when the change lead flags resistance somewhere in the business, a governance forum has to answer for it. The borrowed machinery works well enough that nobody notices who actually owns it.
Then the programme closes, and the scaffolding comes down in a matter of weeks. The steering cadence winds up, the sponsor moves to the next initiative, and the change plan reaches the end of its listed activities at precisely the moment the real work of embedding new behaviour begins. Go-live is not the finish line for adoption. It is the start line, and it is also the moment the change team loses its borrowed authority. Support roles have none of their own.
Call this the authority cliff, the drop between the influence a change role holds inside a live programmeand the influence its place on the org chart gives it the day after. The decay that follows has a recognisable shape. People agree in meetings and revert at their desks. A leader accepts a legacy report because the quarter is busy, and everyone watching learns that the platform is optional. None of it looks like failure on any given day, which is exactly why nobody in a support role can stop it. Adoption doesn't decay because people forget their training. It decays because nobody with authority is watching.
The vendor's own guidance has moved on
The clearest confirmation comes from ServiceNow itself.
Its most recent change management guidance, refreshed in 2025, treats adoption drift as a governance risk, not a support ticket. It tells organisations to raise repeated avoidance in governance meetings rather than in a ticket queue, recommends a defined stabilisation window after which working off the platform is flagged for correction, calls for a long-term sustainment role that outlives the project, and keeps executive sponsors reviewing usage trends through sustainment instead of releasing them at launch.
The framing underneath those instructions settles the argument, because it says sustaining behaviour change should run as a governed business process, with routines, ownership and metrics, the way a compliance or financial function runs. Read that against the three-column model and the contradiction is plain. The newest guidance describes a chartered function with decision rights and a permanent seat, while the standard role model files that same function next to testing. When the vendor's latest thinking and its default classification disagree, the classification is what your programme inherits automatically, so it is the thing you have to consciously overrule.
What changes when adoption has standing authority
The question | Filed under support | Chartered with authority |
|---|---|---|
Where usage drift goes | Into a ticket queue | Onto the governance agenda |
When the role ends | At project close | It does not |
What sponsors do after launch | Move to the next programme | Review usage trends on a cadence |
What reversion is called | User preference | A governance risk with a named owner |
Drawn from ServiceNow's standard role model, read against its 2025 sustainment guidance.
Where this doesn't apply
On a small deployment inside a single team, the platform owner can usually carry adoption personally, and the classification of the change roles costs nothing. Equally, some organisations have already moved adoption into a business-side centre of excellence with a seat at the governance table, and they have made the structural decision this essay argues for, whatever their org chart calls it. And reclassification is no substitute for competence. A chartered change function that runs poor training and vague communications still fails, it just fails somewhere everyone can see.
The bottom line
The tactical response to decaying adoption is to commission more training and refresh the communications plan, which treats a structural problem as an effort problem. The structural response is to move the function. Name the person who owns adoption in month seven, before you need them. Give that person a seat on the governance forum you already run, put usage drift on its agenda as a standing item alongside cost and risk, and write the role into your RACI with a mandate that survives project close. Everything else in your change plan can stay exactly as it is.
If your change lead's authority expires at go-live, your adoption plan expires with it.
P.S. Watch the first governance meeting after your next go-live. If usage drift is showing up in the ticket queue but not on the agenda, the decay has already started.