Are you thinking about maybe, possibly, probably using a chatbot in your service desk this year? That’s great! The bandwagon’s pretty crowded, but I’m sure there’s a seat for you. Maybe you hope to be like the North Carolina Innovation Center, which tested chatbots for routine internal IT requests, such as password resets. If the chatbots complete the easy tasks, live support analysts can be freed up for the more challenging ones. Or maybe you’re interested in BugBot, a sample bot written for Cisco Spark, which converts a simple human-like chat with a customer into a ticket for your support desk platform. If bots can lighten our workload and make us more effective, what are we waiting for? Let’s get started!
Not so fast. While chatbots may be able to make customer support quicker, cheaper, and easier, your organization may not be bot-ready. Imagine, for example, that you’re a Zendesk shop, and you’re considering using Answer Bot, Zendesk’s bot. Using machine learning, Answer Bot scans a customer’s email to understand their request and suggests articles that will answer their question. And, according to its maker, Answer Bot learns as it goes, so “every suggestion it gives will be better than the last.” Answer Bot gets its information from Zendesk Guide, the system’s integrated knowledge base. So, to be ready to use Answer Bot, your organization would need accurate, current, readable information in the knowledge base. The bot can’t be better than the knowledge base. It can’t spin straw into silk.
Leslie will help you assess whether you’re ready to use bots at HDI Conference & Expo.
Ask yourself the hard questions about the current state of your automated communications. How ready is your organization is to use bots? To find out, take a clear-eyed look at how successful your organization is at the types of automated communication it's already using. Here are eight candid questions about the current state of communication in your support desk. If you answer “yes” to two or more of these, you’re not ready to use a bot.
Do your customers have to repeat information when they’re connected to a live agent that they’ve already typed in or said to the IVR? If so, it suggests the hand-off from automation to live person doesn’t work well. That’s not healthy if you’re thinking of using bots.
Does your IVR say, "Listen closely as our menu items have changed…?" Besides being a stale and irritating phrase, this suggests you’re not equipped to explain changes in automated communication clearly to your customers. You may not be able to sell a bot to the people you serve.
Do your web forms force customers to choose options that don't describe their actual problem? If a high percentage of the people who use the dropdown menu in your web form are choosing “Other,” you’re not ready for a bot.
Is your template library (or knowledge base) woefully out of date, but you lack the bandwidth to clean it up? For two reasons, a “yes” answer to this question shows you’re not ready for a bot. First, bots rely on stored information. If your information collections aren’t good, there’s a garbage-in, garbage-out reality you’ll have to face if the bot is going to rely on the KB. Second, your team is stretched to its limit. While we count on bots to make life easier for our support analysts, that happens eventually, not immediately. If your team is too taxed to maintain the KB properly, finding the time to launch a bot isn’t likely.
Are the "smart" systems you're using now kind of glitchy? Let’s say, for example, you’re using employee recognition software to issue analysts “Job Well Done” badges from their peers or managers. Sadly, the software isn’t working right, and people’s badges keep getting “lost.” If your organization isn’t good at recognizing and fixing these types of glitches right away, you’re not bot-ready.
Do you accept customers' contacts in channels where you don't always have the capacity to serve them? For example, do you “turn off” live chat when chat volume gets too high or wait times are too long? This suggests a “burning building” mentality about omnichannel service that won’t work well with the planfulness required to launch a bot.
Do you lack the budget to update your service management software, so you're not using the version you need? While this isn’t a question about automated communication, it does point to a bot being a software purchase, not a new religion. If you can’t afford the needed upgrade to the software you have, how will buying new bot software, or paying for bot development, hit your budget?
Does your support desk fail to get customer input when making decisions about how you'll deliver service? I’m not suggesting that you interview each customer about whether they’d rather interact with a bot than a live analyst. (Unless your analysts are really cranky, that question will get an uninformed “no.”) But if your organization is in the habit of making big decisions without getting much input from your customers, you’re not ready for a bot.
Bots are diverse. They can be simple or complex, mechanical or intelligent. They can support analysts or customers. They can be “dumb” or smart. But they are always communication tools. The successful ones will truly communicate with your customers. You don’t have to wonder whether your organization is ready to use a bot. Take an honest look at the current state of your automated communication, and you’ll know.
Bots can be simple or complex, mechanical or intelligent. They can support analysts or customers. They can be dumb or smart.
Leslie O'Flahavan has delivered writing courses for support center staff, customer service agents, and social media managers, helping thousands of professionals hone their customer-focused writing skills. She helps support organizations train agents to write well in all service channels, measure the quality of their writing, and revise and maintain their entire library of canned answers. Leslie is the coauthor of Clear, Correct, Concise E-Mail: A Writing Workbook for Customer Service Agents. Visit her E-Write website, follow her on Twitter, or connect with her on LinkedIn.