--- name: adoption-and-scale description: Help people develop, use and spread valuable AI work through existing products or deployed workflows. Use for hands-on team enablement, reusable working practices, adoption diagnosis, changed responsibilities or expansion across teams and organizations. --- # Adoption and Scale Help an organization discover useful ways to work with AI, develop the ability to use them, and spread the practices that improve its work. Adoption can begin with an enterprise AI product available to the workforce, an employee's local invention, or a purpose-built workflow entering operation. Treat these as different entry points, not a maturity ladder ending in custom software. For broad platform adoption, discover what people do, what they could do differently, and which available capabilities help. For a particular deployment, examine how it changes work and why people use, bypass, or abandon it. In both cases, the aim is valuable work that the organization can sustain and improve. When asked to execute an adoption program, carry out the authorized exploration, demonstrations, practice, and asset development rather than returning only a training plan. ## Choose the work that advances this assignment Read the relevant guidance for the requested result; a team session does not need an expansion plan. - For existing AI access, employee invention, a small team's reusable method or practical enablement, read [workforce practice](references/workforce-practice.md). Produce and try the working material the team will use. - For a particular workflow that people need to adopt, or use that has stalled, read [workflow adoption](references/workflow-adoption.md). Investigate the task and the people's incentives before prescribing training. Its worked warranty example shows how misleading time savings become a targeted service change and a practical role exercise. - For a capability ready to reach another population or account, read [expansion](references/expansion.md). Examine what transfers and the next constraint. Combine these when the assignment spans them. Keep any requested format, scale and division of work. In any mode, consider the time, friction and incentives around use. If people cannot make a promising practice part of their work, the [role and workflow diagnosis](references/workflow-adoption.md) can help even when they use a native AI product rather than a custom service. ## Choose how the practice should work Choose the form of adoption from the work. Native AI product practice can be sufficient when a person can supply the relevant context, initiate the work, judge the result, and complete the action within a manageable flow. A well-designed reusable instruction, skill, agent, or workspace may make that practice teachable and consistent. A formal integration is worthwhile when repeated context assembly, handoffs, access boundaries, or transactions materially limit the outcome. Work that must persist, react to events, coordinate people, or act unattended needs corresponding state and operating arrangements, whether supplied by a maintained product or built for the purpose. Do not make custom development the reward for a successful experiment. First discover whether supported product behavior can carry the improved workflow. Equally, do not keep forcing an agentic process through a personal chat when its value depends on durable shared work or enterprise actions. Explain the boundary that changes the solution, and move the promising case into technical design when it needs engineering. ## Develop practical competence Teach people to frame a worthwhile task, supply usable context, delegate meaningful work, judge the result, and improve the approach through feedback. Hands-on role enablement should develop this judgment, not just familiarity with controls or prompt phrasing. Let a participant move from asking for a summary to commissioning an investigation, comparing explanations, developing alternatives, or maintaining a useful work product where the task warrants it. Use worked cases that expose the judgment: a convincing but incomplete answer, a correct recommendation that conflicts with an outdated local habit, an ambiguous case that needs more information, and a case the system can handle with little intervention. Show how an expert reasons through the choice. Teaching only failures can produce blanket distrust; teaching only successful demonstrations can produce overreliance. Observe people performing representative work with the service. The useful question is whether they can reach an accepted outcome and detect the mistakes that matter, including when to ask for help. Use the difficulty they encounter to improve the interface, task design, or instruction. Do not assign a training problem to an operator when the system makes the right action unnecessarily obscure. Build a succession path. Have the customer team onboard a new colleague, revise a job aid, handle a failure, and explain a behavior change. Capture reusable domain procedures where they can be maintained and used by the service. Skill development should leave the customer able to extend the capability, rather than dependent on a visiting specialist's prompts or tacit knowledge. ## Learn whether the work improves Trace enough of the case journey to explain loss of value: eligible work, attempted use, completed work, downstream acceptance, time and effort, and the resulting service outcome. Choose measures that answer the current decision. Login frequency says little about an infrequent but valuable expert task. A high acceptance rate can reflect genuinely good results, trivial selected cases, or reviewers who stopped checking. Measure displaced and newly created effort, including review, escalation, maintenance, and work in downstream teams. Compare similar populations and periods. Where practical, stagger introduction or use a suitable contemporaneous comparison; account for differences in case selection and for practices spreading to the comparison group. For new coverage, examine who receives a service they previously lacked, whether they use its result, and whether the enterprise can continue providing it. ## Sustain useful practice For enterprise product adoption, establish continuing ownership of access and enablement, maintained shared assets, hands-on support, and the path from an employee's promising invention to a supported workflow. Let the central team learn from local practice and help employees discover relevant capabilities as they change. Retire stale guidance and unsuccessful assets so the internal library remains useful. For deployed workflows, put day-to-day operation, domain policy, technical change, and benefit realization with people who can act on them. One person may carry several responsibilities in a small organization; a large enterprise may need a clear arrangement across existing teams. The purpose is to ensure that a change in the business can become a controlled change in the service. Use the organization's normal operating cadence where possible. Examine unresolved work, meaningful failures, operator corrections, resource demand, and the value of possible improvements. Make release communication explain what changed in the task and what the operator should do differently. Avoid a parallel AI governance routine that produces meetings without improving the work. End with the action supported by the experience: spread a useful practice, develop a promising workflow, reshape a service, fix a constraint, retire redundant work, or discontinue a poor fit. Produce the material needed to carry it out, such as a working shared skill or agent, a hands-on role session, a revised job design, or an expansion proposal. Successful adoption leaves people better able to perform and reimagine valuable work, and the organization able to sustain, share, and develop that capability.