Intercom is in the business of offering its customers a suite of tools to make customer contact and service easier and more efficient. As such, the world of bots is very much in their lens. Bots are, after all, often held up as the technology innovation that will fundamentally change how customer service works. So it’s no surprise to see that intercom has launched its own bot service, Operator.

The idea of Operator isn’t to replace other forms of customer contact, but merely to augment the existing relationship that end users have with intercom. Mundane tasks such as collecting contact information or suggesting relevant help articles are prime candidates for bot attention. The idea is that in an organization that wants to both provide better customer service and reduce the cost of that service, freeing human workers up to provide added value services makes more sense. So Operator has a set of rules and machine learning goodness to recognize when a bot’s input is useful and, more importantly, when it is not.

Of course, thanks to some high-profile historical examples (Microsoft Tay, anyone) bots have gotten a bad rap. My experience of customer service bots, much like my experience of many implementations of IVR (interactive voice response) has been pretty poor. A good example, that we’ve all experienced with IVR, and that has been repeated in the bot world, is the inanity of the same question being asked over and over:

Operator_Inline_03

Or when a bot can’t understand anything beyond a series of pre-determined if-then-else statements:

 

Operator_Inline_04

Bots CAN be a helpful tool for customer support situations. But when their modus operandi is simply to block customers from actually talking to a real person, they have the side-effect of really impacting upon customer satisfaction.

Bots work best for strict flows

As Intercom points out, to really understand the potential of bots, it is important to understand their strengths and weaknesses. Bots work best when they follow strict flows or simple rule sets. Think Google Assistant and Siri. What makes these services effective is that they require direct user input for them to reply. They only interact when a user asks them for specific information or to complete a task. They don’t try to predict or infer when to interact with a user or follow a logic tree to insert themselves where they aren’t required.

Operator_Inline_01

Google Assistant completing a simple task for the user with well-defined inputs.

Building bots with manners

Intercom takes the approach that the reason bots have proven ineffective to date is that they don’t take cues from the way humans interact, especially when it comes to developing rules from good manner norms. As humans, we understand what rude means. From a very young age, we’re taught not to eat with your mouth full, the seat is not for feet and when someone is talking, you listen and don’t interrupt. These are some of the simple manners parents teach their children but which are totally analogous to how we interact with bots today.

Some examples of manner norms, and rules that can be developed from them:

  • Don’t talk with your mouth full = Do one thing well, not two things poorly.
  • The seat is not for feet = Know where the bot belongs and don’t put it where it doesn’t.
  • When someone is talking, you listen and don’t interrupt = When humans are talking the bot doesn’t need to.
  • Manners are as important in the landscape of bots as they are with humans for one simple reason: bots are starting to interact with us in ways only humans did before.

Operator has attempted to codify this principle, that of good manners, into the way it works once deployed. The Intercom design team have focused on four distinct design patterns in order to achieve this. Their intention is that Operator will be:

  1. Helpful: Operator will only suggest actions or answers to customers or teammates that have a high chance of being useful.
  2. Tactful: It will never appear uninvited during an active conversation between a business and a customer, or block a customer from communicating with a business.
  3. Restrained: It won’t send follow up messages to customers if they don’t first engage with it. Operator messages are short and precise. It will quickly provide clear routes to follow, and avoid trapping users in loops, or a prolonged back-and-forth.
  4. Nuanced: Manners and messages are adjusted to suit a person’s context. Operator’s logic is designed around who the participants in a conversation are, what they need, and how they’ll interpret its actions.

However translating this intention into actual product behaviors is difficult and this is where it gets a little soft-focused. Intercom articulates how Operator will actually embody these manners by using the following examples:

  • Response time notifications – Operator will let users know when they can expect a response from the team and collect the required contact details
  • Automatically answering user’s questions – Operator automatically offers support articles, but according to Intercom, it won’t blindly spit back answers to customers. If Operator does make a suggestion that answers the user’s question, it will close the conversation automatically.
  • Measuring customer satisfaction – Once a conversation is over Operator will send a survey to the customer to gauge their level of satisfaction

MyPOV

All of the issues that Intercom alludes to are real ones – bots have proven somewhat ineffective at really giving customers a better experience. But identifying issues, and coming up with solutions are two different things and the three use cases that Intercom identified are pretty standard ones – any decent automation platform will offer response time, knowledge base suggestions and customer satisfaction harnessing – while these are useful, and if done correctly ease the customer support burden, these are areas where poor experience has been the norm with historical automation initiatives. I’m a little dubious about just how much intercom moves the needle here, and organizations should be cautious when embarking upon bot-based customer support forays. My suggestion is to trial small implementations and assess the effectiveness of automation before jumping in headfirst.

Ben Kepes

Ben Kepes is a technology evangelist, an investor, a commentator and a business adviser. Ben covers the convergence of technology, mobile, ubiquity and agility, all enabled by the Cloud. His areas of interest extend to enterprise software, software integration, financial/accounting software, platforms and infrastructure as well as articulating technology simply for everyday users.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.