Adoption starts with the work
AI Change Management for Saudi Organisations
Diagnose low AI adoption through task evidence, role impacts, manager incentives and bilingual support before expanding a rollout.
Low AI usage is a signal to investigate. Employees may be avoiding an unreliable answer, protecting a customer relationship, working around a slow interface or following a manager's existing performance target. Treating every hesitation as resistance can remove the people who understand the workflow from the improvement process.
AI change management helps a Saudi organisation move from an announced tool to a service people can use responsibly. It aligns tasks, decision rights, support, incentives and communication. Training is one part of that work; the larger question is whether the new process makes sense for the people expected to operate it.
Find the point where the new workflow becomes harder
Observe a small number of real tasks with authorised access and appropriate privacy safeguards. Ask employees to show the current process, including spreadsheets, messages and unofficial checks. Then walk through the proposed AI-supported process. Record where work disappears, where it moves to someone else and where a new verification task appears.
The UK Service Manual guidance on user needs starts with understanding the people using a service. Apply that research principle to employees as well as external customers. It is a methodological reference; it does not prescribe a Saudi change programme.
In a fictional facilities helpdesk, an assistant drafts maintenance-ticket summaries. Staff initially appear reluctant. Observation reveals that a summary saves three minutes of writing but adds five minutes checking asset references in another screen. If the previous task took ten minutes, the new total is twelve. The right response is to fix the workflow and evidence display, not demand higher tool usage.
Create a change-impact record for each affected role
| Role | Work that changes | Concern to resolve | Required support |
|---|---|---|---|
| Service agent | Writes less, verifies generated summaries | Accountability for errors in information they did not create | Visible source, correction route and realistic review time |
| Shift supervisor | Handles exceptions and monitors service quality | Unclear threshold for stopping the assistant | Authority boundary and escalation cover |
| Knowledge owner | Maintains asset and procedure information | Additional work without allocated time | Update process and explicit capacity |
| Service manager | Measures completed outcomes and review effort | Legacy targets reward speed over careful checking | Revised measures and responsibility for trade-offs |
For each role, record what is known, what remains undecided and when the organisation will clarify it. Be direct about possible task changes. Do not promise that no role will ever change if leadership has not made that decision. Equally, avoid using vague transformation language to imply a restructuring that has not been proposed.
Resolve ownership through the AI operating model. A change team can facilitate discussion, but it cannot invent authority or capacity that business leaders have not assigned.
Design the first user cohort to reveal real problems
Choose participants who represent the intended work, including different shifts, experience levels and supported languages where relevant. Enthusiastic volunteers are useful, but a cohort consisting only of experts may hide the difficulties that ordinary users will face.
Give participants a clear purpose and boundary: which tasks to attempt, what information may be used, when to fall back and where to report a problem. Keep feedback short enough to fit the work. A practical issue record captures the task, expected result, observed result, impact and whether a workaround was required.
In Arabic and English workflows, test the whole journey. A translated interface is insufficient if the source material, escalation instructions or supervisor response remain in a language the user cannot comfortably work with. Confirm that names, asset references and mixed-language documents remain understandable during handover.
Measure completed work, not just logins
Track the path from eligible task to useful outcome. Define eligibility before calculating adoption: some cases may correctly remain outside the approved scope. Then measure attempts, completions, quality acceptance, review effort and fallback. Do not count mandatory logins as evidence of value.
Suppose an illustrative cohort handles 100 eligible cases. Staff try the assistant on 70, complete the assisted process on 56 and accept 48 outcomes after the agreed quality review. Initiation is 70% of eligible cases, completion is 56% and accepted completion is 48%. These figures use the same denominator. The gaps identify different questions: why some tasks were not attempted, why others were abandoned, and why completed outputs failed review.
Pair these measures with outcome and workload evidence. A higher completion rate can still be undesirable if staff spend excessive time checking or customers receive poorer service. Segment results by meaningful task type and cohort, with appropriate privacy limits. The purpose is to improve the system and process, not to rank employees through unexplained usage scores.
Change manager expectations alongside employee behaviour
A supervisor who is measured only on handling time may unintentionally discourage careful verification. A manager who celebrates every automated case may make fallback look like failure. Explain which behaviours the organisation wants: appropriate use, evidence checking, correct escalation and honest reporting of limitations.
Give managers a short decision guide. When should they coach a user, when should they raise a product defect, and when should they suspend a task? Separate capability gaps from design problems. Sending an employee on another course will not fix a missing source or a slow approval route.
Use role-based capability building for genuine skills gaps. Keep the feedback loop open between frontline staff, service ownership and the team making improvements. Tell users which issue was fixed and which remains constrained; visible responses make reporting worthwhile.
Communicate uncertainty without losing direction
Explain the business problem, the permitted use, the role of human judgment and how people can raise concerns. Use concrete examples from the actual workflow. “The assistant drafts a summary; you verify the asset and urgency before submitting” gives staff more useful guidance than a broad promise to become AI-first.
Separate confirmed decisions from proposals. If support hours, role changes or performance measures are still under review, identify the decision owner and next update. Silence encourages people to fill gaps with assumptions. Overconfident promises create a different problem when experience contradicts them.
For customer-facing changes, coordinate notices and service explanations with the responsible owners. Test whether customers understand what the service does and how to obtain help. The communication should describe the actual journey rather than promote capabilities that the deployment has not demonstrated.
Retire the old process only when the new one can carry the work
Running two full processes indefinitely creates duplicate work and conflicting records. Removing the old route too early can leave users without a workable fallback. Agree the conditions for transition: acceptable service quality, sufficient support, trained role coverage, resolved critical issues and a tested fallback for remaining exceptions.
Document which record becomes authoritative and how unfinished cases are handled during the switch. Give staff a precise transition instruction rather than asking them to choose informally between systems. Keep a controlled fallback where needed, with an owner and review condition.
The pilot-to-production playbook connects adoption evidence to release and operational acceptance. A pilot's positive feedback should be considered alongside actual task outcomes and support demand.
Diagnose stalled adoption before expanding the rollout
If use remains low, distinguish access problems, weak output quality, additional effort, insufficient skill, unclear accountability and misaligned incentives. Use observations and task evidence to identify the dominant cause. A wider launch may multiply the same unresolved problem.
Where the issue precedes the tool, revisit the readiness assessment. For broader organisational blockage, use why AI transformations stall; for a strategy whose assumptions no longer match reality, use the diagnostic checklist. Keep the change plan tied to the specific finding.
Open for AI's agentic AI consulting can help review workflows, authority and readiness. Bring a redacted before-and-after process, user feedback and task-level outcome measures to discuss the obstacles to responsible AI adoption.
FAQ
Your questions, answered.
Why can AI usage stay low after employees have been trained?
Training does not remove slow interfaces, unreliable outputs, duplicate work or unclear accountability. Observe the task and compare the total effort with the previous process. Separate skills gaps from design and incentive problems. The right intervention may be a workflow change, clearer authority or better evidence rather than more introductory training.
Which adoption metric is more useful than active users?
Measure accepted completion of eligible tasks, alongside review effort, fallback and service outcomes. Define the denominator clearly and keep excluded tasks visible. Active-user counts show access or activity, but they do not establish whether the assisted work was completed correctly or whether it improved the customer's experience.
How should managers handle employees who use the manual fallback?
Check whether the fallback was appropriate for the case and approved scope. Correct escalation is a desirable behaviour when the AI service cannot safely complete the task. Investigate recurring fallback reasons and fix the underlying issue. Penalising every manual case can encourage staff to accept weak outputs or conceal problems.
How do we avoid turning adoption measurement into employee surveillance?
Collect the minimum information needed to understand task outcomes and workflow problems, with clear purpose, access and appropriate privacy review. Use aggregate or task-level patterns where suitable. Explain how the measures will be used and avoid unexplained individual rankings that treat cautious review or legitimate exceptions as poor performance.
What should bilingual AI rollout support include?
Include understandable task instructions, source context, correction guidance, escalation routes and supervisor support in the languages used by the workforce. Test mixed-language documents and handovers, not just screen labels. Ask participants to complete real tasks so language gaps become visible before a wider launch.
When is it reasonable to retire the old workflow?
Retire it when the new process meets agreed quality and support conditions, users can perform their roles and remaining exceptions have a workable route. Identify the authoritative record and treatment of unfinished cases. Keep a controlled fallback where needed, but avoid indefinite duplication without an owner or review date.