The support experience can be usefully thought of as part of your product: users will not always be able to accomplish their goals in-app, and will instead need to interact with your product’s support experience, whatever that is. Much like any other aspect of your product, the goal isn’t strictly to minimize costs, it’s to create a compelling and delightful experience that leaves users happy.1 And one way to do so is by blurring the line between “regular application functionality” and “functionality only available by contacting support”. This article explains how, using a running example of an airline support bot.
Companies that view support purely as a cost center will sometimes try to reduce these costs in ways that make the customer experience worse. This leads to unhappy users, and unhappy users affect the company’s bottom line (in the form of increased churn, brand damage, reduced word of mouth recommendations, and so on). These secondary costs are sometimes harder to measure, or they only manifest over longer timescales.
Suppose you’ve purchased a plane ticket. Later, you realize you forgot to add a TSA PreCheck number to your reservation.2 You’re a little annoyed with yourself for forgetting, but you definitely don’t want to have to deal with the the hassle of showing up to the airport without this on the reservation. But after spending several minutes hunting around on the website and the app, you can’t manage to find a way to update the reservation. So you contact support. Minutes tick by waiting for the “next available representative”.
Finally, you get connected with someone. You’re probably more annoyed than you should be now, but because you’re a nice person and it’s definitely not the representative’s fault the airline didn’t expose this functionality in their app (or it is buried somewhere undiscoverable), you’re polite and make your request. The representative of course needs you to re-supply all the same context you had when logged into the app or website. Perhaps there’s some additional authentication step, but in the end, minutes later, you have the PreCheck number added to the reservation. Phew!
Now then, is that a good experience? In one sense, we might argue this was success, so long as the wait time wasn’t too long and the support agent was friendly. But thinking more holistically, the experience was actually kind of frustrating. You knew what you wanted to accomplish, yet couldn’t find a way to do it yourself within the application. After being thus disempowered, you then spent time waiting for a representative, giving them context they needed to carry out the request on your behalf.
Adding a TSA PreCheck number after the fact isn’t exactly a rare situation, and there’s no real reason why it can’t be fully automated by a support bot. Shown here is a demo, built with an LLM-free support bot.3
Not only is this much faster, with the task being accomplished in 15 seconds instead of 10 minutes, but it is delightful for users when tasks are as simple as they ought to be. Users are generally happy to talk to a human for unusual situations that aren’t easily automated. They aren’t enthusiastic about contacting support for tasks that really seem like they should be accomplished with a few clicks.
We can think of a bot like this as either “automated support”, or we could think of it as simply another way of surfacing app functionality. It just happens to be triggered using natural language, and the experience feels conversational, but users don’t experience it in the same way as a typical support interaction. Because it’s fast and 100% reliable, it acts more like a product feature; users can come to trust the experience as much as they would any other part of the application.
The “shelf space” problem in applications
A problem with applications as they exist today is limited “shelf space” for functionality. There are only so many screens and places to cram buttons before user are overwhelmed and unable to find what they need. So businesses often make a somewhat artificial decision to limit the functionality available. Adding a TSA PreCheck number after the fact perhaps doesn’t make the cut (“where would we put the button?”), and so users wanting this functionality end up needing to contact support. That’s silly. It’s costly for the organization and worse for users. Everybody loses.
A good UI makes it possible to surface the long tail of application functionality, without taking up shelf space. Our LLM-free structural chatbots accomplish exactly this. They supports the usual “talk to a human” chat, but also make it easy to to expose hundreds of commands, each triggered by natural language and with rich autocomplete for discoverability. A single portal in the corner of your app gives access to all of it, and the bot can respond with contextually appropriate UI elements to help the user accomplish their goals, right there in the conversation, quickly.
Not every request will have an automated way of handling, perhaps because it occurs infrequently or is somehow unusual, and that is also fine: the same conversational interface can escalate to a support rep at any point, with context passed along. Over time, support interactions that occur frequently can be distilled to automated flows and surfaced within the same UI. Support costs go down, and users avoid frustration and save time.
If you’re working in this area or like the vision here and want one of these LLM-free bots for your app, we’d love to hear from you. Send us an email at acid-burn example dotcom.
Footnotes
-
If you google “support is not a cost center”, you’ll see a number of articles making the point that support is not just a cost center to be minimized. Rather, it is a place to generate value. ↩
-
Or perhaps you need to add a checked bag to a reservation. Or any number of other changes to a reservation that aren’t obviously achievable within the app. ↩
-
This sort of bot can be embedded anywhere in an application or website, and the place it is invoked can provide relevant context to influence the bot’s behavior. For instance, if the user is already on a scren showing a particular reservation and requests “add my tsa precheck number”, the bot can pre-select this reservation or just assume it and continue with the rest of the flow. ↩