Where the human belongs
Where human judgement changes the next step
These are common reasons to require review. A human response is not a guarantee of correctness; the reviewer still needs relevant evidence, authority and enough time to consider it.
Hard to reverse
The action has real consequences if it is wrong
Refunds, contract changes, anything that touches money or a commitment. When undoing the action costs more than pausing for a person, the pause is worth it. Automate the preparation; keep the approval human.
Genuinely ambiguous
The input does not map cleanly to a rule
A reply that could be an objection or a scheduling note, a record that fits two categories, a case the rules did not anticipate. A machine forced to choose will choose confidently and often wrongly. A person reads the ambiguity a rule cannot.
Outside the rules
It is an exception, not the standard case
The system should recognise what it was not built for and route it to a review queue rather than forcing it down the happy path. The exception handled by a person today is the pattern that informs a better rule tomorrow.
Relationship-sensitive
A customer would notice a machine
A moment where the wrong automated touch reads as careless, a sensitive account, a complaint, a high-stakes negotiation. The system can prepare the response; a person decides whether and how to send it.
The rule that runs the seam
Give the reviewer a decision they can actually make.
A request should identify the proposed action, its current version and the person authorised to decide. Include the evidence needed to approve, reject or request a change. Keep the consequential step pending until the response meets the agreed conditions.
Record what is being approved: the quote version, proposed discount and next action. A generic Approved checkbox can lose that context.
Name the responsible reviewer and an authorised substitute. A reminder or reassignment does not itself grant permission to proceed.
Make waiting visible. Show the request owner, age and agreed response deadline; do not turn silence into approval.
Recheck the approved inputs before execution. If the material terms change, obtain a decision for the revised request under the agreed policy.
Fictional quote review
Q-204 is waiting for a discount decision.
In this example the manager approves a specific quote version before it can be sent. The team chooses a response deadline and an authorised substitute. These are illustrative operating rules, not a client result or a universal approval policy.
| What happens | Request state | Allowed next step |
|---|---|---|
| Quote version 3 is submitted | Pending review | Prepare the context; keep sending blocked. |
| The manager is unavailable | Still pending | Route to the authorised substitute; retain the original request age. |
| The response deadline passes | Expired under this example policy | Escalate to the request owner; do not assume approval. |
| The quote changes to version 4 | Version 3 superseded | Request review of version 4 before sending. |
| Approval arrives for version 3 | Outdated response | Retain the decision as evidence; it does not authorise version 4. |
| An authorised reviewer approves version 4 | Approved for version 4 | Recheck the terms and perform only the approved next step. |
The design principle
The reviewer needs a specific decision, and the workflow needs a specific answer.
Record the response against the request version and verify that it still applies before continuing. Keep rejection, expiry and cancellation visible rather than letting all of them appear as a request that simply stopped. For a technical failure after approval, use the separate exception workflow instead of asking the person to approve the same action again.
Handle uncertain technical outcomes separately from the business approval.
Design the exception and recovery path ->