Employees are not using their AI subscriptions: how to find the cause and adapt adoption

A company pays for an AI service, holds an introductory session, and a month later sees that most licences were barely opened. The manager’s first reaction is understandable: motivate people. Before that, find out what is getting in the way.

Low use should be explained before it is changed. The tool may not fit real work; employees may not know which data they can upload, how to check an answer, or what personal value it offers. A practical approach is to choose one recurring workflow, train people on their own examples, remove specific obstacles, and measure useful outcomes rather than prompt counts.

Be ready to accept any diagnostic result, including cancelling unused licences or abandoning a poor use case. This guide helps you choose a workflow, decide what to check with the team in a week, and distinguish real benefit from activity for activity’s sake.

Five reasons a paid AI tool sits unused

When people ignore a new tool, it is easy to call it “resistance to change.” That puts the problem on employees. It is more useful to check five concrete causes.

No relevant use case. Someone asks a general question, gets a general answer, and returns to familiar work. They cannot see how AI helps with their weekly sales report, customer complaint, or proposal.

The output needs rewriting. If corrections take as long as writing from scratch, declining to use the tool is rational, not laziness.

Fear of data exposure. A manager does not know whether a customer contract, price list, or CRM export can be uploaded. Without a clear rule, a cautious person uploads nothing.

Missing skills. Giving the model a usable task and checking its answer are separate skills. One introductory presentation does not teach both.

No time to learn. Early attempts can be slower than the familiar method. With a full schedule, employees will not experiment at the expense of deadlines.

Access and use are different. A six-month field experiment across 66 firms included 7,137 knowledge workers and an assistant integrated into familiar email, meeting, and writing applications. About 80% of those given access used it; in the second half of the experiment, users spent around two fewer hours per week on email. Researchers did not find a change in the number or composition of workers’ tasks. This is a result for one tool under specific conditions, not a forecast for your company. Assigning a licence does not guarantee use, and use alone does not mean the workflow changed.

A short diagnosis without ranking employees

Diagnosis should not become a search for someone to blame. Do not publish usage rankings or compare departments by app opens. The goal is to find which of the five causes applies to your team.

Interview about the last real task. Ask an employee to recall a specific task from last week that took a lot of time. What did they do? Where did they look for information? Did they try AI, and what went wrong? A concrete example is more useful than “Why don’t you use the tool?”

Observe the workflow. Half an hour with someone preparing a report or answering a customer can reveal more than a survey: switching systems, copying by hand, and points where work stops.

Check access. Has everyone signed in to the company account? Are the necessary data sources connected? Does the person know where the allowed-data rule is? Sometimes the licence is assigned but setup was never completed.

Aggregated administrator data can help identify where to look. Reading employees’ messages to “measure engagement” is not appropriate: covert monitoring damages trust and, depending on jurisdiction and internal rules, may create legal risks.

Pick a first use case that is frequent, clear, and safe

After diagnosis, choose one use case—not everything AI might possibly help with. A good first workflow:

• happens at least weekly, so the employee can build a habit;
• has a clear definition of an acceptable result;
• has moderate risk, with mistakes caught before they affect a customer or accounting;
• uses only data allowed by company policy for the selected service.

Examples include drafting a weekly summary from permitted internal data, preparing a first draft for a common customer question with mandatory manager review, or structuring meeting notes. Poor first candidates include legal conclusions, unchecked customer emails, and calculations used by accounting.

Teach the work, not just a separate course

A general prompting course may not change daily work: employees return to their tasks and cannot transfer a training example to their own report. Put learning into the workflow:

1. Break down a real recurring task into steps.
2. Show a good input: the data, context, and format the answer needs.
3. Check facts, figures, tone, and customer commitments together.
4. Save a successful instruction as a shared template.
5. Assign a colleague whom employees can ask when the output fails.

Surveys of employers and workers in finance and manufacturing across seven countries found that training and consultation with workers were associated with better outcomes for workers. This is an observed association, not proof that any training guarantees success. It supports a practical lesson: involve the team in choosing and setting up use cases rather than merely announcing a new tool.

Support and feedback after launch

Without support, even a good use case fades. Templates become outdated, new task types appear, early mistakes go unreviewed, and people return to the familiar method.

• Use-case owner: a named person maintains templates and rules and decides what changes. This need not be a new job, but the responsibility should be written down.
• Error channel: a separate chat or form where employees can share a bad result without fear of blame.
• Template updates: the owner reviews cases weekly or every two weeks and revises instructions.
• Protected time: schedule time to learn during the first weeks instead of expecting people to use spare moments.

Voluntary AI risk-management practices encourage clear roles, measurement, and responses to risks. They are not a mandatory training format or ready-made policy, but they help define who decides, who checks, and who responds when something goes wrong.

An educational example: a four-week pilot

This is a plan to adapt, not a proven approach with guaranteed results.

A sample obstacle table for week one:

What counts as successful adoption

It is easy to increase the number of AI prompts without creating value. Set a quota and people may ask meaningless questions to make the metric look good. Measure the workflow instead:

• Repeat use on a real task: does the person reuse a template for the same task a week and a month later without reminders?
• Output quality: how many edits does the reviewer make, and are factual errors appearing?
• End-to-end time: the full path from starting the task to a ready document, including review.
• Employee feedback: is the work clearer, or has review created a new burden?

App opens and prompt counts are diagnostic signals only. A drop in one department’s use is a reason to talk, not issue a reprimand.

A negative pilot result is still a result. If the use case provides no value after four weeks and the team agrees, closing it and reallocating licences is more honest and cheaper than maintaining the appearance of adoption.

What to do in your workflow

1. Choose one weekly task and measure its current end-to-end time, including review.
2. Hold three to five short interviews about recent real tasks and sort the answers across the five causes.
3. Write one data rule for the use case: what may be uploaded and through which account.
4. Assign a use-case owner and an error channel.
5. Record quality and time criteria for continuing, changing, or closing the use case.
6. After four weeks, compare with the baseline and decide what to do with the licences.

Frequently asked questions