How to turn a working method into a reusable workflow
5 minutes read
A method becomes a workflow the moment someone writes down what stays the same every time it runs. Here is what belongs in that document, and what a real one looks like.
A method turns into a reusable AI workflow when someone writes down the parts of it that stay the same every time it runs: the sources it draws on, the steps in order, and the shape of the output. That written record is what a workflow actually is: a record of the setup, saved so the next person doesn't rebuild it from memory. It doesn't replace the judgment calls an expert still makes on top of it.
Most firms already have methods worth capturing. A senior researcher has a reliable way to structure a competitor scan. An analyst has settled on a good order for building out a market sizing. None of that is written down anywhere. It lives in one person's head, and the next person doing similar work starts from a blank window and their own guess at the same problem.
When a method is ready to become a workflow
Not every good result is worth turning into a workflow yet. A few signals are worth checking first.
The work recurs. A method used once was probably shaped by that specific brief, not by anything repeatable. A method that has come up three or four times, in roughly the same shape, is a better candidate.
The setup is genuinely the same each time. A workflow only pays off for the part of the task that does not change. If the sources, the framing, and the structure vary wildly between instances, there may not be a repeatable setup to capture yet, just a person who is consistently good at the judgment part.
Someone can name what worked. If the person who ran it can say which sources they used, what order they worked in, and what the finished piece needed to include, the method is ready to write down. If they can only say "it just came together," there isn't yet a clear setup to standardize, and writing one down too early risks freezing in a method that was actually a one-off.
What to write down
A workflow document is short, and skipping any of the fields below is usually why a captured workflow sits unused once someone writes it.
| Field | What it answers |
|---|---|
| Trigger | What kind of brief calls for this workflow, and what doesn't |
| Sources | Which documents, tools, or prior work it draws from |
| Steps | The order of work, from brief to finished draft |
| Output shape | What sections or format the result needs to contain |
| Owner | Who updates it when the method changes |
The trigger row matters more than it looks. A workflow used on the wrong kind of brief produces a draft that technically follows the steps and still misses the point, because the brief didn't match what the workflow was built for. Naming what the workflow is not for is as useful as naming what it is for.
A worked example
Take a competitor scan a strategy team runs for new clients. Before it was a workflow, it lived with one senior consultant who happened to be good at it. Here is what capturing it actually looked like.
Trigger: a new client brief asking for a competitive landscape, not a deep single-competitor profile.
Sources: the firm's prior scans for similar clients, the client's own positioning material, and a fixed set of public sources the firm already trusts for this kind of work.
Steps: pull the prior scans for reference structure, identify the client's five most relevant competitors from the brief and prior work, research each one against a fixed set of dimensions, and draft a comparison before writing the narrative summary.
Output shape: a comparison table across the five competitors, followed by a two-page narrative that a consultant can hand to a client after review.
Owner: the consultant who built the method, until it moves to whoever runs point on strategy work.
Once this was written down, a different consultant could run the same scan without reconstructing the approach from scratch. The comparison table and the source list came from the workflow. Which competitors actually mattered for this client, and what the findings meant for their positioning, still came from the person running it.
Where workflows go stale
A captured workflow is not permanent, and it tends to go stale in a couple of predictable ways.
Nobody owns it. A workflow with no named owner drifts. Someone hits an edge case the workflow doesn't cover, works around it once, and the fix never makes it back into the document. The next person hits the same edge case cold.
It tries to standardize the judgment, not just the setup. A workflow that dictates the conclusion, not just the preparation, produces a worse result than the person it was copied from would have reached alone, because it strips out the part of their work that actually needed thinking. The reusable workflows guide covers this line in more detail: standardize the preparation, never the call an expert has to make.
The output is still a draft
Turning a method into a workflow changes how a draft gets built. It does not change what happens after. The result is still a first draft, and an expert still reviews it before it reaches a client, the same as any other piece of AI-assisted work. A workflow makes that starting point more consistent across the team; it is not a substitute for the review itself.
