Start with the work, not the tool.

Before choosing a model or building an agent, follow one piece of work from request to completion. The useful opportunity is usually easier to see in the handoffs, repeated decisions, and missing context than in a list of AI features.

Follow a real task

Choose a recently completed task: a customer question, an inbound lead, a weekly report. Ask the person who did it to walk through the actual messages, documents, and decisions. Capture what started the task, what they needed to know, and what counted as finished.

Include the awkward parts. A spreadsheet copied into another spreadsheet, a manager asked for context, or a request returned for clarification may reveal more than the documented process. Record exceptions alongside the normal path.

Consider the work involved in preparing a new customer’s onboarding plan. The visible task is writing the plan. The actual work may include checking a signed scope, resolving an incomplete handover, identifying the customer’s systems, and confirming who can approve access. Automating the writing alone leaves those dependencies in place. A useful map shows the information and decision behind each step, including where the team waits for someone else.

Separate judgment from movement

Mark the steps that move information, the steps that apply a stable rule, and the steps that require interpretation. A deterministic integration may handle movement. A simple rule may handle routing. AI becomes a candidate where varied language or incomplete context makes interpretation useful.

This distinction keeps the design honest. If the underlying problem is unclear ownership, adding a model will leave that ownership unclear. Resolve the operating question before automating around it.

Ask what happens when two experienced people receive the same input. If they apply the same documented rule, make that rule explicit. If they disagree, find out whether the difference comes from missing context, legitimate discretion, or an unsettled policy. An AI system should not quietly become the place where an unresolved organizational decision gets made.

Choose a boundary you can observe

Start with one input and one useful output. Preparing a response for review is a clearer first boundary than handling every customer interaction. The smaller workflow should still save meaningful effort when it works.

For the onboarding workflow, the first version might assemble a briefing from approved source documents and flag unanswered questions. It would not promise dates, grant access, or send a plan to the customer. Those boundaries make the output reviewable and keep an incorrect interpretation from becoming an external commitment.

Name the person responsible for the final result.

List the information the system may access.

Define when it should stop and ask for help.

Keep an ordinary manual path available.

Give the workflow an accountable owner

Name an operational owner who can decide what the workflow should do, and a technical owner who can maintain the implementation. In a small team, one person may hold both roles; the responsibilities still need to be explicit. A reviewer should have the authority and context to reject an output, not simply be the last person to click a button.

Agree on the exceptions before launch. Who receives a request with missing information? Who resolves conflicting documents? What happens during an integration outage? Keep the unresolved task visible, with a next action and responsible person. Sending an error into an unattended inbox does not create an operating process.

Measure the whole task

Record the current effort using a few representative cases. Include checking, corrections, and follow-up work. After introducing automation, use the same definition of completion and compare similar cases.

A draft produced quickly is only useful if reviewing it is easier than doing the task directly. If the benefit disappears once checking is included, adjust the boundary or choose a different workflow.

Keep waiting time separate from hands-on effort. A tool might reduce preparation effort while the request still waits for an approval. Record whether mistakes are found before or after handoff, too. Moving correction work to another team can make one person’s task look faster while the overall process becomes harder to operate.

Make the next decision deliberately

Compare candidate workflows on frequency, clarity of inputs, review effort, consequences of mistakes, and access to the required systems. Avoid a single score that hides a serious constraint. A frequent task can still be a poor starting point if nobody can verify the output or approve the data access.

Choose one workflow and write the smallest experiment that would change your decision. Specify the cases you will review, who will assess the results, and what would cause you to stop. If the task cannot yet be described this way, invest first in clarifying the work.

A practical next step.

Bring one completed task, its source material, and its owner into a working session. Leave with a workflow map, an explicit boundary, and one question an experiment can answer.