How to decide what an AI should be allowed to answer on its own

Most conversations about AI-assisted support start in the wrong place. Someone asks which model is best, or whether it can "sound natural enough." Those questions matter eventually, but they're not the one that decides whether the thing actually works. The one that decides it is: for this specific business, which questions is it allowed to answer completely on its own, and which ones get handed to a person before a customer ever sees a reply? Get that line wrong and you either have a bot that escalates everything, which is no better than no bot, or one that confidently answers things it shouldn't, which is worse than no bot. Getting the line right is most of the actual project.

Start from what's already been answered a hundred times

Before touching a model, we go through a few weeks of real support tickets or chat logs and sort them into two piles: questions that come up constantly and have the same correct answer every time, and questions that depend on judgment, context, or a specific customer's situation. "What are your hours," "where's my order," "do you have this in stock" — that first pile is usually bigger than people expect, and it's the only pile worth automating on day one. The second pile — a complaint, a pricing exception, anything with money or a relationship on the line — stays with a person regardless of how well the system performs elsewhere. We're not looking for every question the AI could plausibly answer. We're looking for the smaller, safer set it should.

Confidence isn't a feeling, it's a rule you can write down

"Escalate when it's not sure" sounds reasonable until you have to build it, because a model doesn't know what it doesn't know the way a person does. What actually works is grounding every answer in your own documentation and past tickets — retrieval against a real source, not the model improvising from general training — and then setting a concrete rule for when a match is good enough to answer from and when it isn't. No matching source, a question that touches a policy exception, anything mentioning a refund or a complaint: those are rules, not vibes, and they're the ones you can actually test and adjust after launch instead of hoping the model "just knows."

The escalation path matters more than the auto-reply

Businesses spend most of their attention on getting the automated answer right and almost none on what happens when it hands off, and that's backwards — the handoff is where trust is won or lost. A good escalation doesn't just dump a raw transcript on a person; it hands them the question, what the system already checked, and why it didn't answer, so the human isn't starting from zero. A bad one makes the customer repeat themselves, which is worse than if no AI had touched the conversation at all. If you only have the budget to get one part of this right, make it the handoff, not the first reply.

Review the misses, not just the catches

The line you draw on day one will be wrong in places you can't predict from logs alone, so the system needs a way to show you where it guessed badly — a flagged list of answers a person had to correct, not just a count of tickets closed. We check that list weekly in the first month of any support automation we build, because it's the fastest way to find a question that looked safe to automate and wasn't, or one in the "needs a human" pile that's actually simple enough to move over. The line isn't static. Treat it like a setting you tune, not a decision you make once.

The businesses that get real value out of AI-assisted support aren't the ones with the fanciest model behind it. They're the ones who were honest about which questions are actually safe to hand over, built a real off-ramp for everything else, and kept checking their own line instead of trusting it by default. That's a smaller, less exciting project than "AI answers your support inbox" — and it's the version that still holds up six months in.