How to choose the first workflow to automate with AI

01

Begin with work, not a model

Teams often start by asking where they can use a chatbot or an agent. That reverses the useful order of operations. Begin with a recurring business process: who starts it, what information arrives, what decision is made, what output is expected, and who uses that output next. A model is only one possible component inside that system.

Write the current process as a short sequence of observable steps. Include handoffs, copy-and-paste work, searches, approvals, and rework. This map exposes whether the real constraint is language interpretation, missing data, unclear ownership, or an integration that conventional software could handle more reliably.

02

Score candidates on five dimensions

A lightweight scorecard makes competing ideas comparable. Rate each candidate from one to five for frequency, labor consumed, input consistency, output verifiability, and consequence of error. High frequency and labor increase potential value. Consistent inputs and verifiable outputs make evaluation easier. A severe consequence of error should lower the priority unless a strong human review step is available.

Do not turn the score into false precision. Its purpose is to force a concrete discussion. A weekly task that consumes thirty minutes may be easy but unimportant. A daily task that consumes three hours may be attractive, yet still be a poor first project if nobody can define what a correct result looks like.

• Frequency: how often does the workflow run?
• Effort: how much focused time and waiting does it consume?
• Input consistency: do examples share a recognizable structure?
• Output verifiability: can a reviewer judge correctness quickly?
• Risk: what happens when the system is incomplete or wrong?

03

Prefer bounded transformations

Good early workflows transform a defined input into a defined draft: classify an inbound request, extract fields from a document, compare a submission with a checklist, summarize a known packet, or prepare a response for review. The system has a clear starting boundary and a clear stopping boundary.

Open-ended goals such as “manage customer support” or “run our marketing” hide many decisions, systems, and accountability questions. Narrow the goal until one person can provide representative examples and explain the acceptance criteria without relying on intuition alone.

04

Collect examples before building

Gather a small but varied set of real inputs and the outputs the team considers good. Include routine examples, messy examples, missing information, conflicting instructions, and cases that should be escalated. Remove sensitive information when it is not needed for prototyping.

These examples become the evaluation set. They are more useful than a long feature list because they let the team compare the existing process with the proposed one. If examples cannot be collected, ownership or data access may be the first problem to solve.

05

Define a safe operating boundary

Decide what the prototype may read, what it may produce, and what it must never do automatically. A first version can draft without sending, recommend without approving, and extract without overwriting the source record. This keeps the test useful while preserving accountability.

Also define an escape route. Low confidence, missing fields, unusual requests, and policy-sensitive cases should be routed to a person with the original source attached. A clear escalation path is part of the product, not an admission that the automation failed.

06

Choose the smallest decision-worthy test

The first milestone should answer one decision: should the team invest further? A useful test might process fifty historical items, measure reviewer corrections, and record time per item. It does not need every integration or a polished dashboard.

At the end, compare accuracy, cycle time, review effort, and failure patterns with the current workflow. Continue only if the evidence supports a next step. A small test that produces a clear “not yet” is more valuable than a large demo that cannot guide a decision.