Most AI adoption plans follow the same arc: a leadership team commissions a strategy document, someone produces a polished slide deck with a phased rollout timeline, it gets presented once at an all-hands, and within two months almost nobody can describe what phase the company is supposedly in. The plan wasn't wrong, exactly — it just wasn't built to be used, only to be presented. An adoption workbook is a different kind of document entirely: something individual teams actually open, fill in, and return to, because it's built around their specific work rather than around a company-wide narrative that never quite touches anyone's actual job.

Why plans fail and workbooks survive

The core design flaw in most adoption plans is that they're written at the wrong altitude — company-wide, strategic, and abstract — for the audience that has to act on them, which is individual teams doing specific, concrete work. "We will embed AI across our operations by Q3" is a sentence a leadership team can agree on in a meeting; it gives a customer support team member absolutely nothing to do on a Tuesday morning. A workbook fixes this by being deliberately narrower and more concrete: instead of one document describing the whole company's adoption, it's a repeatable format that each team fills out for itself, answering the same structured questions about their own specific work.

The four sections every team's workbook page needs

Section 1: What we actually do, task by task. Before any AI tool gets suggested, the team lists their real recurring tasks — not job titles or responsibilities in the abstract, but the actual, specific things people do repeatedly: "draft responses to common billing questions," "compile the weekly sales pipeline summary," "write first drafts of client status updates." This section forces specificity that a company-wide plan never achieves, because it's written by the people who actually do the work, not by someone summarizing it from a distance.

Section 2: Which of these tasks are worth automating or assisting, and why. For each listed task, the team scores it on two simple dimensions: how much time it currently takes, and how repetitive versus how judgment-heavy it is. High-time, low-judgment tasks (the billing question drafts, the pipeline summary) are strong candidates; low-time or high-judgment tasks (a sensitive client negotiation, a rare escalation) usually aren't, at least not as a first target. This section is where the earlier idea of separating mechanical work from real decision-making does concrete, team-level work — it stops "let's use AI for our workflow" from being a vague aspiration and turns it into a short, specific, ranked list.

Section 3: What "actually adopted" looks like for each chosen task. This is the section most adoption plans skip entirely, and it's the one that makes the difference between a workbook that gets used and one that doesn't. For each task the team decides to pursue, they write a concrete, checkable description of success — not "use AI for pipeline summaries" but "the AI-drafted summary requires less than 5 minutes of manual editing before it's sent, at least 80% of weeks." A vague goal produces vague follow-through; a checkable one produces an actual answer four weeks later about whether it worked.

Section 4: What got in the way, reviewed on a fixed schedule. The workbook isn't a one-time form — it has a return date built in, typically four to six weeks after a task is adopted, where the team revisits Section 3's success criteria honestly and records what actually happened, including what didn't work and why. This section is what turns the workbook into a living document rather than a plan that gets written once and never revisited, which is the exact failure mode it's designed to prevent.

Tip

Resist the temptation to make Section 4 a success report. Its real value comes from documenting friction honestly — "the AI drafts were fine on billing questions but consistently missed the tone we use for complaint responses, so we narrowed the task to billing only" is a far more useful entry than a vague "went well," because it's specific enough that the next team filling out a workbook for a similar task can learn from it directly.

A worked example: a customer support team's page

