The procedure is written down, the model is good, and the assistant still does something other than what you intended. Most organisations conclude that the technology fell short. Usually it is the instruction.
A work instruction for AI is a procedure in which every decision, every exception and every source is made explicit, because the executing system has no experience to fill the gaps with. A human work instruction assumes a colleague who knows what "check whether it's reasonable" means inside your company. An AI does not know that, and fills the space with something plausible.
That difference decides whether automation survives outside the demo. This guide covers why existing procedures fall short, what an executable instruction looks like, and the four steps for rewriting one you already have.
Why don't existing work instructions work for AI?
Almost every written procedure in an organisation is a memory aid, not a complete description. That is efficient: a new hire reads the instruction, shadows someone for two weeks, and picks up the rest from the people around them. The document never has to be complete, because the environment fills it in.
That assumption disappears the moment a system performs the task. Three kinds of knowledge then turn out to be missing, every time.
The implicit decision rules. "For large customers we check first" assumes everyone knows which customers count as large. For a person that is one glance at a system; for an AI it is an empty variable.
The exceptions nobody writes down. The procedure describes the normal case. The fifteen deviations the team handles out of habit appear nowhere, and those are exactly what produce the errors you find later.
The boundary of the task. Human instructions rarely say what you must not do, because that goes without saying. For a system, that boundary is the most important part of the instruction.
The result is predictable. On delivery the automation works on the examples it was built with, and in production it meets the cases the team knew about for years but never recorded. To avoid that pattern, start with process analysis: our guide on process analysis for automation explains how to score processes before building anything.
What makes an instruction executable?
An executable instruction differs from the version in your quality manual on five points. The distinction is not level of detail but decidability: can a system determine what to do without asking anyone?
| Element | Human work instruction | AI-executable instruction |
|---|---|---|
| Input | "the request" | named fields, required or optional, with a location |
| Decision | "assess whether it's acceptable" | thresholds and rules that resolve to yes or no |
| Exception | learned verbally | numbered list, each with its next action |
| Boundary | implicit | explicit: what the system never does on its own |
| Result | "handle it" | definition of done, plus where the output lands |
The second row pays back the most in practice. An assessment you cannot express as rules is not an instruction point but a judgement, and judgement belongs with a person. Write a procedure out this way and it separates itself into the part that can be automated and the part that cannot.
The fourth row prevents the most expensive incidents. A system that knows it never issues a credit note, never deviates from a price and never rejects a customer can at most prepare something a person declines. That is a fundamentally different risk profile from a system where the boundary was never stated.
[ TIME SAVED ]
Save 5 hours per week on correcting output that follows from unclear work instructions
How do you rewrite an existing procedure in four steps?
You are not starting from nothing. The existing procedure is the skeleton; you add the missing layers.
Step 1: collect thirty real cases
Not three examples, and not the examples someone invents from memory. Take the last thirty cases exactly as they arrived, including the messy ones. This collection does double duty: it exposes the exceptions, and it becomes the test set you use later to check whether the system still performs.
Step 2: have the person doing the work think out loud
Sit next to someone who does the task daily and have them handle ten cases while explaining why they make each choice. What comes out is in no document anywhere. This is the cheapest step with the largest return, and it costs half a day.
Step 3: write the rules as decisions
Turn each choice into a rule that ends in an action. "Check when in doubt" becomes: above a set amount, for a customer with no payment history, or where the standard terms are altered, the case goes to a person. Anything you cannot get into that shape, mark as judgement, and it stays with the team.
Step 4: name an owner and a review date
An instruction goes stale the moment prices, terms or systems change. Without an owner nobody notices, and the system carries on applying the old rules perfectly. Agree who maintains the instruction and when it gets revisited. We describe the same rhythm for live systems in our guide on running AI agents in production.
Where is the line between instruction and judgement?
The question is not whether AI can technically make a decision, but whether you can defend the outcome when it is wrong. Three categories therefore belong on the human side of the line.
Decisions with legal or financial consequence: price deviations, contract changes, rejections. Decisions that affect a person, such as selection, assessment and sanction, which carry separate rules of their own. And decisions where the cost of an error exceeds the value of the time saved, which happens more often than the business case suggests.
Everything else is a candidate, on one condition: there is a checkable source from which the correct answer follows. Without that source a system produces an answer that is right in form and wrong in substance, the problem we cover in our guide on AI hallucinations and reliability.
That source is usually your own documentation. This is why an organised knowledge base is a precondition rather than a follow-up project: our guide on setting up an AI knowledge base explains how to build one.
What does it cost to write and maintain?
For one procedure of average complexity, budget two to four half-days: collecting cases, shadowing, writing, validating with the team. That is effort from your own people rather than a supplier, and that is precisely why it works.
Maintenance is the item that gets forgotten. Every change in pricing, terms, systems or legislation touches the instruction. Plan a six-monthly review per procedure plus a short check whenever a system changes.
Against that sits a return that reaches beyond the automation itself. A written-out procedure speeds up onboarding, makes cover during absence possible, and records how your company works instead of leaving that knowledge with a handful of people. That is an asset, not documentation. The same reasoning sits underneath our guide on automating business processes.
Conclusion: the instruction is the real work
In nearly every stalling AI implementation the instruction is the weak link, not the model. Collect thirty real cases, have an operator think out loud, write decisions as rules and appoint an owner, and you have done most of the implementation already.
That investment also stays yours, whatever technology you put underneath it later. We build business automation on instructions you can read, change and take with you, because a process you can write down is a process you own.