The quality gate: putting a human in the loop for AI in customer support

Leaders who ask me about AI in support rarely ask whether it works. They ask whether it will say something stupid to a customer. That is the right question, and the answer is a quality gate: a small set of checks that sits between the model and everything that matters. In my work the gate is not an afterthought. It is the product.

What a quality gate is

A gate is a rule-based layer that decides, for every AI output, one of two things: this can continue automatically, or a person must look first. The model proposes. The gate disposes.

It matters because language models are confident in a flat way. A wrong answer and a right answer read the same. A gate gives you something the model cannot give itself: a consistent, auditable reason why a given item went through or was held.

The five checks I use

1. Confidence threshold. Every classification or draft carries a score. Below 0.90, it does not continue. I picked that number by looking at what the daily sample caught, and I would expect you to adjust it for your own data.
2. PII check. Before anything is posted to a shared channel or written to the CRM, I scan for phone numbers, addresses, card fragments and similar. Matches are masked or the item is held.
3. Duplicate check. If the same customer and the same order already have an open ticket, the new message attaches to it instead of creating another.
4. Rule check on outbound copy. Tone, offer, opt-out wording and personal data are checked against written rules before any message to a customer is scheduled or sent.
5. Daily QA sample. Each day a person scores twenty routed items. This is the check on the checks. It is how I notice that a label is drifting before customers do.

The review queue

Everything that fails goes to a human review queue. Design it like a real inbox, not a log file:

• Each item shows the original message, the model's proposed label, and which check failed.
• The reviewer can accept, correct, or reject in one action.
• Corrections are saved, because they are the best training material you will ever have for the next version of the instructions.
• The queue has a visible size and an owner. If it keeps growing day after day, someone is asked why.

I keep the queue short on purpose. If it is long, the gate is either too tight or the labels are too fine, and the fix is upstream, not more reviewers.

A worked example

An illustrative draft reply is produced for a customer who complained twice in a month:

Hi Sara, I'm sorry about the second late delivery. I've asked the team to call you on +971 5x xxx xxxx today and I've added a goodwill credit to your account.

The gate runs:

• Confidence: 0.93, passes.
• PII: the phone number is in the text, so the item is flagged. For an outbound message to that same customer a number may be fine, but the rule says no numbers in the body unless the CRM confirms they match the contact on file.
• Offer: a goodwill credit is not in the approved offer list for this tier, so the rule check fails.

The draft goes to the review queue with two reasons attached. A person edits it, approves it, and the corrected text is saved. Nothing unreviewed went out. Without the gate, an unapproved credit would have reached a real customer.

(The name and phone number above are invented for illustration.)

What went wrong the first time

I first built the gate as a single threshold. Confidence above the bar, go. It missed two kinds of failure completely: confident wrong answers, and correct answers that contained data they should not have. The model was sure and the content was still unsafe.

That is why there are five checks and not one. Confidence tells you how sure the model is. It tells you nothing about whether the output is permitted. You need both kinds of check.

Trade-offs

• Every check adds friction. The gate should block the few things that can hurt, not everything that looks unusual.
• Rules written in a document nobody reads decay. Keep them in the workflow, as code or configuration, where they actually run.
• A person in the loop is a cost. I treat the review queue as a budget: if the volume goes above what the team can clear in a day, I tighten the labels, not the headcount.
• The gate does not remove the need for judgement. It decides where judgement is spent.

How the gate changes over time

A gate is not set once. I review it on a rhythm, and each review asks the same three questions:

• Which items did the daily sample catch that the checks let through? Those become new rules.
• Which items did the checks hold that a reviewer approved without any change? Those rules are too strict, or the label is badly defined.
• Which reviewer corrections repeat? A repeated correction is a missing line in the model's instructions, and fixing it once removes a whole class of queue items.

This is slow, unglamorous work, and it is where most of the value is. A team that treats the gate as a living part of the process ends up with a queue that gets shorter for good reasons. A team that sets it and forgets it ends up either ignoring the queue or switching the gate off, and both of those are how AI in support goes wrong in public.

For how this fits into a full routing workflow, see how I cut handling time from 2 hours to 20 minutes and the dispatch workflow in HubSpot and n8n.

What I would build for your team

I would write down, with you, the five or six things the AI must never do to a customer, and turn each into a check that runs on every item. Then I would build the review queue before building the clever part, so the safe path exists first. After that, a daily sample with a named scorer keeps it honest. The aim is simple: AI in front of customers with nothing unreviewed going out.

Email: kodirovrukhillo@gmail.com