AI introduced but barely used: where is the barrier?

Access initially only proves that a tool has been provided. A login shows an interaction. Neither says much about whether a relevant task is completed more easily, reliably or quickly. Conversely, occasional use for a demanding task can make more sense than daily use without a usable result.

Before judging a low usage figure, therefore name the intended work case. Should the tool, for example, structure drafts, help access information or prepare routine wording? If the suitable task did not arise during the observed period, low usage would be expected. A blanket usage target would encourage unnecessary activity here.

Critical feedback also needs context. “This does not help me” can mean that someone does not know a feature. It can equally mean that the results need too much correction or that the process offers no suitable point of use. Treat these explanations as distinct assumptions, not characteristics of individual employees.

The useful question is: which business problem do we want to solve with this tool, and what is currently preventing its use? Further spending on licences, training and introduction time depends on this. Costs already incurred are no reason to continue unsuitable applications indefinitely. Equally, a single failed attempt does not justify ending the entire initiative.

Create a brief decision note: desired change, affected task, effort so far, known barrier and next assumption to check. A fictional example would be: “Preparing internal project reports requires a lot of rework. We are checking whether structured first drafts help and which information needs to be reliably available for them.” Such a note remains useful even without survey software.

The OECD discusses opportunities as well as risks and necessary conditions for AI in the workplace. This does not guarantee success for a specific rollout. Your decision needs observations from your own workflow, including the costs of checking and reworking.

Start with clarity: do employees know which tasks the tool is intended for and which limits apply? One possible statement is: “I know which of my recurring tasks I am allowed to use the approved AI tool for.” Anyone who is uncertain here first needs concrete guidance and an accessible contact person.

Use the decision table to make the initial distinction. An unclear task needs guidance; a lack of practice needs support; a lack of opportunity needs a change in the process. Only explore the point that stands out in more depth. This prevents a general catalogue of questions from producing more feedback than you need for the next decision.

A clear task can still be unsuitable. Perhaps the required data is not approved, results vary too much or additional checking exceeds the effort saved. Such objections are professional input. More motivation or a mandatory activity day does not automatically resolve them.

Other barriers arise from conflicting expectations. A manager calls for experimentation but only evaluates short-term throughput. Or a team is expected to develop new processes but is not allowed to change existing steps. Clarify these goal conflicts with the people responsible instead of treating them as a lack of openness within the team.

Collect specific situations in discussion, but no confidential inputs or work samples containing personal data. For an initial overview, it is often enough to ask: what category of task was affected, what was the obstacle and what next step would be possible? Free text can make people identifiable. Therefore, agree on a suitable framework for feedback in advance.

If the limits of use are unclear, create a brief task overview with permitted applications and contacts. If checking results is difficult, practise using an approved, non-sensitive example. If opportunity is missing, plan a realistic trial in the actual process. If the task is unsuitable, choose another or end this use case.

Where possible, change one clearly identifiable part of the approach before adding further actions. This is not a controlled experiment, but it makes interpretation easier. If the tool, tasks, training and responsibilities all change at once, it becomes difficult later to identify which next step is needed.

A fictional team understands the value for project reports but runs into missing source information. Another prompting workshop would not close the information gap. A suitable action could be a standard input template. Afterwards, the team checks whether the information is available and the drafts need less rework.

Before taking action, define when a meaningful new observation period will end. Base this on how often the task occurs and the time needed for testing. Weekly feedback can keep the initiative present, but it should serve a current decision need. If a use case is only rarely needed, a lack of experience should remain visible as such.

Repeat a suitable statement with the same wording and scale. If needed, add “Unable to assess”. A non-rating must not count as a low value in the average. At the same time, record whether the action actually took place and which other changes shaped the period.

Separate the results into three levels: was the prerequisite established? Is the application experienced as helpful in everyday work? Does the relevant process improve? Feedback mainly answers the second level. For the third, you also need suitable process observations, such as professionally reviewed work samples or documented reworking effort without ranking individuals.

Continuing is plausible when the use case remains relevant and several observations suggest a usable application. Adjusting makes sense when a specific, addressable barrier remains. Stopping or narrowing the scope is a reasonable decision if the task is unsuitable or checking effort repeatedly consumes the benefit.

A survey can support this decision, but cannot demonstrate financial ROI on its own. A higher agreement score is not a euro amount. More frequent use is also not proof of better results. Compare effort and quality with a clear baseline, and state openly which changes occurred at the same time.

Give the team a brief response on the decision: what have we understood, what will we change and what will we check next? This turns the survey into a visible action. Employees do not have to keep reporting the same unresolved issue while those responsible simply file another report.

First choose a clearly defined work case and a person responsible. Write down the suspected barrier, check it with a suitable question and a look at the process. Agree on a small action, a review point and the decision to be made then. This framework prevents a stalled rollout from prematurely becoming a large culture programme.

Our article on using AI in everyday work helps with suitable applications. For more detail on questions and comparability, see measuring AI adoption. If the issue is transfer into practice after training, the article on reviewing AI training in everyday work complements this diagnostic approach.

EngageBeat Fokus can make recurring feedback on custom questions and AI topics visible. This helps narrow down rollout barriers and ask again about experience after an action. You also assess process quality and business value using your workflows. AI adoption with EngageBeat shows a suitable starting point; confidentiality explains the framework for feedback.