Adoption · Operating decision guide
Why do employees work around a technically successful AI tool?
Otomat editorial · Revised
Observe the real task and the extra work the tool creates. Adoption depends on whether users can complete and defend their work, not simply whether they attended training.
Watch a fresh task, with consent
Ask a representative user to complete an ordinary case and an exception without the builder taking over. Record where they leave the tool, copy results into another system or ask a colleague for help. Treat that as evidence about the workflow, not a reason to blame the user. A shadow spreadsheet may exist because the new system lacks an approval record the employee needs.
Include the work that moved
Count checking, correction, source lookup, copying and follow-up. If a new assistant cuts drafting time but doubles review, the apparent gain may disappear. Ask which outputs users trust, which they verify and why. Preserve a safe way to report errors; hiding workarounds makes the system look more successful while weakening the evidence needed to improve it.
| Check | Evidence to bring | Decision or stop condition |
|---|---|---|
| Observed detour | Task, step, reason and time outside the tool | Fix the underlying dependency before treating it as a training failure. |
| Transferred effort | Review, copying, exception and follow-up work | Count all affected roles in the before/after comparison. |
| Independent task | Primary and backup complete fresh cases | Keep support in scope until the acceptance exercise passes. |
| Management change | Responsibility, escalation and measurement agreed with staff | Do not infer a staffing outcome from task exposure. |
Change the task before repeating the course
Fix missing permissions, unclear escalation, unreliable source selection or a disconnected handoff before prescribing more training. Then practice the changed task with a primary user and a backup. Define what competent independent work looks like, including when to stop. Attendance and a positive survey are useful context but do not establish operational independence.
Let management own the redesign
Explain which responsibilities change, what review remains and how performance will be measured. Discuss the proposed change with the people doing the work. Do not equate a model’s technical ability with a staffing decision. Compare accepted tasks and total effort over a representative period, and keep the prior safe process available until the new one is accepted.
Questions before the decision
Is low adoption always resistance to change?
No. It can indicate missing access, unreliable outputs, extra review work or a process the tool does not cover. Observe the task before choosing the remedy.
What should a training assessment include?
A fresh ordinary case, an exception, a correct refusal and a recovery step, completed by the user without the builder operating the system for them.
Take the evidence sheet to the meeting
Download the blank CSV, assign an owner to each check and record the evidence. Keep completed sheets in your own approved system.
Download the evidence sheet (CSV)Use the working tools
Blank templates are ungated. Adapt them to the workflow; inputs are not submitted.
Sources and limits
These are Otomat’s proposed operating methods and original decision artifacts. External references inform risk management; they do not certify this method or establish client results. Linked sources were selected for this review; their live revision dates may change.
- ILO: generative AI and jobs, 2025 update (task exposure, not staffing forecasts)
- NIST AI RMF: governance, measurement and risk management context
For anonymous documentation and proposal patterns, see delivery evidence and its boundaries.
Related decisions
Bring a workflow to the discussion
Share the business goal and constraints through the mandate process. Do not send sensitive production data in the initial brief.
Book a Return Review