AI licences with no adoption: what to do instead of buying seats for everyone

On-Off Group

September 2026

Instead of buying an AI licence for everyone and hoping people use it, start with one real task, give seats to the people who do that task, and measure the work before and after so you can tell if anything changed.

This is for anyone paying for AI licences across a department who cannot show what changed because of them. The seats are paid for and the usage report is thin. Seats bought, logins created, and the same work being done the same way.

Here is a different order to do it in. Pick one real task first. Get a before number for it. Then buy only the seats the people doing that task need.

None of this needs a new budget cycle. Most of it is two weeks of work with people you already have.

What the usage report actually looks like

The normal version goes like this. A block of licences handed out across operations, marketing and digital. Month one, a spike as people log in and try the thing. Month three, a handful of daily users, most of them the two people who would have found the tool anyway.

Nobody lied. The training happened. Attendance was good. The feedback scores were fine. A full room and a good score tell you people showed up, but that's it...

The gap is that nobody tied a licence to a task. Ask someone in the room what they will use it for on Monday and you get an honest shrug, because their Monday is a queue of approvals, an underwriting check, a batch of customer emails, and none of those were in the training.

So the tool never gets used on the work people actually have in their queue.

Pick one task, not one department

Instead of licensing a department, pick the first real task you will use AI on. One task. Named, with a person's name next to it.

Good candidates are the ones people complain about without being asked. Drafting the reply to a complaint. Summarising a claims file before the review call. Pulling the weekly turnaround time report together by hand. Checking documents for missing fields before onboarding goes to the branch.

Bad candidates are anything described as "improving productivity" or "ideation". Nobody has that on their list for Tuesday.

Then watch the task being done now, once, with the person doing it. Not a workshop about it. Sit with them. Count the steps, count the minutes, note where they wait for someone else. Often the waiting between steps is what is slowing the task down, not the typing. That is worth knowing before you pay for two hundred seats.

Get a before number or you cannot prove anything

Most companies have no baseline. "Did it work?" gets answered with a shrug, and the shrug is what gets you a slide pack instead of a decision.

The before number does not need to be clever. Pick one:

Turnaround time on the task, start to finish, measured over a week.
How many of the tickets or applications get reworked.
How long a person spends on it per day.

Write it down with the date. Tell the team you are measuring, so the number is not a trick.

This is the part people skip because it feels slow. It takes a few days and it is the only thing that makes the after number mean something. On a series of five-day design sprints with a large insurer, customer journeys that had taken six months or more were designed and tested with customers in two weeks and live in four. Twenty-six weeks down to four. Completion rates on the new journeys rose 80 per cent. Those numbers exist because the client measured the old journey first. Without the before, all you have is a nice-looking new screen.

Fix the task before you automate it

AI on a broken process automates the failure. If onboarding bounces between the branch and a central team three times because the form asks for the wrong thing, a chatbot in front of it makes the bouncing faster.

So look at the task with fresh eyes before you point a tool at it. Where does work get sent back? What is being retyped from one system into another? Which approval is there because of a rule nobody can name any more?

Often one or two of those come out with no AI at all, and the number moves. Good. That is a cheaper win and it makes the AI part easier to judge, because you are no longer measuring two changes at once.

Then apply the tool to what is left. Small, on one task, with the person who does it standing next to you.

Build a rough working version and watch someone use it

Prompt training in a room is fine. On its own it does not change what people do the following Monday.

What works better is building a rough version of the thing and putting it in front of the person who does the task. Not a proposal. A working draft: a prompt saved somewhere they can reach, a simple form, a small tool that takes their file and gives back the summary they need.

Then watch them try it without help. You find out quickly whether it is good enough, faster than another scoping meeting. Usually the first version is wrong in a way nobody predicted, because most ideas arrive written up in a PowerPoint and once you start building, the slides turn out to be wrong.

Five real users on video using the thing will settle arguments the team has been having for a while. Watch the recording with the team. Fix the obvious breakage. Try again.

Buy licences last, and only for the people using them

Once one task has a before number, a rough version people have tried, and an after number, the licence question answers itself. You know who needs the tool, for what, and what it saves.

Then you buy those seats. Then the next task, with its own number, with the people who do that one.

At that point you stop running a push to get people using it. It is a list of tasks with numbers next to them. Some numbers will be small. Say so. Small honest numbers beat big vague claims, and they are the ones your boss can repeat in her own meeting without getting caught out.

To see how a before and after gets measured on a customer journey, there is a design sprint write-up at onoffgroup.com.

What to do this week

Pull the usage report for the AI licences you already pay for. Note how many people used the tool more than twice last month.
Pick one task that someone complains about, and name the person who does it.
Sit with that person for an hour and write down the steps and the minutes. That is your before number.
Build a rough version of the AI help for that task and watch them use it without coaching.
Put the before and after on one page with dates, and stop buying seats until that page exists.

Questions people ask

How do we know if the licences are being used?
Look at the first real piece of work after the training or rollout. Did people open the AI tool for it, and did it help? Login counts and feedback scores only tell you people showed up.

What should we measure?
Take a baseline before you start, such as turnaround time on the task you picked, then measure the same thing after. Without a before number, nobody can answer whether it worked.

Why not roll it out to everyone at once?
Training people are made to attend does not change how they work on Monday, and seats bought in bulk hide who is actually using the tool. A smaller group on one task gives you something you can check.

Where can we see more of this work?
More of what we do with client teams is at onoffgroup.com.

On-Off Group trains teams, tests products with real customers, finds where a transformation has stalled and builds what gets it moving, for banks, insurers and enterprises in the Philippines, since 2015. How we help with ai training.