The most common failure in enterprise AI is not technical. Licences are bought, a handful of people become genuinely fast, everyone else tries it twice and returns to how they worked before. The capability never becomes organisational, and the spend cannot be justified at renewal.
AI adoption is the work of closing that gap deliberately — training people by role, giving them approved patterns that already work, and measuring whether it stuck.
What Adoption Work Involves
- Role-based training — what an engineer needs is not what finance or support needs. Generic training is why generic adoption fails.
- Approved-use policy — clear guidance on what may and may not go into which tool, written to be understood rather than to protect a policy team.
- Prompt and workflow libraries — the good pattern one person worked out becomes the one everyone starts from.
- Office hours and champions — support at the moment people get stuck, which is when adoption is actually won or lost.
- Governance — who can connect what, and how new tools get approved.
- Measurement — usage and outcome tracking, so you know whether capability is spreading or a few people are carrying the numbers.
Training on the Tools You Actually Use
We train on Microsoft Copilot and Copilot Studio, Claude and Codex for engineering teams, and the custom agents we build for you — because training on a generic assistant does not transfer to the tool on someone’s desk.
Distribution Is the Other Half
Training tells people what good looks like; distribution puts it in their hands. That is the problem our Desktop AI Skills and Workforce Manager is being built to solve — approved skills, instructions and connections delivered centrally rather than rebuilt by each person.
Tell us where adoption has stalled and we will design training and governance around how your teams actually work.
Related services
- Agentic AI Consulting and Implementation — Related: agentic AI consulting.
- Microsoft Copilot Studio Development — Related: Microsoft Copilot Studio.
When Adoption Work Applies, and When It Is the Wrong Spend
Adoption work assumes the tools are already in place and the problem is what people do with them. The test is mechanical: are licenses assigned to the people in scope, and does the tool open and authenticate on their machines. If the answer is no, the problem is deployment, and training scheduled ahead of it turns the first session into access troubleshooting.
Training changes what someone can do. It does not by itself change what they reach for on a Tuesday under deadline, and those are separate problems with separate fixes. Where the gap is capability, a session closes it. Where the gap is habit, the engagement has to be designed around the weeks after the session rather than the session itself, with follow-up scheduled rather than offered, and the session judged by whether people used the pattern on live work in the days following rather than by attendance.
- Right fit: licenses are assigned, the tool is reachable, and the work being done with it is real but narrow.
- Wrong fit: access is not provisioned, the tenant is not configured, or the connector to the system people need does not exist yet. That is build and deployment work.
- Wrong fit: one team with one workflow. Write the workflow down, hand it over, and skip the program.
- Wrong fit: the underlying process is contested independent of AI. Speeding up a process nobody agrees on produces faster disagreement.
Breadth and Depth Need Different Work
Shallow use across many people and deep use by few are not the same failure, and the remedies do not substitute for each other. Shallow-and-wide is usually a permission question: people confine themselves to low-stakes tasks because nobody has told them where the boundary is, so the work is policy clarity and role tracks that name the tasks a role is cleared to do. Deep-and-narrow is a visibility question: working patterns exist but live in a few people's heads, so the work is capture, review, and a place to put them, backed by direct support for the people trying to use them.
These two remedies compete for the same budget and the same calendar, which is why choosing wrong is expensive rather than merely slow. Role tracks delivered to a population that already knows what it is allowed to do produce attendance and no change. Library work aimed at a population that has not started produces a library nobody opens.
What the Engagement Depends On From You
Most of what determines whether this works is on the client side and cannot be supplied by us. The one that matters most is real work: role tracks built on invented tasks end up teaching the same material to everyone, with different job titles in the examples. The rest is access and a decision maker who can answer questions without a committee round trip.
- A named owner who can approve what data may go into which tool, and who is available while the work is running.
- Admin-side visibility into how the tools are licensed and configured, including which connectors are already enabled.
- A small number of real, repeated tasks per role, with the real inputs, not cleaned-up versions of them.
- Calendar time for the people being trained. This is the constraint that slips most often.
- A decision about what happens to patterns people build: who reviews them, where they live, who is allowed to publish them.
Written Material Goes Stale, Which Is the Real Maintenance Problem
The libraries are the part of this that decays. A pattern written against one tool's behavior can stop producing the same result when the model behind it changes or when an administrator turns off a connector it quietly relied on. Nothing announces the change. The pattern just gets worse, people notice it is worse, and confidence in everything published drops faster than the actual breakage warrants.
The handling is unglamorous. Each published pattern names an owner and records the tool and configuration it was written against, and the ones that depend on a specific connector are listed so an admin-side change has a known blast radius. The approved-use policy gets the same treatment: it is written to be reopened when a new tool arrives, with the reasoning visible, so the next person can tell whether a rule still applies or was answering a question that no longer exists.
Frequently Asked Questions
What does an AI adoption engagement actually deliver?
You keep four things: written role tracks tied to the tasks each role really does, an approved-use policy your own owner has signed off on, a library of working patterns stored where the people who need them already work, and an agreed way of checking whether use is holding. The sessions are the delivery mechanism, not the deliverable. It is not a software purchase, and it is not a substitute for building agents or connectors, which is separate work with its own scope.
Do we have to install anything for the training itself?
No. The training runs against the tenant, licenses and machines you already have, and installs nothing on anyone's desktop. What sometimes comes out of a session is that a needed agent or connector does not exist yet, and that is build work with its own tenant admin steps, approvals and scope. We keep it separate rather than folding it into a training day, because the approvals it needs run on a different clock than a calendar of sessions.
What has to already exist before the first session?
Licenses assigned to the specific people in scope, the tool opening and authenticating on their machines, a named person who can answer data questions, and a decision about which roles go in the first pass. If any of those are missing the first session is spent on them instead of on the work. We check access and configuration before scheduling for exactly this reason.
How does a rollout proceed, in order?
Access and configuration review first, then role scoping and collection of real tasks from the people in those roles. The approved-use policy is drafted and signed off before any session runs, because unanswered questions about what is allowed will otherwise dominate the room. Sessions follow by role, patterns are captured out of the sessions rather than written in advance, and support runs in the weeks after while people are applying it. Measurement is agreed at the start and reviewed once there is enough use to read.
How does this fit with the systems we already run?
It works through your existing paths rather than standing up parallel ones. Your identity groups define who belongs to which role track, your admin console remains the control point for what the tools can reach, and your help desk absorbs the questions once direct support ends, which is why its people are trained early. Where a line-of-business system has no connector, that is a build question and we say so rather than teaching a workaround around it.
Where does our data go, and what stays under our control?
Sessions run on your material inside your environment, and we do not take a copy out of it. The judgment calls stay with your named owner; our job is to make the decisions explicit and write them down so they can be applied consistently after we are gone. If any part of the work would require material to leave your environment, we identify it first and it is agreed before it happens. The libraries and policy documents live in your tenant and remain yours.
What do we have to decide that you cannot decide for us?
Which roles go first, which classes of data are acceptable in which tool, who owns the pattern library, and whether review of new patterns is central or sits with each team. We can draft all four and recommend an answer for each. The sign-off has to be someone inside your organization, because a use policy owned by an outside party is not something your managers can enforce.
Can the Desktop AI Skills and Workforce Manager be part of our rollout?
No. It is still in development, it cannot be bought or deployed, and no part of an adoption engagement depends on it. It is designed to publish through the same managed-software approval path an IT group already uses, with a named owner approving what goes out and to which groups, so nothing reaches a desktop without passing that review. Until it exists, distribution is manual, using your tenant's own sharing and whatever route your help desk already uses to push standard configuration.