Mapping an AI Workflow Before You Automate It: A Step-by-Step Diagnostic
Most people who start using AI in their daily work begin in the wrong place. They open a tool, type in a request, and gradually accumulate prompts, half-finished scripts, and automations that nobody remembers setting up. Six months later the work is faster in some corners and harder to trust in others, and it is unclear which parts are actually improving. A better starting point is a map. Before you automate anything, write down how the work currently moves, where it stalls, and where a mistake would be expensive. This article walks through a diagnostic you can run on any operation, whether it is a one-person content channel, an ecommerce catalog, or a small team's reporting routine.
Start by Listing the Work as It Actually Happens
Ignore the process document your team wrote last year. Instead, track one real cycle of work from start to finish and record every step, including the messy ones: the Slack message that triggers a task, the spreadsheet you copy from, the file you rename before sending. Write each step as a verb and an object, such as 'pull last week's order export' or 'draft product description from spec sheet.'
Aim for granularity. A step like 'handle customer emails' hides five different jobs with different risks. Split it into sorting, answering routine questions, escalating complaints, and issuing refunds. Each of those has its own answer to the automation question later.
Note the inputs and outputs for each step. Where does the information come from, what format is it in, and who or what consumes the result? Gaps between steps, where someone re-keys data or waits for a reply, are often more valuable to fix than the steps themselves.
Score Each Step on Three Dimensions
Once the steps are listed, score each one on three questions. First, how repetitive is it? Work that follows the same pattern dozens of times a month is a candidate for assistance; work that changes shape every time is not. Second, how costly is an error? A typo in an internal draft is cheap to fix, while a wrong price published to a storefront is not. Third, how much context does the step require? Some steps depend on knowledge that lives only in one person's head, which makes them poor candidates until that knowledge is written down.
Use a simple scale, such as one to three for each dimension, and total the scores. High repetition with low error cost and low context needs are the easiest starts. High error cost deserves a different treatment regardless of its score. You should not be asking whether a tool can do the step; you should be asking whether a wrong output would be noticed, and by whom, before it causes harm.
Decide Where Human Review Must Stay
A practical rule: keep a human in the loop wherever an output leaves your control. Drafts for your own review can be generated freely. Messages to customers, changes to live data, commitments made on behalf of the business, and anything that touches money or personal information should pass through a person before they take effect. This is a workflow decision, not a claim about any particular tool's capabilities. Write the review point into the map explicitly, with a name next to it.
Review is only useful if the reviewer knows what to check. For each review point, write two or three specific questions. For a product description, the questions might be: does every claim match the spec sheet, is any measurement missing or invented, and does the tone match the brand? A review step with no checklist tends to become a rubber stamp.
A Short Checklist Before You Automate Anything
Work through these questions for each step before you build anything. Does the step have a clear input and a clear output? Can you describe what a correct output looks like in one sentence? Have you run the task manually at least three times and noticed the variations? Is the error cost written down? Who receives the output, and would they know if it were wrong? Is there a named person responsible for reviewing it? If you cannot answer these, the step is not ready, and the work to do first is documentation, not automation.
Keep a running log of what you changed and why. A dated note such as 'moved order-status replies to a drafted template with manual send, reviewed weekly' is far more useful later than a memory of having 'set up some AI stuff.' The log also gives you evidence when you decide whether a change helped.
Sequence the Work and Measure It Honestly
Automate in small, reversible increments. Pick the single highest-scoring step, change only that, and run it for a set period. Compare against the prior baseline using the same measure you used to score the work: time spent, number of corrections, or number of escalations. Be willing to find that a change saved time on paper but created cleanup work elsewhere. Those hidden costs show up in the review step, which is one more reason to keep it.
Revisit the map monthly. Workflows drift, tools change their behavior, and the team's priorities shift. A diagnostic is not a one-time project; it is a habit that keeps your operation legible to the people running it. The goal is not to automate as much as possible. It is to know, at any point, which parts of your work are running on judgment you have checked and which parts are running on defaults you have not looked at in a while.