1. Find a task you can observe
Start with a normal working day, not a list of AI tools. Where does someone copy information, ask the same questions, check a status, or assemble the same report? Write down three candidates. Useful examples include turning inquiries into a brief, collecting appointment preferences, extracting fields from documents, and summarizing open work for a weekly meeting.
Watch each task happen and note where it starts and ends. Answering customer questions is too broad. Turning a website inquiry into a draft for the owner to review is specific. That boundary gives you something you can explain, price, and test without committing the whole business to a new way of working.
2. Compare the candidates before choosing
For each candidate, ask how often it occurs, how much attention it takes, how consistent the inputs are, and what happens if the output is wrong. Use examples from your own work rather than guessing. A frequent task with predictable information and a reversible output is often easier to start with than a rare task that requires judgment or makes a binding promise.
Also ask whether a simpler change would solve it. A clearer form, saved reply, spreadsheet formula, or checklist may be enough. AI is more relevant when the task involves varied language or documents that need to be interpreted. Choose the smallest approach that produces a useful result; the goal is less friction, not more software.
3. Write a one-page process brief
Describe the process in plain language so another person could follow it. Include the trigger, required information, current tools, expected output, reviewer, and exceptions. Keep decisions separate from clerical work: preparing a quote request is different from approving a price. A brief also reveals missing information before anyone starts connecting systems.
Here is an illustrative brief for a repair business. Trigger: a new service inquiry. Input: customer-provided contact details, location, equipment type, and description. Output: a structured inquiry brief with missing fields highlighted. Destination: the agreed inbox or CRM. Reviewer: the owner. Limits: no diagnosis, price promise, appointment confirmation, or message sent without the agreed permission. Success: the owner can review the brief against the original request.
4. Sketch the workflow and the human handoff
For that example, the sequence could be: receive the inquiry, check required fields, organize the supplied information, save a draft brief, and notify the owner. If the description is ambiguous, preserve the original wording and flag it rather than filling in a guess. If contact details are missing, put the request in a review queue instead of attempting a reply.
Decide what the person sees at handoff: the source message, proposed summary, missing details, and next action. Decide who covers the queue when the usual reviewer is away. If saving or notification fails, the workflow needs a visible failure state and an agreed recovery path. A handoff is useful only when someone can find it and act on it.
5. Turn the brief into acceptance tests
Collect a small set of representative examples, including awkward ones. Test a complete inquiry, missing contact information, an unclear description, a duplicate submission, an unsupported request, and an unavailable destination. Write the expected result beside each example. The correct outcome may be a request for human review rather than a completed action.
Compare outputs with their sources. Did the summary preserve the customer's meaning? Were names and reference numbers kept in the correct fields? Did a duplicate create extra work? Did the system report a failed action honestly? Agree these checks before building so acceptance depends on observable behavior rather than whether a demonstration looks impressive.
6. Decide whether to proceed
Proceed when the task has a clear owner, usable inputs, approved access, a manageable failure path, and a result someone will use. Pause when the underlying process changes every day, nobody owns the output, or essential information lives in people's heads. Fixing those gaps can be the most useful first step, even before automation.
After testing, compare the new process with the current one using the same kinds of work. Include time spent reviewing, correcting, and maintaining it. Record errors and exceptions as well as time saved. That gives you a practical basis for keeping, adjusting, or stopping the workflow instead of assuming a pilot automatically deserves expansion.
Your first-workflow checklist
Bring this short checklist to a discovery conversation. You do not need a polished specification; a clear example and an honest description of the difficult cases are more useful than a long wish list.
- One task with a clear beginning and end.
- Representative inputs and a sample of the desired output.
- Current tools and the person who can approve access.
- Actions the workflow may take, and decisions that stay with a person.
- Expected behavior for missing information, duplicates, and failed connections.
- A named reviewer and acceptance tests for the first scope.