Getting your team from "we have Claude" to "we use Claude"

Why implementations fail

Almost never because the AI wasn't good enough. Only 35.8% of employees with Copilot access actually use it, against 83.1% for ChatGPT over the same period (Recon Analytics, January 2026), and that gap isn't a capability problem. It's usually one of three things: nobody mapped the actual workflow before turning the tool loose on it, the first use case was too big to finish in a day, or there was no one specific person accountable for making it stick past week one.

The tool was never the problem. The workflow was.

An implementation that works starts narrow, on purpose. One real use case, one team, one visible result, before anything gets rolled out wider.

The three-layer method

Every real business process breaks into three layers, and treating all three the same way is the single most common implementation mistake:

• Workflow: the actual sequence of steps a task follows today, written down, not assumed.
• Automation: the repeatable parts of that sequence, fixed and rule-based, that don't need a person or an AI's judgment at all.
• Agent: the parts that genuinely need judgment, handed to Claude or Copilot with a clear goal, checked by a person at the right point.

Map the workflow first. Decide what's actually repeatable versus what needs judgment second. Only then decide what gets built as an agent versus a simpler automation. Skipping straight to "let's build an agent" is how implementations end up expensive, fragile, and abandoned.

Before you build: the readiness checklist

• One named use case, written in a single sentence a non-technical person understands.
• One team, not the whole company, for the first pass.
• One person accountable for the use case still working in 30 days, not just on day one.
• Access to the real tools and data the workflow actually touches, confirmed in advance, not discovered mid-session.
• A defined "done": what does a successful first version actually produce.

If more than one of these is missing, fix that before a build day gets booked. It is cheaper to sort out now than mid-session.

Running the implementation day

The best implementation sessions are boring in the best way: build the real thing, with the real team, on the real data, live. Not a sandbox example that gets thrown away, not a demo that impresses in the room and gets forgotten by Friday. The team leaves having built the thing themselves, with someone experienced in the room the whole time, not just kicking it off and coming back at the end.

Teams don't watch a demo. They leave with something working.

What "done" looks like

Not a working prototype. A working prototype that someone on the team actually opens again the following Tuesday without being reminded to. The real test of an implementation isn't the demo at the end of the session, it's whether the thing gets used the week after nobody's watching.

• The person accountable for it can explain what it does without notes.
• It's been used at least once on a real task, not a test case, within 48 hours.
• There's a plan for what happens when it breaks or the data changes.

Common mistakes

• Starting with the whole department instead of one team.
• Choosing the use case for how impressive it sounds instead of how real and repeated it is.
• No one person accountable once the session ends.
• Reaching for an agent when a simple automation would do the job for less cost and less to maintain.

Next steps

This guide covers implementation. Training That Actually Transfers covers the session itself, and What Real Adoption Looks Like at 90 Days covers what to check after. All three are free to read, and the Lexicon defines any term in them you're unsure of.