Decision guide
How to assess an AI workflow opportunity before you build.
A useful assessment turns an operational bottleneck into a decision supported by evidence. It does not begin by assuming automation is the answer.
A six-part assessment
Move from a workflow problem to a responsible recommendation.
The stages overlap in real work. Their purpose is to ensure that value, feasibility, safety, ownership, and adoption are examined before an implementation is funded.
Start with an operating question.
State what the team needs to decide and why now. A useful prompt is concrete: should we change this recurring intake, handoff, review, or follow-up workflow? Avoid beginning with a model, vendor, or feature list.
Map the work people actually do.
Document the trigger, inputs, systems, handoffs, decisions, exceptions, waits, rework, and outcome. Interview the people close to the work; a leadership description alone often misses the practical constraints.
Measure the consequence of leaving it alone.
Use a defensible baseline: frequency, time, delay, backlog, rework, quality, service level, risk, or missed follow-up. The value may be real without being a labor-saving claim.
Examine the information and dependencies.
Identify data sources, permissions, integrations, representative examples, system limits, and the person accountable for access. Sensitive or regulated data changes the assessment; it is not a detail to defer.
Decide where people stay responsible.
Specify what an automated step may do, what requires review, which failures matter, how a user corrects the result, and how the team escalates. A fast output that cannot be challenged is not a finished workflow.
Recommend rather than assume.
The answer may be a controlled pilot, an existing tool, a process improvement, more discovery, or no change. Record the owner, dependencies, acceptance criteria, and measure that would justify continuing.
What good evidence looks like
Specific enough to make the next step smaller.
An assessment should leave behind a shared artifact, a named owner, and a decision. Vague enthusiasm, a software demo, or a list of tools is not sufficient evidence.
- A current-state workflow map with exceptions
- A dated baseline and its assumptions
- Data, access, and retention constraints
- Human-review and escalation boundaries
- Named sponsor, process owner, and users
- A next-step decision with acceptance criteria
- Assuming an AI capability makes the workflow feasible
- Calling avoided time realized savings without a plan
- Using representative customer data before its use is approved
- Describing a pilot as production readiness
- Promising an outcome before the constraints are known