The Question My Team and I Ask Before Letting AI Touch Anything Customer-Facing

A capable AI tool can still be the wrong choice for a specific customer-facing task, and a less capable one can sometimes be perfectly fine — capability alone isn't the question that actually determines safety here. Before recommending AI for anything a customer will directly interact with, my team and I ask a narrower, more specific question that has little to do with how impressive the tool's general abilities are, and everything to do with what happens on the specific occasions it gets something wrong.

This distinction matters because most vendor conversations, and most internal evaluations, naturally gravitate toward capability as the primary axis of comparison — which tool is smarter, which tool handles more edge cases, which tool scores higher on some published benchmark. Capability is a real and relevant factor. It's rarely the factor that should be deciding whether a specific customer-facing task is actually safe to automate.

The question that actually matters

What happens, specifically, the first time this tool gets it wrong in front of a customer — and how bad, realistically, is that specific failure?

The question isn't "can this tool generally handle customer interactions well." It's "what does the worst plausible version of this tool getting it wrong actually look like, for this specific task, with this specific customer." A capable tool handling a low-stakes task can fail in a way that costs almost nothing. The same tool handling a high-stakes task can fail in a way that costs a relationship, and the gap between those two outcomes has nothing to do with how capable the underlying tool actually is.

Why capability and risk aren't the same axis

A highly capable tool used on a high-stakes task can still be a bad bet if the rare failure case is severe enough — capability reduces how often it fails, not how bad the failure is when it happens.

A more capable tool generally fails less often, but it doesn't change what happens on the occasions it does fail. If the failure case for a specific customer-facing task is severe — a wrong answer about pricing, a mishandled complaint, an incorrect commitment made in the business's name — then even a low failure rate can be an unacceptable risk, regardless of how impressive the tool's overall capability looks in a demo, because a rare but severe failure can do more lasting damage than a frequent but trivial one.

A concrete comparison of two customer-facing tasks

An AI tool confirming an appointment time has a low-severity failure case. The same tool quoting a final price on a custom service has a high-severity one — even if it's the exact same underlying technology handling both tasks.

Consider two customer-facing tasks that might both be handed to the same AI tool. Confirming an upcoming appointment time has a low-severity failure case — if the tool gets the date slightly wrong, the mistake is usually caught quickly and corrected with minimal damage. Quoting a final price on a complex, customized service has a much higher-severity failure case — a wrong number stated confidently to a customer can create a real dispute, a damaged relationship, or a financial loss the business has to absorb. The underlying technology might be identical in both cases. The acceptable risk level is not.

What this means for deciding where AI goes first

Tasks with a low-severity failure case are reasonable early candidates regardless of stakes elsewhere in the business. Tasks with a high-severity failure case need either a much higher confidence bar or a person kept in the loop.

Ranking customer-facing tasks by the severity of their worst plausible failure, rather than by how exciting or valuable the task looks, tends to produce a safer and more sensible rollout order — low-severity tasks go first and build trust, high-severity tasks either wait for a much higher confidence bar or keep a person actively in the loop rather than fully handing off the judgment, which means the business's AI rollout order ends up determined by risk tolerance rather than by which task happened to look most impressive to automate first.

Why this framework also helps with vendor conversations, not just internal decisions

Asking a vendor directly what the worst plausible failure looks like for a specific use case, and how often it realistically occurs, surfaces more useful information than asking about general accuracy statistics.

This same question is worth bringing directly into conversations with any vendor proposing a customer-facing AI tool — rather than asking only about general accuracy or capability, asking specifically what the worst plausible failure looks like for the exact use case under consideration, and how often that failure realistically occurs in practice. A vendor's answer to that specific question tends to reveal far more about genuine fit than any general capability claim, and a vendor unable or unwilling to answer it clearly is itself a useful piece of information.

Why this question gets skipped under enthusiasm

It's easy to evaluate a tool purely on how well it performs in a demo and forget to separately ask what the cost of its rare failure actually is for this specific use case.

A compelling demo naturally focuses attention on how often the tool gets things right, which is the wrong half of the question to be asking before deployment. The more disciplined version of evaluation asks both halves — how often does it fail, and how bad is it when it does — and treats a customer-facing rollout as ready only once both answers are genuinely acceptable, not just the more flattering one.