4 cases where AI must stop and ask
You have picked the task, written the instructions, measured the impact and chosen the tool. One question is usually postponed until the first mistake: what may the system not decide on its own? An automated step with no stopping rule is like an eager new employee with no written authority. It acts on everything it understands, and some of what it understands is wrong.
An example from the floor
A building-materials distributor runs its orders over WhatsApp. A sales rep sends: release three hundred bags of cement to the North Project customer on account. The system reads it without ambiguity: known item, clear quantity, registered customer. If it executed straight away, everything would look fine.
But that customer's unpaid balance is already past the credit limit in their file. The system must stop here, not because it failed to understand, but because the decision is not its own. The right response is neither a silent refusal nor a silent execution: it is a message to whoever holds the authority, naming the customer, the quantity and the value, with approve or reject.
The difference shows up a month later: one company discovers debt nobody decided to take on, the other has a record of every exception and who approved it. Automation speeds up execution; it does not transfer authority.
Four cases where the system must stop
Not every step needs approval; too many approvals kill the benefit as surely as none. These four always deserve a stop:
| Case | WhatsApp example | What the system does |
|---|---|---|
| Financial impact over a limit | An unusual discount, or a release on account past a credit limit | Prepares the request and routes it for approval |
| A request with two readings | Send the order to the new branch, when two branches are new | Asks one specific question instead of guessing |
| An exception to a written policy | A return after the return window has closed | States the rule and asks the manager to decide |
| An outside effect you cannot undo | Issuing an invoice or messaging a customer | Shows the draft, then acts after confirmation |
Everything else should just run. A goods receipt matching the purchase order, a quantity updated after a stock count, an answer about an item's remaining balance: these are reversible, and approvals in front of them turn the system into a new queue. The sorting principle is one question: how hard is this step to undo?
What a good stop looks like
A bad stop just says the request cannot be completed. A good stop reaches the right person with four elements: what was requested, why it stopped, the expected impact, and the options now. Such a message is answered in seconds from a phone; one without them starts a chain of calls.
Give every exception a deadline and a backup approver. A request sleeping in a travelling manager's phone blocks the work as effectively as a rejection. That is the point of running the system from WhatsApp: the decision reaches its owner wherever they are.
An automated step saves time, but it does not carry responsibility. That stays with whoever owns the decision, so let the system deliver it to them rather than take it on their behalf.
Checklist before you switch on any automated step
- You wrote down what executes directly and what waits for approval.
- You set a clear numeric limit on the value or quantity needing approval.
- You named the approver, the backup when they are away, and the time window.
- The approval message explains the reason and the impact, not just a refusal.
- Every executed step leaves a trace: who asked, what ran, when, and on whose approval.
- You tested the edge cases before go-live, not after one hits a real customer.
Review the limits after a period of use
Day-one limits are estimates; after two months you have data. Review the approval log: an item always approved without discussion means the limit is too low, while one often rejected or amended means the underlying rule needs review rather than the system being at fault. This keeps the real approvals and drops the ceremonial ones, which is the difference between a system that helps your team and one that annoys them. The same applies to stock movements over WhatsApp, where the gap between a reversible step and a costly one is obvious.