What approval gates are, and why your AI should not be allowed to issue a refund
The design pattern that separates an automation you can trust overnight from one that will eventually cost you a customer.
Most conversations about business automation focus on what the system can do. The more useful question, and the one that decides whether you can sleep while it runs, is what it is not allowed to do.
An approval gate is a rule that says: this action never happens until a specific human says yes. It is not a safety feature bolted on afterwards. It is the thing that makes an autonomous system deployable in a real business at all.
The three lanes
Every action an automated system might take belongs in one of three lanes. The work is deciding which.
Lane 1: Handled automatically
Routine, reversible, and bounded by facts you have already published. Answering whether a unit is available. Booking a tour into an open calendar slot. Logging a maintenance request as a work order. Sending a confirmation text.
The test: if it goes wrong, can you fix it with an apology and five minutes? A tour booked in the wrong slot is annoying. It is not a loss.
Lane 2: Handled, logged for review
Actions with real judgment in them, where doing nothing is worse than acting, but you want to see what happened. Re-engaging a lead that went cold. Rescheduling a vendor. Marking a caller as suspicious. Recommending a lead be closed.
These appear in the morning digest as a record, not a question. You are not approving them, you are staying informed, and over time this lane is where you learn whether the playbook matches your judgment.
Lane 3: Waits for approval
Nothing here moves without a human. The categories are consistent across industries:
- Money out. Refunds, credits, fee waivers, discounts, goodwill gestures.
- Contractual commitments. Lease terms, pricing exceptions, warranty decisions, anything that binds you.
- Legal weight. Notices, anything resembling legal or medical advice, anything with a deadline attached.
- Damaged relationships. An angry customer, a complaint, a threat to leave a review.
The common thread is irreversibility. Not "important," not "expensive," but hard to take back. A $40 credit you did not authorise is a small amount of money and a large amount of precedent.
Why a well-built system needs this more, not less
There is an intuition that better AI needs fewer guardrails. The opposite is true in practice. A system that is obviously clumsy gets supervised closely. A system that is fluent and usually right gets trusted, and the failure, when it comes, arrives with total confidence and nobody watching.
The failure mode is rarely something dramatic. It is a plausible-sounding answer to an unusual question. A price that is roughly right but not your price. A commitment that sounds like something you would say. These are exactly the errors that slip past a quick skim of a log.
What a gate looks like in practice
A properly built gate has four parts:
- Detection. The system recognises this class of request before responding, not after.
- A safe holding response. The customer is not left hanging. "I've passed that to Dana, who'll come back to you first thing" is a complete, honest answer.
- Context for the human. The transcript, the customer's history, what the system would have said, and why it stopped.
- A one-tap decision. If approving takes more than a few seconds, it will not happen and the gate becomes a bottleneck.
The part vendors do not like discussing
Gates cost conversion. A system that quotes a price on the spot closes more jobs than one that says a human will confirm tomorrow. That is a genuine trade-off and anyone claiming otherwise is selling.
The reason to take the trade anyway is asymmetry. The upside of an unauthorised commitment is one faster booking. The downside is a price you have to honour, a tenant expecting something you did not promise, or a client who believes they received advice. Those are not symmetrical outcomes, so the conservative default is correct even though it costs something measurable.
How to audit any vendor in ten minutes: ask them to write down every action their system can take without a human. Then ask what happens when a customer asks for a discount, threatens a bad review, or says something the system has never seen. A good vendor answers immediately and specifically. A bad one talks about how advanced the model is.
Building your own list
If you are scoping automation, write the lane-3 list before anyone writes code. Sit down for twenty minutes and list every action in your business that would be expensive or embarrassing to take back. That list is the spine of the whole project and it is more valuable than any feature comparison.
You can see ours on the how it works page, and the industry-specific versions on each industry page.