Is your support team actually using its AI assistant?

When a customer service or CX leader introduces an AI assistant for the support team, the opportunity is help for every team member. It can take on the slow parts of a reply: finding the right answer, drafting it, adjusting tone or language. Done well, that can mean faster and more consistent replies, and more time for the cases that need judgment.

Buying the assistant does not deliver that. Access means people can open it. Adoption means they use it in the work it was bought for. Value depends on whether that use makes replies better or faster. A rollout can stall between any two of these, and a licence count will not tell you where.

This guide covers the middle step: finding out whether the people who should use the assistant actually do. Then you can help those who don't before you judge the tool or the business case. The steps are our recommendations, drawn from Typewise conversations with support teams rolling out AI assistants in 2026, not a benchmark for how fast adoption should rise.

Access, use and value are separate questions

Each stage needs its own measure, and none of them is a share of the one before. Someone can have full access and no eligible work that day. Someone else can use the assistant often on replies that still need heavy editing.

This article is about stages 2 and 3. For stage 4, see how to use draft mode to improve AI replies and the business case guide.

Decide who should be using it

An adoption rate is only as good as its denominator. Count the people whose work the assistant is meant for, not everyone with an account. Someone who covers another queue for part of a shift, or whose role doesn't include the task the assistant supports, lowers the figure. That tells you nothing about the tool.

Judge targets per team or line of business. One blended figure across teams with different work can hide a team that needs help and penalise one whose work fits the assistant less.

Set up the report before the first number

• An eligible-user list with an owner. Connect it to the staffing schedule, so role and channel changes reach it. Decide in advance whether people who move between channels within a day count.
• An agreed definition of use. Name the features that count, and tell team members before the first report, so the numbers and the coaching match.
• Use inside the work, per person. For example, replies written with the assistant out of replies handled in the period, and the date each person last used it.
• Absolute counts beside every percentage. A team lead needs to see that someone used it on 2 of 40 replies, not only a rate.
• Reporting periods that match working days. One fixed daily cut-off can split a local working day or a late shift across two report days. Follow each team over its own days or shifts, and compare teams only over the same complete periods, such as full weeks.
• A route to the data at full rollout. A spreadsheet export that works for a first group can become unmanageable once everyone is on the tool. Agree early how the people who analyse adoption will get the data.

When someone shows zero: a diagnostic checklist

Zero recorded use is a question to check, not proof that someone ignored the tool. Write the order down so every team follows the same path:

1. Eligibility and schedule. Was the person on the eligible list and working in the relevant queue in the period?
2. Access, licence and role. Do they have a licence, and the role or permissions the assistant needs, in the tools they work in?
3. The report itself. Does it capture their activity: the right user, team, features and period?
4. Technical causes. Does the assistant load and work for them? Agree with your IT team and your vendor who checks which causes. Bring the vendor in early when a fault affects several people at once or only the vendor can see its cause.
5. Real non-use. Only now is it a coaching conversation.

Two patterns are worth checking even when no one reports a problem:

• New users. People new to a tool may assume a missing feature is normal and work without it. Check access before they start, and look at their first days of usage data.
• Missing use where it should be highest. Low use on exactly the requests the assistant was designed for can mean people skip the AI step and handle the case manually. Team members who also use a different, unapproved tool may show low use rather than none. Both are conversations for the team lead, not tracking errors.

Use the numbers to coach

The purpose of per-person data is to find who needs help, not to rank people. Limit it to the people who coach, usually the team leads. Tell team members what is measured, who can see it and what it is used for. Check what your privacy obligations and any agreements with employee representatives require before you report use per person. Before you roll a new report out to every team, review a sample with the team leads to check it shows what they need.

Expect habits to change gradually. Start with common, simple cases and move to harder ones once people are comfortable. During rollout, a short regular review of adoption by team, with a named owner for each team's follow-ups, keeps open questions from waiting.

If you expect people to use the assistant, say for which tasks. An expectation tied to the work where the assistant saves time is easier to follow, and to coach against, than a general instruction to use it. Then name who owns adoption after rollout in your operating model.