A useful system needs a new everyday practice.

A new assistant goes live on a Monday. There is an announcement, a short demo and a link to a guide. Use peaks that week, then drifts back to the few enthusiasts who would have tried it anyway. A month later, someone asks in a meeting why nobody uses the thing the company paid for.

It is a familiar pattern, and it rarely means the tool was bad. It means the launch changed the software and nothing else. The meetings, the reports, the handovers and the expectations stayed the same, so the old way of working remained the easiest way. Adoption is not an announcement. It is a change of routine, and routines change for specific reasons.

Why doesn’t a launch change behavior?

People do what their week rewards. If the Monday report is still built by copying numbers from three systems, and nobody asks where the numbers came from, a tool that drafts the report is an optional extra. Learning it costs time the week doesn’t have. Most people are not resisting AI. They are protecting their schedule.

So the useful question is not “how do we get people to use the tool?” It is “which routine should this tool be part of, and what has to change in that routine?”

Change the routine first

Before any training, map the week of the team that will use the system. Where does the work arrive, where does it wait, where is it checked, and where is the result used? Then decide where the new output fits and what it replaces.

Take an illustrative sales team. If an assistant drafts account summaries, the weekly pipeline meeting should open with those summaries, not with someone reading from the CRM. The old path doesn’t have to disappear on day one, but it should stop being the default. When the routine expects the new output, people produce it.

Train on real work, in the team’s language

Generic demos teach people that a tool exists. Training on their own tasks teaches them when it helps. We build sessions around each role’s real cases: the invoices, tickets, contracts or reports they actually handle. Groups are small, sessions are short, and most of the time goes to practice, not slides. Where a team works in Turkish and English, the training does too. A curriculum by role sets out what each group needs.

Good training also covers the limits: what the tool is not for, when to check its sources, and when a person must decide. Confidence grows faster when the boundaries are clear.

People adopt a tool when someone they report to asks for what it produces.

Talk openly about what changes for people

Many people hear “AI” and wonder what it means for their job. Vague reassurance doesn’t help, and silence makes it worse. Be specific: which tasks the system will prepare, which decisions stay with people, what the time saved is for, and what training is available. Involve the people who do the work in designing the review step. They know where the risks are, and a system they helped shape is one they are more likely to trust. When roles do change, say so early and plan the transition with the people affected.

Give champions time, not just a title

In every team there are people who figure out new tools first and explain them to colleagues. A champions program makes that role official. Champions get deeper training, a direct line to the system’s owner and, crucially, protected time to help others. They collect good examples and problems, and pass them on.

A title without time does not work. If helping colleagues is squeezed between regular tasks, the program fades within weeks.

Managers ask for the output

The strongest signal in any organization is what managers ask for. When a manager opens the weekly meeting with the AI-drafted summary, reviews the exception list the system produced, or asks what the assistant flagged since the last meeting, the new routine becomes the normal one. When managers never mention it, it stays optional.

This is why enablement starts with leadership, not with users. An executive session on real priorities gives managers their own experience of the tool, and a reason to ask for its output.

Retire the old path, one step at a time

If the old spreadsheet still works and the new system is optional, the spreadsheet wins. Once the new output is reliable, remove the duplicate steps: stop circulating the manual report, route requests to the new queue, archive the old template. Do it in stages, announce each one, and keep a fallback for the cases the system can’t handle yet.

Measure use and results together

Usage numbers alone mislead. Heavy use of a tool that produces poor results is a problem, and light use of a tool that saves hours for the three people who need it may be fine. Track use alongside the workflow’s own measures: time per case, rework, quality. Read what people say when they override the system or stop using it, and act on it visibly. Nothing encourages feedback like seeing it change something.

A 90-day outline

• Weeks 1–2: map the routines, choose the roles and tasks to start with, and brief the managers.
• Weeks 3–6: run short cohorts on real work, appoint champions, and fix the first problems quickly.
• Weeks 7–12: build the new output into weekly meetings, review use and results with managers, and hand the program to its owners.

After ninety days, the tool should be part of how the team works, with someone inside the team responsible for keeping it that way. If you want a partner for the ninety days, AI enablement is the work we do with teams: role-based training on real tasks, champions and new routines with clear owners.