The Workflow Diagnostic: Where AI Actually Fits
Five questions that turn “we could probably use AI for that” into something you could actually build this week.
Table of Contents
The Short Version
“We should use AI for our reporting” is a feeling, not a use case. Five plain questions, what triggers the work, what information it needs, what happens to that information, what comes out, and who reviews it, turn a vague idea into something specific enough to actually hand to an agent. This piece walks through the diagnostic on a real example, then gives you a blank copy to run on your own recurring work.
Why “we could probably use AI for that” goes nowhere, and what a real use case needs instead
Somebody in a leadership meeting says it almost every time: “We should probably be using AI for our reporting.” Everyone nods. Nobody does anything about it, because there’s nothing to do yet. “Our reporting” isn’t a task, it’s a whole category of work with a trigger nobody named, inputs nobody listed, and a reviewer nobody assigned.
That’s the actual reason most AI ideas stall before anyone builds anything. Not resistance, not budget, not a missing tool. The idea was never specific enough to hand to anyone, human or AI. “We should use AI for reporting” and “AI-assisted monthly leadership reporting: synthesize performance data and team updates, identify themes and risks, draft executive narrative, and generate presentation structure for VP review” are two completely different sentences, and only the second one is buildable.
The five-question diagnostic below is how we get from the first sentence to the second, every time, in about fifteen minutes per recurring activity.
The five-question workflow diagnostic: what it is, and why these five questions
Pick one recurring piece of work, something that happens on a schedule or a trigger, not a one-off project, and answer these five questions about it.
The workflow diagnostic
| Question | What it tells you |
|---|---|
| What triggers this work? | Workflow start |
| What information do you need? | Inputs |
| What do you do with that information? | Process |
| What do you produce? | Output |
| Who reviews, approves, or uses the output? | Human controls |
The exact five-question diagnostic we run in Future Factors workshops before anyone touches a tool.
Each question earns its place. The trigger tells you whether this is even a recurring pattern worth building for, or a one-off that doesn’t need a system. The inputs tell you exactly what an agent would need access to, which is usually the first thing people get vague about. The process is where the actual thinking happens, and it’s worth being honest about how much of it is genuinely judgment versus genuinely repeatable. The output is the thing you’re actually trying to produce, stated plainly instead of as a category. And the fifth question, who reviews it, is the one people skip, and it’s the one that turns this from a productivity exercise into a responsible one: it’s the human-ownership check built directly into the diagnostic, not bolted on afterward.
Running it: a worked example, from raw answers to an actual AI use case
Here’s the diagnostic run on a real recurring activity: preparing a monthly leadership update.
Worked example: the monthly leadership update
| Question | Answer |
|---|---|
| Trigger | Month end |
| Inputs | Excel reports, project updates, emails, meeting notes |
| Process | Review performance, identify themes, find risks, summarize |
| Output | Leadership PowerPoint |
| Human role | VP validates conclusions |
Five raw answers to five plain questions, about a task nearly every mid-size company already runs every month.
Look at what those five raw answers turn into once you write them as a single sentence: “AI-assisted monthly leadership reporting workflow: synthesize performance data and team updates, identify themes and risks, draft executive narrative, and generate presentation structure for VP review.” That sentence tells an agent exactly what to work from, what to do with it, what to hand back, and who has to sign off. “We should use AI for reporting” tells nobody anything.
Notice, too, that this didn’t remove the VP from the process. It made the VP’s actual job clearer: not compiling the numbers, but validating the conclusions. That’s the human-ownership question doing its job. If your version of this exercise produces a use case with nobody named in the reviewer slot, that’s not a finished diagnostic. That’s a gap you need to go back and close before you build anything.
Here’s a second worked example, in a different domain, so you can see the pattern generalize rather than just repeat.
Second worked example: weekly client status update
| Question | Answer |
|---|---|
| Trigger | Every Friday, for each active client account |
| Inputs | Project management tool activity, time-tracking entries, the prior week’s status email |
| Process | Compare this week’s progress to the plan, flag anything behind schedule, draft plain-language client update |
| Output | Client-ready status email |
| Human role | Account lead reads and edits before sending; never auto-sent |
The same five questions, applied to a client services workflow. Resulting use case: “AI-assisted weekly client status drafting: compare planned versus actual progress, flag schedule risk, and draft a client-ready update for account lead review before sending.”
If you can’t name who reviews the output, you haven’t finished the diagnostic. You’ve found a task, not a use case.
How to run this with your own team, one recurring activity at a time
This works alone, at your own desk, on your own recurring work. It works better in a room, because other people notice inputs you’ve stopped seeing because you’re used to them.
- Pick one recurring activity per person or per small group, not five. Depth beats breadth on the first pass.
- Answer all five questions in writing before discussing anything. Writing it down first stops the conversation from jumping straight to tools.
- Read the resulting use-case sentence out loud. If it still sounds vague, one of the five answers was too broad, usually the inputs or the process.
- Name the reviewer as a specific person, not a role or a department. “Someone checks it” is not an answer to question five.
For whom this matters differently: a finance lead running this on a close process is going to find a process step that’s almost entirely judgment (deciding which variance is material), while an ops coordinator running it on a scheduling task might find a process step that’s almost entirely mechanical (matching availability to slots). The diagnostic doesn’t tell you which is which. Running it honestly does.
Blank diagnostic: run this on your own recurring work
| Question | Your answer |
|---|---|
| What triggers this work? | |
| What information do you need? | |
| What do you do with that information? | |
| What do you produce? | |
| Who reviews, approves, or uses the output? |
Copy this into a doc and fill it in on one recurring task before your next planning meeting.
Turning a stack of finished diagnostics into a shortlist of what to build first
Once a few people have run this on their own recurring work, you’ll have a short stack of specific, buildable use-case sentences instead of a long list of vague hopes. Don’t try to build all of them at once. Sort by two things: how often the trigger actually fires, and how clear the reviewer answer was. A workflow that fires weekly with a clearly named reviewer is a better first build than one that fires quarterly with a fuzzy “the team looks at it” answer, even if the quarterly one sounds more impressive in a meeting.
This diagnostic is deliberately the step before the next two decisions, not a replacement for either. Once you know which workflow you’re building, our piece on what to actually hand to AI first covers how to decide the boundaries of that specific build. And if you’re choosing between a handful of finished diagnostics and want a shortlist of proven starting points, five systems every founder should build is a useful reference list once you know what you’re looking for.
Frequently Asked Questions
What is a workflow diagnostic, and why run one before picking an AI tool?
A workflow diagnostic is a short set of questions that turns a vague idea like “we should use AI for reporting” into a specific, buildable use case. Running it before picking a tool matters because a tool decision made on a vague idea usually produces a vague result; the diagnostic forces the specificity a tool needs to actually help.
What are the five questions in the workflow diagnostic?
What triggers the work, what information you need, what you do with that information, what you produce, and who reviews, approves, or uses the output. Those five map to workflow start, inputs, process, output, and human controls.
How do you turn diagnostic answers into an actual AI use case?
Write the five answers as one sentence: trigger and inputs become the starting context, the process answer becomes the action verbs, the output answer becomes the deliverable, and the reviewer answer becomes the sign-off step. That single sentence is specific enough to hand to a builder or an agent directly.
Does this exercise have to be done as a team, or can one person run it alone?
One person can run it alone on their own recurring work. It tends to work better in a small group, because other people often notice inputs or process steps that someone doing the work daily has stopped consciously seeing.
How many workflow diagnostics should we run before deciding what to build first?
Enough to have real options, usually a handful across a small team, then prioritize by how often the trigger fires and how clearly the reviewer question was answered, rather than building the first one that comes up or the one that sounds most impressive.
About This Article
The five-question diagnostic and both worked examples in this article reflect the exact framework and case detail Future Factors uses in its own workshops. The WEF statistic cited above supports the broader point about skill gaps and is sourced in the citations below.
Sources
- World Economic Forum, Future of Jobs Report 2025 (January 2025)
