Deciding where AI belongs
Start with the work, not the AI
A practical worksheet for choosing a first workflow by volume, variability, consequences, and human backup.
Published · Collection dates are retrospective editorial dates.
The first useful sentence in an AI project should describe a piece of work. “Handle after-hours enquiries” is a start. “Collect a callback request from an existing customer and place it in the correct queue” is better. “Deploy an AI agent” tells you almost nothing about the operating problem.
A technology-first brief encourages everyone to imagine a different project. The owner pictures fewer interruptions. The manager pictures a cleaner inbox. The supplier pictures an impressive conversation. Staff picture a system that will send them more cleanup. All four can be right about their own version and still disagree on what success means.
Choose a workflow before choosing a model or a vendor. The worksheet below is an original decision aid, not a scoring system validated by a research study. Its purpose is to make your assumptions visible enough for someone else to challenge.
Describe the work in one sentence
Use this structure:
When this event happens, we need to complete this action, and we know it is finished when this evidence exists.
For a hypothetical repair business: when an after-hours customer requests a routine appointment, collect the approved contact details and preferred windows, then create a request for the scheduling team. Completion means a correctly assigned request exists. It does not mean an appointment has been promised.
That distinction prevents a quiet expansion of authority. A system allowed to collect preferences should not start negotiating arrival times simply because it can hold a natural conversation.
Write a second sentence naming the person responsible if the action fails. If nobody can fill that blank, the workflow is not ready for automation.
Compare candidates without hiding the tradeoffs
List a few specific workflows, then describe each across these dimensions. Avoid adding the columns into a single score. A severe consequence should not disappear because the task happens frequently.
| Dimension | Evidence to gather | What it changes |
|---|---|---|
| Volume | Actual requests in a representative period | Whether setup and maintenance have enough work to justify them |
| Variability | Different request types, missing fields, unusual cases | How much interpretation the workflow needs |
| Consequence | What a wrong answer or action would cause | Review, permissions, and acceptable scope |
| Human backup | Named queue, hours, ownership, response expectation | Whether exceptions can be handled in practice |
| Knowledge quality | Approved instructions and conflicting information | Whether the system has a dependable basis for answers |
| Completion evidence | Record or acknowledgement that proves the task happened | What testing and monitoring must inspect |
A high-volume workflow with unresolved policy can be a worse starting point than a modest-volume workflow with clear boundaries. Volume makes problems more important; it does not make them easier to solve.
Look at the work as it happens, including follow-up. A short incoming message may trigger a long investigation. A long conversation may end in a simple, approved answer. Message length is a poor substitute for understanding the task.
Separate the language problem from the process problem
AI may help interpret varied wording, find relevant information, or draft a response. It cannot supply your missing approval policy.
Suppose staff disagree about which customers qualify for a courtesy reschedule. You could train a system on historical answers, but those answers might reflect inconsistent decisions rather than a coherent rule. The first project is deciding the policy and who may make exceptions.
Likewise, if a customer cannot complete a request because your booking form omits a necessary field, fix the form. An assistant that repeatedly asks for the omitted field adds a conversational detour around a preventable design flaw.
Use the simplest method that handles the real uncertainty. Fixed inputs and fixed rules often suit ordinary software. Open-ended language with bounded consequences may suit AI assistance. Consequential judgment with incomplete information may belong with a qualified person.
Make the smallest useful boundary
Basecamp's discussion of setting boundaries connects scope to the amount of time a team is willing to spend. The practical adaptation here is to choose a slice of work you can implement, inspect, and support with the resources you actually have.
“Handle support” is not a slice. “Answer approved delivery-policy questions for orders that do not need an account-specific decision” could be. The excluded cases matter just as much as the included ones.
Write them down in customer language. “The system will not approve refunds, promise delivery dates, change account ownership, or decide disputed charges.” Then specify where each excluded request goes. An exclusion without a destination is just a different way to lose the customer.
Check whether the backup is real
“Escalate to a human” can conceal an empty queue. Walk through a request outside office hours, during a staff absence, and when the main system is unavailable. Who receives it? How do they know it is theirs? What does the customer hear before anyone accepts responsibility?
A practical first workflow should tolerate honest limits. It should be able to say a request is pending without implying it is confirmed. It should preserve enough context for the next person without collecting unnecessary sensitive information. Staff should be able to recover the work without reconstructing every step from a transcript.
NIST's AI Risk Management Framework is voluntary guidance for managing AI risks. It provides a broader reference for evaluating systems; the worksheet here is a narrower operating tool.
Bring your candidate brief to the people who perform the work. Ask them to identify the case that makes the brief fail. Their answer may suggest a smaller scope, a missing policy, or a reason to use ordinary automation. Any of those is a useful result before you spend money connecting a system to customers.
Sources
For help defining this workflow, explore our workflow integration work.
Keep reading
