Process first, then AI: what to clarify before automation
AI can prepare a clear project brief and a draft response from a short inquiry. Before doing so, however, we need to know what outcome we expect, what information is missing, and who is authorized to decide on the next step.
A clear response does not yet mean a finished brief
Let us consider an illustrative scenario: a small web agency receives an inquiry for three pages — Home, Services, and Contact. The customer supplies their own copy, but does not state a budget or desired deadline. This is an illustrative example, not a description of an executed project.
AI can organize requirements and suggest follow-up questions. However, a clear output alone does not indicate whether the agency has available capacity, how pricing will be set, or who will confirm it to the customer. These questions belong within the workflow itself.
It is therefore useful to first define the immediate outcome. In this situation, that may be a background document for evaluating the inquiry: known requirements, missing information, and a proposed next step.
Drafting a response and sending it are two separate steps
When designing a procedure, we need to separate text preparation from customer communication. In the model example, AI prepares a draft response. A human evaluates the scope, potential pricing, and deadline, and approves a specific text for a specific recipient.
Automation can handle passing materials and logging status. However, it must be defined what happens upon rejection, draft modification, or missing approval. Waiting alone does not constitute consent.
Such a division helps identify where preparation ends and commitment begins. It also highlights which decisions require additional information or authorization.
Missing information should remain visible
If a customer did not state a budget, filling in the field does not necessarily mean a better output. An unflagged estimate could be treated in subsequent steps as a confirmed requirement.
In a structured output, an unknown value can be marked as null, for example. For a human reader, a clear explanation should follow: the budget was not provided and needs to be requested. The same rule applies to deadlines.
A good workflow does not merely specify required fields. It also describes how to handle uncertainty: which details are missing, who will supply them, and whether work can proceed without them.
A small experiment needs a concrete benchmark
For an initial trial, choose a limited task and document in advance what you will measure. For inquiry processing, this could be the time required to prepare background materials, the number of manual corrections, or overlooked missing details.
Use the same prompt and the same criteria for comparison. Include review and output corrections; the speed of drafting alone does not capture the full work process.
Test incomplete or conflicting inquiries as well. The result of a small experiment serves as a baseline for further decisions. In itself, it does not yet prove how the procedure will perform in all standard situations.
Start by describing work you already know
For a first step, simply choose one recurring task and describe its current flow. What triggers it? What outcome do you require? Where does a human currently make decisions, and how do they know when to hand off the work?
From such a record, you can derive instructions for AI, handoff rules, and review checkpoints. If the outcome or responsibility is not yet clear, clarifying them may be the most useful next step.
In the accompanying practical guide, you will find a working template for process mapping. It will help capture current state and separately design the change you want to validate.