Many AI workflows are really a prompt with a few steps missing on either side. Draw the missing steps before you automate anything.
The model is the part everybody sees. It writes, sorts, extracts, or compares. The rest of the job is quieter: collecting the material, checking the answer, making a decision, and passing the result to the next person.
Real input is rarely as tidy as the demo. An email is missing its attachment. Somebody uses last year’s template. A customer asks two questions in the same message. Your process needs an answer for those cases.
Start with five boxes
Take a sheet of paper and write: input, AI task, check, decision, next action. Put a name or a role under each box. Then draw an arrow for anything that needs to go back.
This takes a few minutes and shows the gaps quickly. You can see who prepares the input, whether anyone really checks the answer, and where the result is supposed to end up.
Input → AI task → check → decision → next action. Add one name or role beneath each box. An empty owner leaves unfinished work.
1. Deal with messy input
Every workflow begins somewhere: an email, a form, a spreadsheet row, a document, or a conversation. Look at the examples people actually send before designing the automation.
Which fields are often missing? Are dates written the same way? Do attachments arrive? Can the tool read the scanned pages? Make a short list of the common problems.
Now decide what to do when a required item is missing. Return the request, ask a person to fill the gap, or move it to a “Needs information” queue. Do not let the model quietly guess.
2. Give the model a job you can check
“Handle this customer request” is several jobs pretending to be one. It may involve finding the issue, checking an account, drafting a reply, making a promise, and updating a record.
Something like “Extract the equipment number, fault, urgency, and requested callback time into these four fields” is easier to test. You can compare each field with the original message.
Keep the prompt and settings somewhere the team can find them. If the only copy lives in one person’s chat history, you do not have a maintainable process.
3. Decide how much checking is enough
An internal draft with little consequence may only need a quick read. Work involving safety, money, legal duties, private data, or promises to a customer needs more care and a named reviewer.
Give that reviewer the original material. A polished answer without the source beside it is unnecessarily hard to check.
During a pilot, review everything. Sampling may be fine later for stable, low-risk work, but only after you know which errors to expect and where the exceptions go.
4. Name the decision
Checking an answer and approving the next action are not always the same job.
An AI can compare an invoice with a purchase order. One person can verify that the fields match. A manager may still need to approve payments above a certain amount. Write down who does what.
The final decision should live somewhere other people can find it. A “yes” buried in a private chat is easy to lose and difficult to audit.
5. Give the answer somewhere to go
Will it become a draft in the help desk, fields in a CRM, a task in a project system, or a document in a shared folder? Pick the destination and the owner.
Also decide how the next person knows it is ready. That might be an assigned task or a status change. A green “automation completed” message does not mean anybody received the work.
Keep a manual route. If an integration fails, somebody should still be able to finish the job without waiting for the person who built it.
Do something with the mistakes
The first version will miss cases. Inputs change, tools change, and people find situations nobody considered during setup.
When an error appears, find the layer that caused it. Was the source incomplete? Was the task too broad? Did the model ignore a rule? Did the reviewer miss it? Fixing the wrong layer usually adds complexity without solving the problem.
Keep the errors in one visible place and review them regularly. Otherwise people make private corrections, the dashboard stays green, and the extra work remains hidden.
One person needs to own the workflow
This person does not have to perform every step. They need to know who acts when the tool changes, access breaks, or a business rule is updated.
Write down where the prompt lives, which account owns the integration, how credentials are handled, what data goes into the tool, and how to switch the process off. These details are dull right up until the day you need them.
Measure the whole job
Model accuracy is one number. Review time, corrections, missed handoffs, exceptions, and manually finished cases matter as well.
A new model can produce nicer text while the workflow around it remains awkward. A simpler tool with clean input and a decent review step may do the job better.
Run normal cases, incomplete cases, unusual cases, and one case that should be refused. Watch a person who did not build the workflow use it. Write down every instruction you forgot to give them.
Keep the first version small
Choose one task, one source, one output, and a few users. Leave the manual process available. Review every case until the repeated problems are clear.
Then change the weak parts before adding more volume. Scaling a confusing process only creates confusion faster.
The model is available to everybody. The useful part is the work you do around it: fitting the process to your information, your decisions, and the people who have to use it.
Back to guide 01Before You Prompt, Define the Job →