What a per-department AI Workflow Design contains: the anatomy of a playbook

When an SME weighs the playbook route — a ready-built AI-adoption method to graft into its processes, instead of consulting rebuilt every time — the concrete question arrives right on cue: but what's actually inside? It's the right question. The difference between a playbook that moves the company and a folder of slides lies entirely in its structure, and that structure is surprisingly recognisable: serious AI-adoption playbooks, the ones published by the organisations that use AI at scale, share the same skeletons. Those who know them can tell in ten minutes an artefact designed to last from one designed for the signature.

It's worth dismantling its anatomy, because it's also the most honest way to describe what we deliver when we say "an AI Workflow Design per department". It's not a marketing term: it's a format with parts, and each part answers a precise question an SME should demand to see resolved.

Two axes, before any content

Every AI-adoption playbook, beneath the surface differences, is organised along two orthogonal axes. Recognising them is the first tool for judging what's put in front of you.

• The navigation axis — how you find "what concerns me". The two widespread choices are by department/role (sales, marketing, operations, administration, HR…) or by phase (pilot → scale → ongoing management). They aren't alternatives: the best formats use the department as the entry point and the phase as an internal label.
• The depth axis — whether and how the playbook places you before showing you the content. At one end a maturity model (usually five levels, with a score per capability) that tells you where you are; at the other a flat catalogue you're left to browse freely. The choice isn't a matter of taste: it changes who the playbook manages to serve.

Keeping these two axes in mind, the two most instructive public examples show opposite combinations — and together they cover almost everything an SME should expect to find inside.

Model A — the "pillars and phases" playbook (GitHub's example)

GitHub has made public its internal playbook for building an AI-powered workforce. It's the archetype of the browsable-by-phase format, and it's useful because it's designed to drive adoption, not to impress. Three parts deserve attention, because they are exactly the ones an SME should find again, at a reduced scale, in its own playbook.

• Eight founding pillars. Not use cases, but the conditions for use cases to take: leadership sponsorship, a clearly responsible person (a point person, not a committee), written policy and guardrails, training, metrics, the internal "champions" who spread the use from the bottom up, the right tools, communities of practice. It's the part a weak playbook skips — and it's the reason its use cases then fail to take.
• A three-phase rollout, with a horizon at each phase. First 30 days = foundations (sponsor, point person named, usage policy in draft, metrics instrumented). First 90 days = momentum (champions programme, communities of practice, resource hub, first success stories). Then, ongoing = scale (train the trainers, return dashboard). A playbook with a when next to each "what" is designed to be executed; one without timelines is designed to be read.
• Two reusable mechanics. A tiered tooling system — vetted (approved) versus allowed but not yet vetted — so people know what they can use without asking every time; and a three-stage metrics funnel: first the breadth of adoption (how many use it), then the depth of use (how much and how), finally the correlation with a business outcome. Measuring the last stage without the first two is the most common way to tell yourself an ROI that isn't there.

Model B — the "maturity levels" playbook (Microsoft's example)

Microsoft publishes a maturity model for adopting agentic AI: heavier than free navigation, and precisely for that reason a good reservoir for the parts of governance and role clarity that a self-serve playbook tends to leave thin. Two elements serve as a template.

• Five pillars, five levels each. Strategy and culture, process redesign and value realisation, governance and security, technology and data, organisation and people — each read on a maturity scale. The non-obvious point: a company sits at different levels in different pillars at the same time. It's already the shape of AI readiness — a single average "we're at a 6" hides more than it reveals.
• The split of Center-of-Excellence roles. The model spells out who owns what across five functions: idea gathering and prioritisation; operating model and decision rights (what's managed centrally and what by the departments); enablement and community; standards and reuse (patterns, templates, guardrails); adoption and value signals. It's the ready-made template for the "governance controls" box that a good playbook wires to every workflow.

Microsoft's model is calibrated for the large enterprise: an entire Center of Excellence is out of scale for an SME. But the five functions of responsibility aren't — they all remain necessary. The serious work, for a small business, isn't reducing them: it's compressing them into one or two people who genuinely cover them. The number of heads changes; the list of things someone must answer for doesn't.

The skeleton we recommend to an SME

Putting the two models together and weighting them against the reality of a small business — where a heavy Center-of-Excellence process would contradict the promise of lean adoption — the skeleton we deliver has five parts. This is where "AI Workflow Design per department" stops being a slogan and becomes an index.

• Department-primary navigation. It's the entry point: open your department — sales, marketing, operations, administration and finance — and find the use cases that concern you, not a generic catalogue to filter by hand.
• A phase label on every entry. Pilot, scale, ongoing management: so whoever is already halfway filters to "what comes next" instead of rereading the pilots they've already brought home. It's the phase mechanic of Model A, applied to the single entry.
• No maturity gate on access to the content. The playbook stays browsable — you're not denied the reading until you "earn" a level. But your AI-readiness score appears as a non-blocking recommendation: "open this department first". Maturity as a recommendation signal, not as a paywall.
• A one-or-two-person "AI owner", with five functions to cover. The five Center-of-Excellence functions — idea gathering, decision rights, enablement, standards and reuse, value signals — become a checklist for that one or two people. You keep the rigour, you drop the headcount assumption an SME doesn't have.
• A governance block wired to every workflow. Risk level, impact assessment, controls, human in the loop, oversight: not a downstream formality but part of the design. It's the compliance overlay we describe separately — and the reason why, when we design a workflow, compliance doesn't arrive afterwards.

There's a final part that distinguishes a usable playbook from a nice document: the delivery format. The source of truth stays a structured text — readable, versionable, that can be updated when the tool changes — but to be genuinely used, each department entry needs a light visual asset alongside the prose. A playbook that lives only as a PDF ends up in a folder; one designed to be adopted also hands you how to show it to the team.

What knowing the anatomy is for

The practical reason for dismantling this structure isn't academic. Whether you choose to build a playbook in-house, buy a ready-made one or have someone work alongside you, you now have the index with which to judge the proposal that reaches you: does it have an entry point per department? does it put a phase next to each use case? does it say who answers for what? does it wire governance to the workflow or defer it to later? can it be updated, or is it frozen in a slide? There are five questions, and a serious artefact holds all of them.

It's also, to be transparent, the shape of what we graft: a playbook already built along this skeleton, adapted to your department and taken to production. The first step, though, comes before the playbook and it's free — knowing where to start. Our AI-readiness assessment gives you, in two minutes, a sense of which department is ready and with what controls around it; and if you want to understand how to move from this index to a workflow that runs, here we compared the three routes — course, consultant, playbook — or let's talk, no obligation.

This article is for orientation. The formats cited come from public playbooks and maturity models by GitHub and Microsoft and from industry analysis: they are reference templates, not prescriptions valid for every company. Structure, phases and roles must always be adapted to the size, the data and the context of the individual business.