Chatbot, help center, or agent: choosing the right path for customers

The question "do we need a chatbot?" almost always comes before the one that matters: which requests you receive, how often, and what it takes to close them. Some are solved with a well-written page, others need to read that customer's data, others should never go through a machine at all. This guide helps you make that split before choosing the tool.

The cost of getting it wrong isn't technical: it's a customer going in circles inside an automated conversation while the office is open and someone could be answering them.

A month of requests, lined up

You already have the material to decide with: the support inbox, the call log, the messages you've received. Take a representative period and classify each request with three questions.

• Is the answer the same for everyone, or does it depend on who's asking? "How long is delivery" has a public answer; "where's my order" doesn't.
• Does it need a piece of data that lives in a system, and which one? Order status, contract deadline, item availability, service history.
• What happens if the answer is wrong? A wrong opening time is an annoyance; wrong guidance on how to use a product, on a contractual deadline, or on an amount owed is a different category of problem.

In the end you'll have three groups very different in size: many repetitive, public questions, a sizable group of personal requests, and a few sensitive ones. Each group has its own answer, and it isn't the same one.

If a page solves it, everything else is excess

Some repetitive questions exist because the information isn't there, or is somewhere nobody finds it. In that case, building a conversational assistant means putting a middleman in front of content that just needed to be written.

Before automating, it's worth asking where the question comes from. If "how much does shipping cost" comes up after the customer has looked at the product page, the page doesn't say it, or doesn't say it where it's needed. Moving the information to the point where the doubt arises eliminates the request instead of handling it, and it's almost always the cheapest fix.

Personal requests depend on data

"Where's my order" isn't hard to understand: it's hard to satisfy, because you need to know who's asking and read a system. The demanding part isn't the conversation, it's three tedious things.

• Recognizing the customer reliably, without giving anyone who knows an email address access to someone else's data.
• Reading the data where it's actually true, not from a copy updated once a day: a shipping status that's half a day old generates more contacts than it prevents.
• Knowing what to do when the data isn't there or isn't clear. That's the case where a poorly designed system makes something up, and it's the moment it loses the customer's trust for good.

If any one of these three isn't solved, that category of request isn't ready for automation, no matter how frequent it is.

The request-and-channel matrix

The fastest way to get everyone on the same page is a table with one row per type of request. The rows below are an illustrative example, for a company that sells and services products.

The column you fill in last is the one that matters most. An automated path with no declared exit isn't a path: it's a trap.

The handoff to an agent has to be designed

• The exit conditions need to be written down: words that signal a complaint, two failed attempts on the same point, an explicit request to speak with someone, a topic among those reserved for people.
• Whatever was said needs to reach the agent. Making the customer repeat everything cancels out the benefit and worsens the mood of someone who was already unhappy.
• Outside business hours, the behavior changes: if no one can answer, the system must say so and take contact details, not promise a handoff that won't happen.
• Whoever receives the handoffs needs to know about it and have time to handle it. An extra channel with no one monitoring it produces unanswered requests, which is worse than not having opened it.

What to measure

The number of conversations handled isn't a result: it tells you how many times the tool talked, not how many times it actually helped. You need measures that look at the outcome.

• How many conversations close without the customer writing back or calling about the same reason in the following days. It's the only real indicator of resolution.
• How many end with a handoff to a person, keeping planned handoffs separate from ones caused by a failure.
• Which questions get wrong or generic answers. These need to be sampled and read by someone who knows the business, on a schedule decided in advance.
• Whether the load on agents has actually dropped for repetitive requests, or has just changed channel.

If, after a reasonable period, failure-driven handoffs are still the majority, the conclusion isn't that you need a better system: it's that those requests weren't automatable with the data and content you have today.

What this guide doesn't cover

Here you choose which path to entrust each type of request to. Preparing the documents and sources an assistant will rely on — what to fix, what to remove, how to keep them updated — is a separate job with its own dedicated guide. The precise rules for when an assistant should stop and call in a person are also covered separately.