Most Claude Enterprise rollouts are planned as a licence event: pick the teams, turn on access, schedule training. The licences go live on time. What changes afterwards is usually much less than anyone expected.
The reason is not the model. A rollout that ends at access has only solved the problem of who can use Claude. It has not solved which work should change, who owns that change, or how anyone will know it happened. Those are the questions that decide whether the investment returns anything.
This guide is the sequence we use with enterprises. It has five stages — enable, observe, discover, build and scale — and each one has an exit condition. You can stop after any of them. What you should not do is skip one, because every stage produces the input the next one depends on.
Before stage one: decide the rules
A small set of decisions has to exist before access goes wide, because they are much harder to make once people have formed habits. Which surfaces are approved: Claude apps, Claude Code, the API, and each MCP server separately. Which classes of data may reach the model at all, and which must be redacted first. How audit logging and retention are configured. Who approves a workflow before it goes live, and who can switch it off.
None of this needs to be elaborate. It needs to be written down, because the alternative is that every user invents their own answer.
What to decide before Claude licences go wide
Stage 1: Enable
Train people by role, on their own work. A finance analyst and a support lead use Claude for different things, and a generic session serves neither of them well. The useful output of training is not a feedback score; it is people using Claude on real tasks the following week.
Engineering teams need their own track. Individual engineers on Claude Code get faster quickly, but the team only gets faster once there is a shared standard: conventions the agent reads, shared skills, hooks, and an agreed review bar for agent-written code.
Exit condition
People are using Claude on real work — not practice exercises — in the teams that were trained.
How to roll out Claude Code to an engineering team
Stage 2: Observe
This is the stage most rollouts skip, and the one that most often explains why they stall. Once people are back at work, someone has to watch what actually changed: which tasks moved to Claude, which did not, where people hesitated, and where the real process differs from the documented one.
The documented process describes the intended path. The real one is full of workarounds people built to survive it, and the workarounds are usually where the time goes. You cannot find those from a survey. You find them by sitting with the teams.
Exit condition
A written picture of how the work runs today, including the workarounds, for the teams in scope.
Why Claude adoption stalls after training
Stage 3: Discover
Turn what you observed into a ranked list. For each candidate workflow, estimate how often it runs, how long it takes, what a mistake costs, and whether a person can check the output quickly. Two or three will be obviously worth doing first. The rest wait, and saying so out loud is part of the value.
The ranking matters more than the list. Without it, the next decision is made on enthusiasm, and the loudest team gets the first build rather than the one with the best return.
Exit condition
A ranked build queue with an estimate against each item and a named owner for the first two.
Which workflows to give an agent first
Stage 4: Build
Build the top of the queue into production against your own systems. Before anything goes live, write down what a correct result is, build an evaluation set from your own historical cases, and agree the accuracy bar. Decide what the workflow may do on its own and what must wait for a person.
The usual line: an agent may read, retrieve, summarise, draft and propose freely. Anything that posts to a ledger, a payment rail or a system of record, anything that reaches a customer under your name, and anything irreversible waits for a person. Access to your systems goes through MCP servers scoped one per system boundary, so the agent reaches exactly what it was granted.
Exit condition
The first workflow is live, measured against a baseline taken before it changed, with a named owner and a written rollback position.
Guardrails: deciding what an agent may do unsupervised
Stage 5: Scale
Scaling is not turning the first workflow on for more people. It is repeating stages two to four for the next teams, with oversight that keeps up: the evaluation set re-run on every prompt, tool or model change; exception queues and override rates reviewed; and a periodic check of which workflows have earned more autonomy and which should have less.
Exit condition
There is none. Scale is an operating rhythm, not a finish line.
How to tell whether the rollout is working
Seat counts and message volume tell you who opened the tool, not what changed. Better measures: the number of workflows that were redesigned around Claude and what each is worth, time saved on those workflows against their baseline, and — for engineering — how quickly a new joiner reaches a useful contribution.
How to measure Claude adoption, and what not to measure
Where rollouts usually go wrong
Four patterns come up again and again. Training is treated as the finish line rather than the entry point. Nobody owns the workflows, only the tool. Wins happen but are never measured, so they cannot fund the next phase. And the rules are never written down, so a cautious manager quietly discourages use after the first bad output reaches a client.
Each of these maps to a stage above. The sequence exists to make them hard to fall into.
Where Focus20 fits
We run this sequence end to end: role-based Claude training and Claude Code training to enable, adoption consulting to observe and discover, and workflow implementation to build — with the same engineers throughout, so the people who rank the workflows are the ones who ship them. You can engage us for one stage or all five.