Three cases, followed all the way through.
Every other page on this site describes the mechanism in the abstract. This one follows three individual cases from the moment they arrive to the moment something is released, so you can see precisely where the operator acts and precisely where a person still signs. These are illustrative of how the mechanism works rather than accounts of named clients.
A supplier invoice that does not match its purchase order
The everyday case that eats a clerk's afternoon: the invoice is nearly right, the variance is small, and whether it can be passed depends on a tolerance nobody has written down.
-
01
Arrives
The invoice lands in the shared accounts mailbox as a PDF attachment, like several hundred others that week.
-
02
Read
The operator extracts the supplier, the line items, the totals and the referenced purchase order, and pulls the matching order and goods receipt from the ERP.
-
03
Compare
Quantity matches the receipt. The unit price is 3.1 per cent above the order. The operator recognises this as a price variance rather than a quantity dispute, which are handled differently in your framework.
-
04
Apply your rule
Your codified tolerance permits price variances under four per cent on this supplier category without a fresh approval, provided the contract is current and the year-to-date variance on that supplier is still inside its own ceiling. The operator checks both.
-
05
Act
The invoice is coded to the correct account, cost centre and project, matched against the order and queued for payment in the next run.
-
06
Evidence
Attached to the transaction: the source PDF, the order and receipt it matched, the tolerance rule applied, the year-to-date figure it checked, and the fact that no human approval was required under that rule.
Where the human is. If the variance had been above four per cent, or the supplier contract had lapsed, or the year-to-date ceiling had been breached, the operator would have stopped and routed it to the category owner with all of the above already assembled.
A counterparty returns your standard agreement with edits
Most of the redline is cosmetic. The value is in finding the two clauses that actually shift risk, and not spending an afternoon reading to find them.
-
01
Arrives
A revised agreement comes back by email from the counterparty, tracked changes on, forty-one pages.
-
02
Read
The operator reads it clause by clause against your playbook rather than against the previous version, so cosmetic renumbering does not register as a change.
-
03
Compare
Thirty-one edits are formatting, defined-term tidying or clause reordering. Eight are substantive. Two of those eight touch clauses your playbook marks as non-negotiable.
-
04
Apply your rule
The liability cap has been raised from your standard multiple, and the indemnity has been narrowed to exclude a category your playbook requires. Both sit in your must-escalate list. The remaining six fall inside positions you have accepted before, and the operator surfaces the precedent for each.
-
05
Draft
It prepares the redline restoring both non-negotiable clauses in your house wording, accepts the six it has precedent for, and drafts the covering note explaining each decision commercially.
-
06
Evidence
Every one of the forty-one edits is listed with its classification, the playbook rule applied, and where precedent exists, the prior deal it came from.
Where the human is. Nothing goes back to the counterparty. Counsel opens a prepared redline with a two-item decision list at the top, and releases it. The operator never sends, never signs and never files as executed.
A customer reports something that is not the problem they think it is
The ticket says one thing. The history says another. Sorting that out is exactly the diagnostic work that keeps senior agents from the tickets that need them.
-
01
Arrives
A ticket comes in reporting that a scheduled export has stopped running, flagged urgent by the customer.
-
02
Read
The operator pulls the account, the export configuration, the last fourteen days of run history and any recent changes on the account.
-
03
Compare
The export is running normally and completing. What changed nine days ago is the destination folder permission, so the file is being written and then rejected at the far end.
-
04
Apply your rule
This is a known issue type with a documented resolution, but the fix touches the customer's access configuration, which your framework marks as never-automatic.
-
05
Draft
It prepares the first response explaining what is actually happening in plain language, the exact permission that changed, and the two options for resolving it, in your support team's tone.
-
06
Evidence
The run history it checked, the change log entry it identified as the cause, the knowledge base article it matched, and the reason it did not apply the fix itself.
Where the human is. An agent reviews a diagnosed ticket rather than an undiagnosed one, confirms the cause and releases the response. Any change to the customer's access rights is made by the agent, not the operator.
What all three have in common.
Different departments, different documents, different systems. The same four things happen in each, and they are the four things that separate an operator from a script.
It reads more context than a person has time to
In each case the operator pulled surrounding records, history and configuration before deciding. That is not cleverness, it is simply having the time to check things a person under queue pressure often cannot.
It applies your rule, not a general one
The four per cent tolerance, the non-negotiable clause list, the never-automatic access change. None of these are inferable from general knowledge. All three came out of the Codify stage of the engagement.
It stops at the line you drew
Every walkthrough ends with something a person does. The operator prepares the case up to that line and never past it, and the line was fixed per workflow before it ever ran live.
It shows why, not just what
In each case the evidence trail names the specific rule and the specific data it checked. That is what lets a reviewer disagree with one decision without distrusting the whole system.
Walk us through one of yours.
Bring a real case from a real queue, ideally one your team argued about. We will walk it end to end the way these three are walked, and tell you where we think the line between operator and person should sit.