Most automation efforts are a pile of one-off flows that someone built when they had a spare afternoon. They work until they do not, and nobody can quite explain how the whole thing fits together. A playbook turns that pile into a system: a defined set of plays, each with a clear trigger, a named owner, and a place in a sequence. The point is not bureaucracy. It is that a program you can describe is a program you can scale, hand off, and trust.
This piece lays out the plays in the order you should run them. Each play has a trigger that tells you when to start it, an owner who is accountable for it, and an output that feeds the next play. Run them in sequence and you move from scattered experiments to a durable capability. Skip the sequencing and you get the sprawl that kills most automation programs within a year.
Treat what follows as an operating model you can adapt, not a rigid script. The ordering matters more than the specifics, because each play assumes the previous one is done.
Play One: Audit the Work
Trigger: you are ready to invest in automation but have not decided what to automate. Owner: whoever will run the program.
The first play is reconnaissance. Before touching a tool, map where repetitive time actually goes. Shadow the work for a week and list every task that is frequent, low-judgment, and clearly bounded.
What to capture
- Frequency: daily, weekly, monthly
- Judgment required: stable steps or constant exceptions
- Inputs and outputs: can you describe them in a sentence
- Pain: who hates doing it
The output is a ranked list of candidates. This list drives every later play, so do not shortcut it. A weak audit produces a weak program, because every subsequent investment lands on tasks that were never worth automating. Spend the extra day getting the ranking right; it is the cheapest leverage in the entire sequence.
Rank candidates by a simple combination of frequency, time saved, and how forgiving the task is of small errors. The ideal first candidates sit high on all three: they happen often, they consume real time, and a minor mistake costs nothing. Tasks that score high on time saved but low on forgiveness belong later, once the team has built the judgment to handle their failure modes.
Play Two: Pick and Build the Lighthouse
Trigger: you have a ranked candidate list. Owner: a single builder.
Choose one candidate with a visible, beloved outcome and build it well before doing anything else. A flawless first automation does more for adoption than ten half-finished ones. Keep it forgiving, so early mistakes carry no real cost.
The reasoning behind picking forgiving, high-frequency work first is developed in The Questions Teams Keep Asking About Automating Their Work.
Play Three: Set Standards
Trigger: a second person is about to build or touch an automation. Owner: the program runner.
The moment automation stops being a solo activity, you need conventions. Name every flow for its purpose, assign each a named owner, and write a one-paragraph description of what it does and what to do when it breaks.
The minimum standard
- A descriptive name
- A named human owner
- A one-paragraph runbook
- A sanctioned platform it lives on
Without these you get sprawl: undocumented logic and brittle connections that break the day someone leaves. The team-scale mechanics live in Getting a Whole Department to Actually Use Automation.
Play Four: Add Guardrails by Risk
Trigger: an automation is about to touch customers, money, or irreversible actions. Owner: the flow's owner plus a reviewer.
Tier your automations by consequence and match oversight to stakes. Internal summaries need almost none. Customer-facing or financial flows need a human checkpoint where the machine drafts and a person approves.
Build flows to fail loudly, sample outputs regularly, and plant canary inputs on consequential ones. The full reasoning is in What Can Quietly Go Wrong When You Automate With AI.
Play Five: Enable the Team
Trigger: the lighthouse works and standards exist. Owner: the program runner plus experienced builders.
Adoption follows capability. Run short, hands-on sessions where people edit a real automation rather than watch a demo, and pair newer builders with experienced ones for their first changes. Train people to modify flows, not just use them, because a team that cannot change its automations depends entirely on one person.
Play Six: Instrument and Measure
Trigger: multiple automations are running in production. Owner: the program runner.
Activity counts lie. Measure what compounds: how many people have built or modified a flow, which automations survive thirty days, rough hours reclaimed, and whether people trust flows enough to stop supervising them.
The signals to track
- Breadth of participation
- Thirty-day retention of flows
- Self-reported time reclaimed
- Trust, measured by unattended runs
If one person owns everything, you have a bus-factor problem, not a program.
Play Seven: Review and Retire
Trigger: a quarter has passed. Owner: the program runner.
Schedule a quarterly review where every active automation is confirmed still useful, still working, and still owned. Retire anything orphaned. This hygiene prevents the slow accumulation of zombie flows that quietly erode trust in the whole system. The myths that lead teams to skip this maintenance are addressed in Separating What AI Automation Promises From What It Delivers.
How the Plays Connect
The plays are not independent checklists; they form a chain where each one's output is the next one's input. Seeing the connections is what turns the list into a system you can run without thinking hard about it.
The dependency chain
- The audit produces the candidate list that the lighthouse draws from
- The lighthouse surfaces the first real need for standards, because a second builder is about to appear
- Standards make guardrails enforceable, since a flow now has an owner and a documented purpose to attach review to
- Guardrails and standards together make enablement safe, because new builders inherit conventions rather than inventing their own
- Enablement produces the volume of flows that make measurement meaningful
- Measurement reveals what the quarterly review should retire
Run a play before its predecessor is done and you feel the friction immediately. Enable a team with no standards and you get sprawl. Measure with nothing running and you get noise. The sequence is not bureaucratic ceremony; it is the order that lets each play do its job without fighting the gaps the previous play was supposed to fill.
Where programs typically stall
Most programs do not fail at the start; they fail at play five or six. The lighthouse gets built, a few people get excited, and then enablement and measurement never happen because they feel less urgent than building the next flow. The discipline that distinguishes a durable program is treating enablement and measurement as first-class plays rather than someday tasks. A program that builds endlessly but never measures or reviews is just an expensive way to accumulate technical debt. The honest assessment of whether yours is healthy lives in The Questions Teams Keep Asking About Automating Their Work.
Frequently Asked Questions
How long does running the full playbook take?
Expect three to six months from audit to a self-sustaining program. The first month is audit and lighthouse, the next two are standards and enablement, and durable operation appears once measurement and review become routine.
Can I skip the audit and just start building?
You can, but you will likely automate the wrong things. The audit is what ensures your effort lands on frequent, forgiving, high-value work instead of impressive but low-return tasks. It is the cheapest insurance in the sequence.
Who should own the overall program?
One person who treats automation as part of their role and maintains the standards. For teams under fifty, this is rarely a full-time job, but it must be someone's clear responsibility rather than a shared afterthought.
What if a play reveals we are not ready?
That is the playbook working. If the audit shows mostly rare or exception-heavy tasks, the right move may be to wait or to simplify processes first. Not every team benefits from heavy automation, and the sequence helps you find that out cheaply.
How rigid is the ordering?
The ordering matters because each play assumes the previous one is done. You can adapt the specifics, but building before setting standards, or measuring before anything runs, tends to backfire. Treat the sequence as load-bearing.
Do small teams need all seven plays?
Yes, but lighter. A small team still audits, builds a lighthouse, sets minimal standards, adds guardrails by risk, and reviews quarterly. The plays scale down in effort, not in necessity.
Key Takeaways
- A playbook turns scattered flows into a system you can scale and hand off
- Run the plays in order; each assumes the previous one is complete
- Audit the work before choosing what to automate
- Build one flawless lighthouse before expanding
- Set naming, ownership, and runbook standards the moment a second person joins
- Match guardrails to risk and design every flow to fail loudly
- Measure breadth, retention, and trust, then review and retire quarterly