Seven steps, in a fixed order, for adding AI to one workflow at a time. Each step ends with something written down.
Add AI to your work one workflow at a time, in a fixed order, and don’t start a step until the last one has left something on paper. You get a seven-step playbook, filled-in worksheets, a prompt to paste and a scored 30-day review.
Teams that stall on AI have usually not ignored the good advice. They have done one piece of it. Somebody ran a workshop, a few people tried prompts, a pilot got a green light, a licence was bought. What is missing is the order, so each piece happens without the previous one having finished, and the result is a lot of activity that doesn’t join up.
The research points the same way. In McKinsey’s 2025 State of AI survey of 1,491 participants, redesigning workflows had the biggest effect, out of 25 attributes tested, on an organization’s ability to see profit impact from generative AI. Only 21% of respondents whose organizations use gen AI said they had made fundamental changes to at least some workflows.[1] It is a consultancy survey of what people report, so I’d read it as a direction, and the direction is hard to miss: the tool is the quickest part to get, and the work around it is where the effort goes.
A finance lead in the middle of month-end close pastes the variance table into a chat tool and gets back a tidy paragraph. One line explains a drop in costs with a reason that appears nowhere in the data. She closes the tab and goes back to writing it herself. The tool did what it was asked. Nobody had decided which paragraph it should write, what it could rely on, or who would check the reasons, and nobody had asked whether this was the right job to start with.
This guide puts the steps in a fixed order, so that each one has a finish line and the next one has something to stand on. Every step ends with something written down, and the guides we have already published sit behind steps 1 to 3, 6 and 7 for the full treatment. Here you get the whole run in one place, with a worked example carried from the first step to the last.
Read the table once as a whole first. The pattern runs small to large: one task, then one workflow, then a habit, and only then a decision about more. The usual sequencing mistakes are skips, such as running a pilot (step 5) with no named checker (step 4), or buying a tool before the list in step 1 exists.
| Step | Do this | You are done when | Go deeper |
|---|---|---|---|
| 1. Start with the work | List the recurring pieces of work in your role, one line each, before you mention any tool | You have a list of at least six, in plain language | The 60-minute session |
| 2. Pick one | Choose the one that repeats, has a clear standard, and survives a wrong first draft | One task is circled and the reason is written beside it | Choosing a first workflow |
| 3. Diagnose it | Answer five questions: trigger, inputs, process, output, who reviews | A one-sentence use case names a reviewer | The five-question diagnostic |
| 4. Split the job | Decide what AI does, what a person owns and how it is checked | Every output has a named checker | Below, step 4 |
| 5. Brief it and run it | Write the instructions once, run them on real work for two weeks, log what you fix | Ten or so real runs and a revised brief | Below, step 5 |
| 6. Review at 30 days | Score use, persistence and impact | A score and a decision, written down | What to track instead of logins |
| 7. Keep, fix, retire or add | Act on the score, and add a second workflow only if the first earned it | The workflow has an owner, or it is gone | Scaling beyond one team |
A Future Factors working sequence based on our own judgment, not a research-validated model. As a planning guess, steps 1 to 4 fit into a week of short sessions and steps 5 and 6 take about a month.
Don’t start the next step until this one has left something on paper.
It sounds fussy, and it is the part that does the work. A step that ends in a conversation gets remembered differently by each person. A line on a page can be argued with, fixed and handed on.
You can also see where the four words people use loosely fit. Training builds capability, so someone can do the thing in principle. Steps 1 to 4 are workflow design, which gives that capability a real, recurring task to land on. Steps 5 and 6 are reinforcement, the repetition and the review that turn it into behavior. Adoption is what you can see once those hold, and it is the outcome of the first three, so there is no step called adopt. If you want the longer version of how this fits together, our piece on what makes an AI-powered professional different covers the tool, workflow and behavior sides.
The first three steps are the cheapest, and they get skipped because they don’t feel like AI work. They decide whether the rest has a chance.
Write down the recurring pieces of work in your role, one line each, in the words you would use to a colleague. “Month-end variance commentary” is a piece of work. “Finance” is not. Do it alone first, then, if you lead a team, ask each person for their own list. The tool does not appear anywhere on it. It enters the playbook in step 5, once there is a job to give it. If you want to do this as a team in one sitting, the 60-minute session guide runs the room.
Four tests narrow the list quickly. The task should:
Score your candidates properly with the scored version in What Should You Hand to AI?, which also lists the kinds of work to keep out of a first attempt.
Answer five questions about the chosen task: what triggers it, what information goes in, what you do with that information, what comes out, and who reviews or uses the result. Then write the answers as one sentence. The full method, with two worked examples, is in The Workflow Diagnostic. The sentence matters more than the questions, because it is what you will hand to the AI in step 5 and to the checker in step 4.
Here is what steps 1 to 3 look like finished, for the finance lead from the opening:
| Field | Completed example |
|---|---|
| Work (step 1) | Month-end variance commentary: a paragraph per line that moved, for the management pack |
| Why this one (step 2) | It repeats monthly with the same layout, ‘good’ is a short paragraph that cites the data, and a wrong draft is caught at review before the pack goes out. It also eats a long evening every close. |
| Five answers (step 3) | Trigger: close is signed off. Inputs: the variance table and the owner notes. Process: spot the largest movements, match them to the notes, draft a plain explanation. Output: draft commentary in the pack’s format. Review: the finance lead. |
| Use case, in one sentence | AI drafts the first pass of month-end variance commentary from the variance table and owner notes, for the finance lead to check and edit before it goes into the pack. |
| What is deliberately out | Anything that explains a movement the data and the notes do not explain. That stays a human call. |
A worked example in a common finance setting. Replace every row with your own task; the last row is the one people forget.
This is where the playbook stops being generic, and it is the step that earns its own section. Before anything runs, write down what the AI does, what a person still owns and how each output gets checked.
The check cannot be left to a feeling that something looks off. In a preregistered experiment with 758 knowledge workers at Boston Consulting Group, people using AI on a task chosen to sit outside what the tool handles well were 19% less likely to produce a correct solution than people working without it.[2] That figure is a relative one from a 2023 working paper using the models of the time, so take the direction and not the size. The part that matters for you is that the wrong answers read as confidently as the right ones, which means your checker needs a specific thing to check, set in advance.
| What AI does | What the human still owns | How it gets checked |
|---|---|---|
| Matches each large movement to the owner notes and drafts a plain-language paragraph | Which movements get explained at all, and the call on any movement the notes do not cover | The finance lead reads every paragraph against the table before it goes in the pack |
| Flags movements it cannot explain from what it was given, using the words ‘not explained by the data’ | Chasing the budget owner for the missing reason | A spot check each close: pick one flagged line and confirm the flag was right |
| Puts the draft in the pack’s usual format and tone | The final wording of anything leadership will quote | Compared with last month’s pack for tone, once in the first three closes |
A Future Factors working split. Swap in your own reviewer and your own check; if the right-hand column is blank, the step isn’t finished.
Let AI prepare the work, and keep the decision with the person whose name is on it.
That rule is a default, not a ban. Some decisions are small enough, and reversible enough, that a draft going straight out is fine. Start with the default, and relax it once the review in step 6 says it is safe.
Now the tool enters, and the decision rule is plain: use the one your organization already approves, as long as it can take the inputs from step 3 and the output format from step 4. Check what your policy allows before you paste anything real, and strip names and anything confidential. If the approved tool cannot take the inputs, fix that before you pick another one.
Then write the brief once, so the instructions do not change from run to run. A brief is the one-sentence use case plus the rules.
| You are helping with this recurring task: [paste your one-sentence use case from step 3]. What I’ll give you each time. [Inputs from step 3, e.g. the variance table and the owner notes]. Use only what I paste. Do not add facts, figures or reasons from anywhere else. What I need back. [Output and format from step 3 and 4, e.g. one short paragraph per line that moved, in the same layout as the example below]. Rules. Where the material does not explain something, write ‘not explained by the data’ and leave it for me. Mark anything you inferred rather than read. Keep every number exactly as given. Don’t describe a cause as certain unless the notes say so. Finish with. A short list of what you could not check or did not have, so my review starts there. Here is last month’s finished version as the standard: [paste an approved example]. |
Paste the brief at the top of a fresh chat for each run, so earlier instructions don’t leak in. Keep one saved copy and change it deliberately, not mid-run.
Run it on real work, for two weeks, and keep the run honest. After each run, note three things in a log:
At the end of the two weeks, turn the repeated fixes into new rules in the brief. If the same fix shows up in most runs, it belongs in the instructions. If the AI keeps inventing the same kind of thing, that part of the job may belong back with the person, and it is worth finding that out in week two and not in month three.
Three weeks in, the person who set it up goes on leave. The output keeps arriving and nobody opens it, or the run quietly stops and nobody mentions it. That is the usual shape of a workflow that had a good first week: it was used, and it didn’t become a habit.
Logins and prompt counts will not show you that. They measure access, so they can look healthy right up to the day the workflow dies. The review below looks at three things in order: use, persistence and impact. Use asks whether people did it. Persistence asks whether they were still doing it weeks later without a reminder. Impact asks whether the work itself is better, faster or different. If you want to go further into measuring this across a team, AI Usage Metrics: What to Track Instead of Tokens and Logins goes into it.
| Lens | Question | What a 2 looks like |
|---|---|---|
| Use | 1. Was it run on real work, as planned? | Most runs happened on the real task, not a demo |
| Use | 2. Did the checker actually check? | The log shows reviews, and at least one fix caught |
| Persistence | 3. Is it still running without a reminder? | Someone started it this week without being asked |
| Persistence | 4. Would it survive the owner being away? | The brief and the log are saved where a colleague can use them |
| Impact | 5. Is the work better, faster or different? | Less time in total, or fewer errors reaching review, noted in the log |
| Impact | 6. Would anyone notice if it stopped? | Someone says they would, and says what they’d miss |
Maximum 12. Score it with the checker in the room, because the person who set the workflow up tends to mark it too kindly.
| Score | What it means | Go to |
|---|---|---|
| 10 to 12 | The workflow is working and people use it | Step 7: keep it, and think about a second |
| 6 to 9 | It’s partly working | Step 7: fix the lowest lines, then re-score in two weeks |
| 0 to 5 | It’s mostly a demo | Step 7: retire it, or go back to step 2 |
Bands are a Future Factors working guide, not a benchmark.
Do it once, at about the 30-day mark, and write the score and date on the playbook sheet. The point is a decision you can defend.
The last step is a decision, and it is one that guides often leave out. A workflow with a good score is not finished. It needs an owner, or it will drift. A workflow with a poor score deserves to be stopped, and saying so out loud is a skill.
| If the review says | Do this | Who decides | Write down |
|---|---|---|---|
| Keep: it scores high and someone would miss it | Name a permanent owner and a quarterly check; move the brief to a shared place | The workflow owner | Owner, review date, where the brief lives |
| Fix: partly working | Change one thing (usually the brief, the checker or the inputs), then re-score in two weeks | The workflow owner with the checker | What changed and why |
| Retire: mostly a demo | Stop it on purpose and say so, so nobody keeps running it out of habit | The manager | Why it stopped, and what you learned |
| Add: it earned a second | Go back to step 2 with the next item from your step 1 list | The workflow owner | The next workflow, and its start date |
A Future Factors working table. ‘Retire’ is a legitimate result, not a failure.
Add a second workflow only after the first has a score and an owner.
Teams that add five at once tend to end up with five half-run workflows and no view of which one is working. The second is also quicker to start, because you already have a brief, a split and a review to copy.
The playbook looks a little different depending on who runs it:
None of this means you must go it alone. Teams can run the seven steps internally, and many do. Expert-led training shortens the learning curve on steps 4 and 5 in particular, builds the same skills across a whole team instead of in one keen person, and helps people practise on their own real work and not on generic examples. Our AI courses and workshops do exactly that. If you are thinking about the move from one team to many, How to Scale AI in Your Organization picks up where this one stops.
This week, do step 1 on your own. Write down every recurring piece of work you can think of, in a line each, and circle the one you’d most like back. That page is the start of the playbook sheet.
Yes, and you start at step 4. Write down the split between AI and the person for the workflow you have, add a named checker if it hasn’t got one, and run the 30-day review on what has been happening. Treat step 6 as a check on the existing habit, and go back to step 2 only if the score is low.
Take the one-page table to them and ask for step 1 and 2 first, which cost an afternoon. A tool with no named workflow behind it is a common reason a licence goes quiet, so the request is for a first workflow, not for less ambition. The seven steps also give you something concrete to report back.
It does, with one change: your reviewer may be a colleague or a trusted peer, not a direct report. Step 4 still needs a named checker, and a second pair of eyes on the 30-day score is worth asking for.
There isn’t a right number. One that scored well and has an owner is a better result than four that nobody has scored. The One at a Time Rule is there so the count follows the evidence, not the calendar.
Throughout, but not as a step. Training builds the capability behind steps 4 and 5, and the playbook gives that capability a real task. Reinforcement is the review in step 6. A team that has done the training but hasn’t reached step 2 has capability with nowhere to land.
Sources were read on October 12, 2026: McKinsey’s March 12, 2025 State of AI report (survey of 1,491 participants, fielded July 16 to 31, 2024) and Harvard Business School Working Paper 24-013 (September 2023). The seven-step playbook, the sample worksheets and the 30-day review are Future Factors working methods based on our own judgment, not research-validated models. The scenes in this guide are illustrations, not client stories. We left out any figure for hours saved per workflow or the share of AI pilots that fail, because we couldn’t confirm one against a primary source.