Go-Live Is the Midpoint: Activation, Champions, and Adoption After Deployment

What actually changed on Monday morning?

That is the question we would put to any team the week after an AI system goes live. If the honest answer is "people got accounts and a launch email," the deployment is not finished. It is halfway. The model works, the integrations hold, the evals pass. None of that tells you whether a single person has changed how they do the work the system was built for.

We treat go-live as the midpoint of a deployment, not the finish line. The first half is technical: get a system into production, inside the customer's own environment, safe enough to trust with real work. The second half is behavioural. People have to reach for the new way first, get value from it quickly, and keep reaching until the old workaround feels like the strange choice. That second half has a name in product teams, activation, and in AI deployments it is where value either shows up or quietly doesn't.

Access is not activation

Provisioning is easy to count, so it tends to become the reported number. Accounts created. Licences assigned. Training sessions held. Each one can be at 100% while daily use sits near zero, because none of them measures the only event that matters: a person completing a real task, in their real workflow, and getting a result good enough to try again.

Activation, as we define it, is narrower and harder. A user does the job the system exists for, not a demo task and not a test prompt, inside the tool they already work in, and the output survives contact with their standards. One success is curiosity. The pattern to build toward is repeat use without prompting, and then the moment that actually settles it: the new path becomes the default, and the spreadsheet, the side document, the manual habit starts to disappear.

Why does the gap persist? Partly because the workflow around the system often stays exactly as it was. McKinsey's 2025 survey of AI use found that the organisations reporting the strongest returns were far more likely to have fundamentally redesigned individual workflows around AI — about 55% of those high performers, against 20% of everyone else. Read that carefully and it is an adoption finding as much as a design one. If the steps before and after the model stay untouched, you have inserted a clever moment into an unchanged day. People route around unchanged days.

So the practical work after go-live is unglamorous. Put the entry point where the task already starts, not in a new portal someone must remember to visit. Remove the second login, the copy-paste between systems, the approval that duplicates an approval that already exists. Give the first task a short path to a visible win, a draft someone can use or a check that catches something real, because early evidence persuades people in a way launch communications never will.

Champions do the work sponsors can’t

Every deployment plan names an executive sponsor. Fewer name the people who will actually carry adoption, and the two jobs are different. A sponsor can fund the work, say it matters in a town hall, and clear a blocked decision. A sponsor cannot sit next to a claims handler, a planner, or an analyst at 9 a.m. and show them how Tuesday's task runs through the new system.

That is champion work. A champion is a respected peer inside the team, not the most technical person and usually the one colleagues already ask for help, who uses the system in the open, answers the small questions before they harden into objections, and reports friction back in the user's own words. "It logged me out twice" is a bug report. "Nobody trusts the summary, so everyone re-reads the source anyway" is the more valuable signal, and champions are how you hear it early enough to act.

The leadership data points the same way. In that same McKinsey survey, respondents at high-performing organisations were about three times as likely to say senior leaders visibly owned the AI work and modelled its use. Visibility from the top helps. It just does not substitute for help at the desk, which is why we would rather see a deployment budget protect a few champions' time, hours in their week recognised as part of the job, than spend the same money on a larger launch event.

A warning, because this role gets abused: a champion is not an unpaid support desk, and not an informer reporting who has not complied. The moment peers read the role that way, the information stops flowing and you are back to dashboards that say everything is fine. Champions carry feedback up and know-how sideways. Adoption follows trust, and trust is the mechanism here, not a soft extra around it.

Measure use, not applause, and let the failures teach

If activation is the goal, measure activation. The numbers we trust after go-live are plain ones: how many of the intended users completed the core task this week, how many came back the next week without being chased, and how often the output was used as-is, edited, or abandoned. Logins tell you a door opened. They say nothing about whether anyone stayed in the room.

Just as useful is the negative space. Where do people start in the system and finish outside it? Which step sends them back to the old tool? Those drop-offs are not resistance to be managed; they are the most honest product feedback a deployment gets, and they belong in the same loop as any other production failure: logged, grouped into patterns, fixed, and checked again.

A system that learns from its first month in real hands gets better at the work. A system that only reports its launch metrics stays exactly as good as the day it shipped, which is rarely good enough.

There are limits to all of this, and they matter. Adoption work cannot rescue a system that is not actually better at the task. If the old way is faster or more accurate, people are right to keep using it, and no champion network should be spent arguing otherwise. Timing can defeat good work too: launching into a team's peak season, or alongside three other changes, spends attention nobody has. And some non-use is correct. Edge cases, sensitive cases, the judgement calls a team decides to keep fully human. A healthy deployment has a clear, agreed boundary there, not a quiet failure to convert the last holdouts.

None of that argues for treating adoption as an afterthought. It argues for planning it with the same seriousness as the build: named champions, a redesigned workflow rather than a decorated one, measures that track real tasks, and time after go-live that is staffed and budgeted instead of assumed. Half the deployment, in other words. The easier half to forget, because the system already demos so well.

Bring us a problem

If your AI system is live and the honest usage numbers are thinner than the launch announcement suggested, or you are planning a deployment and want the second half planned before the first half ships — start with Trida AI's intake — a few questions, then talk with founders and experts from Trida AI.