Before you automate it: how to tell whether AI belongs in a workflow

A good AI project rarely begins with an AI idea. It begins with a piece of work that takes too long, gets stuck between people, or depends on someone remembering the same small decisions every week. Starting there keeps the conversation grounded. Instead of asking what a new tool can do, you can ask whether changing this workflow would make the work meaningfully better.

That distinction matters because not every inefficient process needs AI. Some need a clearer owner, a shorter form, a conventional integration, or permission to stop doing the work altogether. A workflow assessment helps you find the useful intervention before the technology narrows your choices.

Write down the work as it happens today

Map the real workflow, not the version in the process document. Start with the event that triggers the work. Follow the inputs, decisions, handoffs, systems, and exceptions until there is an outcome. Talk to the person who performs each step and ask what they do when the normal path breaks.

The exceptions are often where the useful information lives. A campaign request may look like a simple form-to-project automation until you learn that half the submissions are incomplete, product names change by region, and someone in legal must review three specific types of claims. Those details determine whether the system will save time or simply move the confusion somewhere harder to see.

Look for expensive friction, not mild annoyance

The best candidates usually combine volume with repetition. People copy the same information between systems, search for the same supporting material, reformat the same report, classify a steady stream of requests, or wait for a routine handoff. Fixing a task that happens once a quarter may feel satisfying, but it rarely justifies a new system.

Estimate the current cost in time, delay, rework, and missed opportunities. You do not need a perfect financial model. You need enough of a baseline to compare the proposed improvement against something real.

Separate rules, language, and judgment

Most workflows contain several kinds of work, and they should not all be handled the same way. Fixed rules belong in conventional software. If every qualified lead with a particular region and budget goes to the same owner, a normal automation will be cheaper and more predictable than asking a model to decide.

AI becomes useful when the input is messy and the answer cannot be captured by a short set of rules. Summarizing an interview, identifying themes across open-ended survey responses, or drafting a brief from several sources are reasonable examples. Judgment with meaningful consequences should remain with a person, even if AI prepares the information that person reviews.

A dependable workflow often combines all three. Software moves the data, a model handles a narrow language task, and a person approves the decision that carries real responsibility.

Inspect the data before designing the solution

AI cannot use information your team cannot reliably find or access. Identify where each input lives, who owns it, how current it is, and whether the proposed system is allowed to use it. Check whether important context exists only in someone's inbox or memory.

This step often uncovers a smaller project that should happen first. Cleaning a product catalog, standardizing campaign names, or connecting two existing tools may remove much of the friction without a model. That is a good outcome. The assessment is doing its job.

Decide what being wrong would cost

A system that applies the wrong internal tag creates a little cleanup. A system that sends an unsupported claim to customers creates a very different problem. The cost and reversibility of an error should determine how much freedom the system gets.

For low-risk work, a person may review a sample after the fact. For public, financial, legal, or customer-specific output, approval may need to happen before anything leaves the system. Logs and a clear rollback path matter whenever the workflow changes records or takes actions in another tool.

Define success before choosing a product

Choose a small number of measures tied to the original problem. Useful measures might include time per request, cycle time, correction rate, percentage of work accepted without revision, cost per completed item, or how often the team actually uses the workflow. A vague goal such as increasing productivity is difficult to test and easy to declare successful.

Capture the baseline before the pilot. Then test the proposed workflow with real inputs and the people who will use it. A result that saves ten minutes but requires fifteen minutes of careful review is not an improvement, no matter how impressive the generated output looks.

Start with one narrow, complete slice

A focused pilot should complete a real piece of work from beginning to end. It might turn an approved interview transcript into a first-draft brief, classify incoming requests and prepare them for review, or assemble a weekly report from known sources. Keep the audience small, make the reviewer explicit, and collect failures as carefully as successes.

Expand only when the evidence supports it. More inputs, more tools, and more autonomy each introduce new ways to fail. They should be earned by a workflow that is already useful at a smaller scale.

Signs the workflow is not ready

• Nobody can explain who owns the process or the final outcome.
• The workflow changes every time a different person performs it.
• There is no baseline for time, quality, cost, or delay.
• Essential information is outdated, contradictory, or inaccessible.
• The cost of an error is high and there is no practical review step.
• A product has already been purchased and the team is searching for a reason to use it.

A useful assessment may end without an AI project. If an integration, a policy change, or one less spreadsheet solves the problem more reliably, choose it. What matters is whether the workflow is better after the novelty wears off.