A twelve-person customer support team at a subscription software company filled out their workbook page as follows. Section 1 listed their real recurring tasks: drafting responses to common account and billing questions, summarizing long support threads for handoff between shifts, and writing weekly trend reports for the product team. Section 2 scored these: billing-question drafting was high-time (roughly 40% of a support rep's day) and low-judgment (mostly applying known policy), a strong candidate; thread summarization was moderate-time and low-judgment, also a good candidate; the weekly trend report was low-time but genuinely judgment-heavy in its interpretation, so the team explicitly decided not to automate the interpretation, only the initial data-gathering step feeding into it.

Section 3 set concrete success criteria: for billing-question drafts, "reps report the AI draft needs only minor edits at least 75% of the time, measured by a simple weekly survey"; for thread summaries, "handoff summaries take under 3 minutes to produce, down from an average of 11 minutes, without missing key details flagged in a spot-check by the receiving shift." Section 4, reviewed six weeks in, recorded that billing drafts hit 82% — better than the target — but thread summaries were only hitting the speed goal 60% of the time, because summaries of threads involving an escalation consistently needed a full rewrite rather than light editing. The team's documented adjustment was narrowing the summarization use case to non-escalated threads only, which is precisely the kind of specific, useful correction a vague plan would never have surfaced, because a vague plan never would have set a target concrete enough to miss.

Why this format scales without becoming heavy

A natural worry with this approach is that a workbook per team creates a coordination burden — dozens of separate documents with no shared thread. In practice, the opposite tends to happen: because every team's page follows the identical four-section structure, patterns become visible across teams precisely because the format is consistent. A leadership team reviewing workbook pages across the organization after two months can quickly see which task types are working consistently (drafting tasks with clear policy references, across support, sales, and marketing alike) and which are struggling everywhere they've been tried (anything requiring nuanced tone judgment), which is a far more useful, evidence-based basis for a company-wide adoption narrative than the reverse approach of writing the narrative first and hoping individual teams find a way to fit it.

Common mistakes when rolling this out

The most common mistake is writing Section 1 and 2 collaboratively with leadership rather than letting each team write its own — this reintroduces the exact abstraction problem the workbook format is meant to solve, because a task list written by someone who doesn't do the work daily is never as specific or accurate as one written by someone who does. A second mistake is skipping Section 3's concrete success criteria in favor of a general sense that "it's going well," which makes Section 4's review meaningless, since there's nothing specific to check against. A third is treating a discouraging Section 4 review as a reason to abandon the workbook process itself, rather than what it actually is — the process working exactly as intended, by surfacing a specific problem (escalated-thread summaries needing full rewrites) precisely so it can be fixed, rather than staying invisible inside a vague "AI adoption is going fine" impression that nobody ever tested.

Handling the team that resists filling it out at all

Some teams will treat the workbook as one more form to complete rather than a genuine tool, especially the first time it's introduced, and pushing it as a mandatory exercise tends to produce exactly the shallow, box-checking version this whole approach is meant to avoid. A better opener is to pick one willing team, run their page to completion including the six-week review, and then show the result — including an honest account of what didn't work, like the escalated-thread summaries above — to other teams as a real example rather than a hypothetical template. Teams are far more willing to invest real effort in Section 1's task list and Section 3's concrete success criteria once they've seen a finished example that clearly produced a useful, specific answer, rather than being asked to trust that the exercise will be worthwhile before any evidence exists that it is.

It also helps to keep the first round genuinely small — one or two tasks per team, not a comprehensive list of everything they do. A team asked to fill out Section 1 exhaustively for their entire job function will produce a long, vague list and stall there; a team asked to pick the two most time-consuming, least judgment-heavy tasks they do each week will produce something specific enough to actually act on within days, and a fast first win is what earns the credibility to expand the exercise further.

Building the habit, not just the document

The real output of this exercise isn't the workbook pages themselves — it's the habit of setting a concrete, checkable success criterion before adopting a tool, and actually returning to check it on a fixed schedule. Once a team has done this once, for one task, the format becomes a natural way to evaluate the next tool and the one after that, which is the actual difference between an organization that "has an AI adoption plan" on file somewhere and one that's genuinely, continuously adopting AI as a normal part of how work gets improved.

The AI Strategy and Transformation Playbook includes the full workbook template used in the example above, along with guidance on rolling it out across multiple teams without losing the specificity that makes it work. The book's companion AI Adoption Workbook gives you the ready-to-fill structure directly, and the AI Use Case Prioritisation resource helps a team move from a long list of possible tasks in Section 1 to a short, defensible ranking in Section 2 — the step where most workbooks either gain real focus or quietly try to do everything at once and end up doing nothing well.