PROGRAMMING COMING SOON!
It seems that the nostalgia industry will never die. But anyone who wants to turn back the clock might get more than they bargain for.
For example, you’re on your way home from work. You duck into the grocery store to pick up one small item, like a can of tomato sauce. Immediately you feel like you’re on an episode of Supermarket Sweep. When you get to the end of the aisle you look at the registers and every one of them has a line.
At this point you need to do a quick analysis of which line is shortest and moving the fastest, as well as your proximity to that line in relation to everyone else doing the same thing as you. Choose the wrong line and it is frustration city.
Nowadays the saving grace for those folks who want to get in and out quickly—you know, like the people who have their fare ready before they get on the bus—most grocery stores have an array of self-checkout stations. This allows you to scan, bag, and pay for everything as fast as you can and be on your merry way, slurping spaghetti until you heart is content.
Ok, so maybe nostalgia isn’t all it’s cracked up to be. But what’s really going on at the grocery store?
What we’ve got here is self-service. We see self-service everywhere. In many cases it’s become the norm, like at ATMs and gas stations in 48 states and the District of Columbia (I’m looking at you, New Jersey and Oregon). Of course, self-service can take many different forms. When we’re talking about addressing customer concerns one of the most used channels is the phone.
Automating common tasks over the phone with a self-service application cuts to the heart of customer service and customer experience. Customers want their issues resolved quickly and self-service allows companies to collect and disseminate information quickly. If self-service can’t do that, then it doesn’t matter. Plain and simple.
For many tasks, self-service is the contemporary grocery store checkout because callers spend less time with self-service than they would with an agent. In other words, self-service gives customers exactly what they want. Companies like this because it helps improve first contact resolution, which leads to happier customers.
There is no shortage of interactive voice response (IVR) horror stories. After all, people notice bad IVR more than good IVR. If an IVR doesn’t provide callers with information quickly then they won’t like it. There’s no reason for customers to experience IV-ARGH!! as opposed to IVR.
Happy, delighted customers are always the end goal. But every company is different and a one-size-fits-all approach to customer service just doesn’t pass muster. That’s why a custom self-service application is so beneficial.
A custom application lets companies step back and as “what is the customer journey here?” Doing so lets them laser-focus their attention on that question and develop a call-flow that maximizes customer happiness.
What does a bad call-flow look like? Too many menus and unintuitive navigation, long prompts that callers can’t skip, too many prompts or confirmations that add time to each call, failure to give callers an easy way to transfer out of the application if needs be, are all examples of things that grate on callers.
So what should companies focus on when creating a call-flow? When thinking about the customer’s self-service journey it’s helpful not to just think about what information callers want, but also how and when to present that information to them for maximum efficiency.
Although sitting down and hammering out what that call-flow will look like can be the most difficult aspects of making a custom solution, the nice thing is that once it’s done managing the call-flow becomes a process of continuous monitoring and optimizing. Making minor adjustments to an application is a lot easier than rebuilding entire sections of it.
Publish Date: July 21, 2016 5:00 AM
One of the appealing aspects of the bar Cheers was that it was a place where everyone knew your name. A friendly face that knows your preferences doesn’t just make you feel appreciated, it’s also more efficient. Forget the formality, this type of personal attention lets you cut right to the heart of the matter and get things done quickly.
Delivering this type of personal service is easy for a small business with a small client base, like a bar. But large enterprises with thousands of customers can scale this experience to fit their needs as well. That’s what customer relationship management (CRM) software does.
Personalization is the use of customer-specific information to create custom communications tailored to individuals. No doubt you’ve received an email from a major corporation that included your name in the greeting or the subject line. That’s an example of personalization.
In this space we’re talking about personalization in voice-based customer service. What does that mean? Broadly speaking, personalization allows you to use virtually any piece of customer data to improve customer experience. A couple of examples will provide some clarity.
There are a few different steps involved with getting personalization to work. First, is identifying the caller. Second, is figuring out what data to use and how to use it. Third, is presenting that data in an effective way using a voice application.
For any automated voice application to be able to provide personalized service it needs to be able to identify the caller. There are a few different ways to do this. One is using automatic number identification (ANI). This is a backend process that passes the phone number of the incoming call to the interactive voice response (IVR) system. The IVR can then cross-reference that number with the phone numbers in the company’s CRM, which is where most companies keep customer data.
Other ways to verify caller identity include, having callers enter an identification or account number, or through voice biometrics.
Once the voice application verifies who is calling it can then tap into the company’s CRM to pull out any relevant information for that individual. That can be anything as basic as their name and address. Or it could be a bit more complex, like looking at their past ten interactions with the company and suggesting options based on past activity.
The point is that once a call is linked with an individual customer it’s possible to continuously query the CRM for personal data throughout the call. Naturally, this will vary depending on what your company is trying to accomplish.
Voice-based communication doesn’t have to be one-way though. One of our examples highlighted the use of text messaging. Imagine that a big retailer wants to in-store customer experience. In this case a customer, we’ll call him Steve, makes purchase, which updates his CRM data with his most recent transaction.
The transaction triggers an action that can vary depending on how the business logic is set up. It’s possible for the voice application to query the CRM, or for the CRM to simply push the appropriate information to the voice app. In this case, the process finds the Steve’s mobile number and the name of the product he purchased. Before Steve gets to his car, he receives a text message:
“Steve, we hope you enjoy your new Apple iPod. From 1-5 (low to high), how would you rate your shopping experience today?”
Steve can then respond via text, and his rating goes into the CRM where it can be used for analysis.
There are many reasons why companies would want to personalize communications with customers. For example:
Publish Date: June 22, 2016 5:00 AM
You want to make sure that your most important communications actually make it to your customers and that they engage with them, right? That’s a pretty basic desire no matter what business or industry a company is in.
Nowadays there are so many different communications channels it can be difficult to know which one is right for your customers. Of course, having omni-channel capabilities is ideal for many. But this also comes down to understanding how people engage with business-to-consumer communications.
Text messaging has a big advantage over other communications channels because people actually read text messages. While people struggle to get to “Inbox Zero,” it’s almost impossible to ignore glancing at your phone when a text message arrives. A 2010 study [pdf] found that over 90% of people read text messages within three minutes of receiving them. This tells us one critical thing about text messaging: it’s wildly efficient.
Virtually every mobile phone has SMS/MMS capabilities. This tells us another important benefit of text messaging: it provides access to a lot of people.
Text messaging is even more popular than ever. For example, a recent Nuance study [pdf] found 28% of Millennials preferred text messaging for communications. Considering that the Millennial generation is one of the largest in terms of population, this is a considerable development.
All of this means that SMS/MMS isn’t just an add-on. If anything, text messaging should be a central plank in every company’s communications platform. And it’s not as though adding text messaging functionality is a huge hurdle, at least from a technology perspective.
While it’s always possible to undertake deep integration with your current telecom infrastructure, doing so is unnecessary. Pretty much any text message vendor that you deal with will have APIs that allow their tech to talk to your tech. This makes it easy to connect things and to switch if your needs change and you decide you want additional tools or features.
Text messaging is a very personal form of communication. For companies that personalize communications with customers, text messages allow you to develop that relationship even further. At the same time, this also means that text messaging isn’t good for reaching out to customers willy-nilly.
Information sent via text has to contain real value for its recipient. Whether that’s a coupon code, a special offer, a security confirmation, or a payment reminder, failure to create value leads to people opting out of text message notifications.
The last thing you want to do is spam customers via text messages. This could result in your telecom provider suspending your text message capabilities, or other penalties. So be careful!
Overall, text messaging is a very impactful communications channel, and it’s only becoming more relevant as time passes. It provides a number of benefits and is easy enough to implement that every business should incorporate it into their communications efforts.
Publish Date: June 9, 2016 5:00 AM
Our last post noted how important it is to control the initial customer interaction when it comes to customer self-service over the phone. Once you’ve got control a new challenge arises, namely what do to with that control. Our advice is to wield a scalpel in your approach rather than a hammer.
Some of the nation’s largest insurance companies use Plum technology for their voice communication needs. Insurers looking to streamline customer service processes and improve contact center ROI should take a look at how other companies are already using Plum to accomplish these goals.
Arrowhead’s customer service process used to be completely manual and paper-based. In an effort to boost efficiency, the company invested in a self-service solution for checking the status of open claims and paying bills.
The results were immediately apparent. Less than 10% of calls ended up being fielded by agents, where that used to be the only option. The change not only allowed Arrowhead to scale their customer service operation without requiring additional personnel. At the same time average hold time for callers decreased, which meant they could easily absorb a higher call volume.
Read the whole Arrowhead case study.
One Major Insurance Company (MIC), had so many incoming calls on a daily basis that agents didn’t have the time or resources to give customers the high-touch service they expected. MIC determined what callers’ most frequent inquiries were and used Plum technology to automate access to that information.
For example, MIC discovered that agents were processing a lot of payments manually. Rather than hiring more agents or outsourcing the task, MIC automated it. Plum’s PCI-compliant communications platform ensured that customer information remained secure.
After introducing automated payment processing, MIC saw its call containment rate skyrocket. The company also realized savings on payment processing by several orders of magnitude. Rather than spending several dollars per payment processing call, automation enabled MIC to get that down to several cents per call.
Read the full MIC case study.
Erie Insurance is a Fortune 500 company with millions of clients. In an effort to improve the customer service of their claims division Erie launched a customer feedback initiative. Customers access the surveys via the web or over the phone.
With the new channels in place, the number of customers responding to customer service surveys increased dramatically. (The company mailed out surveys prior to the change.) With a bevy of new data, Erie was able to more accurately measure agent performance. The company also gained insight into its sales process as a result of these surveys, which led to change and improvements on that front as well.
Read the full Erie case study.
Enterprise-level insurance companies, because of their sheer size, have a need to effectively control the high volume phone calls that come with the territory. Creating a phone-based customer experience that is easy to use and efficient is a great way to build up the trust between company and customer. Part of that involves giving customers the information they want, fast. No matter what combination of self-service/live agents or in-house/outsourced voice-based customer service you have, Plum gives you the control to maximize both the cost and efficiency of those processes, all wrapped up in a great customer experience.
Publish Date: June 2, 2016 5:00 AM
Control can be an elusive thing. Like a handful of sand, the tighter you grip it the faster you lose it. This idea has a practical application when it comes to voice-based customer service, especially for large insurance and financial services that use call centers.
Insurance and financial services companies, especially, have a vested interest in providing great customer service. After all, these are the companies that people trust with their money. How can these companies develop and maintain that trust?
It’s no secret that many companies view their customer service efforts as a cost center. That’s not to say that companies don’t value customer service–they do. Nevertheless, cost-cutting measures have led companies to outsource all of their call center services, a practice known as business process outsourcing (BPO).
Controlling customer experience is even trickier for large enterprises that outsource more than one process, e.g. claims and payments. This could mean that each process has its own dedicated provider, with its own IVR and corps of agents. In this situation, the same customer can call about claims and to make a payment and have drastically different experiences. This is not ideal.
Why do companies stick with their call center providers if they’re not getting the desired results? Usually because breaking a contract with a BPO consumes significant time and resources. This creates a “locked in” situation where benefits of breaking a contract don’t outweigh the cost. With so much time and money invested in the current call center(s), no way to force change, and no guarantee that switching to a different vendor will improve things, maintaining the status quo becomes increasingly attractive.
But is this necessary?
What if, instead of outsourcing an entire business process, companies just outsourced part of it? The most important point in voice-based customer service is the initial phone call that customers make. If companies can control that initial point of contact with customers, then they can shape the entire process that follows.
A centralized IVR application that fields all of a company’s incoming calls and re-directs them appropriately solves a big part of the control problem. If Insurance Company X has a centralized IVR, it takes the calls and then passes them on to the BPOs based on real-time data and availability.
Here, Company X still outsources the agent component of its call center service, but instead of the call center’s IVR doing all of the work, Company X central IVR ensures that the right calls get to the right agents. Furthermore, because Company X controls where the calls go it accumulates data on these interactions, making it easier to measure vendor performance.
This centralizing approach creates a more consistent customer service experience and makes it easier to personalize that experience for individual callers.
Establishing control over voice-based customer service is step one. Figuring out how to wield that control is a whole different animal, which we will cover in part two of this series.
This approach really does work. Check out this case study from a client that used this strategy to great success.
Publish Date: May 25, 2016 5:00 AM
There’s something to be said for organization, and the more pieces that are in play the greater need to keep everything orderly. When we’re talking about managing high volume phone calls interactive voice response is the manna for your trek through the desert.
One of the great things about using an IVR to centralize incoming calls is that it doesn’t matter how many agents you have or where they are–in-house, outsourced, or whatever it may be. One of Plum’s customers is a major financial services company. Let’s call them Major Financial Services Company (MFSC) in order to preserve their anonymity for this exercise.
Well MFSC has a national reach and they needed a way to efficiently support all of their various, customizable products. So no matter what product someone bought, regardless of where they were in the country, that person could call up MFSC and get service that catered specifically to the product(s) they purchased.
The company had an IVR before switching to Plum, but didn’t use it to its fullest capacity. Because of the massive size of MFSC’s operation, the company uses a number of out-sourced call centers across the country. Here’s where things get really cool.
Armed with the Plum platform, MFSC built multiple applications using the VoiceXML language and tailored each to meet the needs specific products. By linking the Plum platform to their customer CRM (thanks APIs!), as soon as the IVR picks up the call, which is instantaneous–every time–the application deduces who is calling and intelligently routes their call to the appropriate support center.
All of this occurs in real time. This approach ensures that the agents who are best equipped to help a given customer get those calls, based on their availability. Not only did this scheme help customers get the information they needed more quickly, but it also helped MFSC to measure and normalize their expectations for their call centers.
Of course, it helps that MFSC is a proactive company, not simply content to sit on its laurels. No. The company uses data provided by VoiceTrends to continuously update and optimize its applications to continue to provide the best possible experience for customers.
The result of these efforts from MFSC, among other things, is an extremely high call containment rate, which generally sits at 85% or higher.
Grab the full case study, which goes into greater detail, to learn more about how MFSC accomplished all of this and the benefits they derived from the Plum platform.
Publish Date: May 12, 2016 5:00 AM
With the Olympics coming to Rio de Janerio this summer there will be plenty of individual and team athletic achievement on display. Individual performances can be awe-inspiring. Just think about Usain Bolt at the London games, for example.
With individual sports it’s clear where the main onus lies. But the benefit of team sports is that there are others to help share the load. One player’s weaknesses are supported by another teammate’s strengths.
The same dynamic can be applied to software development. Not only can a team approach utilize each member’s specific skill set, but by narrowing the focus on a given project it can be more efficient in both the short-term building phase and the long-term maintenance phase of the application’s life cycle.
Let’s use a hypothetical example to illustrate how all of this works. Enter Rupert’s Insurance company. Rupert’s sells home, life, auto, and motorcycle insurance across the country. But the company prides itself on being a national brand while providing the service of a local company. They want to be like Cheers, where everybody knows your name.
In order to accomplish this, the company decides that they want to customize their self-service offerings at the state level. This requires dozens of different apps that are both product and brand specific. Building this many apps from scratch could be a time and resource intensive undertaking. However, using a visual development platform like Plum Fuse makes the entire project much easier.
In this example we have four different players:
Now getting everything set up and integrated is one of the biggest hurdles to clear. At this point let’s assume that finance and marketing have collaborated on a call-flow so that the developers know what the application should look like.
Using that call-flow as a blueprint, one of Rupert’s core developers, Ryan, begins the task of building the application framework. In Fuse, this is done using a drag-and-drop visual interface. Mr. Rupert, the company’s CEO, wants to make efficient use of his developers and can’t really afford to take Ryan away from his primary duties for too long.
So Ryan creates the skeleton for the application. He connects all the pieces together, links the application to the company’s CRM database, and does some basic testing to make sure it works. At this point, Ryan needs to get back to his backlog of other projects.
Because Fuse is a collaborative platform, Ryan shared access to the application with the other stakeholders. These granular controls enabled him to limit who could do what in the application. The options here include: view, edit flow, edit audio, clone, or re-share. This way no one could tinker with the skeleton, making more work for Ryan.
Now Erin is in the marketing department and she is in charge of branding. It’s her job to make things sparkle. She also keeps an eye on all of Rupert’s external communications and ensures that they conform to the companies’ established guidelines. Ryan gave Erin permission to edit the prompts (which are part of the call-flow here), to edit the application’s audio, and to clone the app.
The company chose to start with California, so all of the prompts and audio recordings were tailored to customers in the Golden State. Knowing that the company needed apps for each of the 48 contiguous states, Erin and the marketing team created prompt copy and audio recordings for each of the other states while Ryan put the bones of the application together.
Armed with a cache of copy and audio files, Erin cloned the California application. Starting at the beginning of the alphabet, she designated the new application clone for Alabama. She uploads the new audio files and enters the updated prompt text to match what her team developed for Alabama.
Once she’s done updating the Alabama application, she passes off the task of deployment to one of Rupert’s junior developers, Kelly.
As a member of Rupert’s development team Kelly has full access to the application. Once the app is in her court, she selects the right phone number and tests out the cloned application. Using Fuse’s “run” option lets her test things out before going live. Once everything is working smoothly, Kelly deploys the application.
Any future changes the applications require will fall to Kelly so that Ryan can maintain his focus on core development projects.
Creating and deploying and application isn’t the end of the story. Just because an application (or a multiple applications) provide self-service for customers doesn’t mean that they should be ignored.
When Ryan shared application access he also included the Vice President of Marketing and Product Development, Holly. Holly can only view the application and the data that it produces in VoiceTrends, which is Plum’s native analytics toolkit. Holly doesn’t need to understand the nuts and bolts of how the application works, she just needs to know that it does work and how customers use it. Therefore, access to the app’s VoiceTrends data is all she needs.
After deployment, Rupert’s applications function properly, but properly isn’t the same as optimally. This is where Kelly re-enters the field of play.
She keeps an eye on the data that Rupert’s apps produce. If she notices an abnormal trend or app performance declines in some aspect, then Kelly, who has complete access to the application, can go in and make any needed changes. She can also talk to both Erin and Holly who have access to the application’s data in order to brainstorm solutions.
If Velma needs updated prompt copy or audio files, she can tap Erin for that. And Erin can go ahead and input those changes directly to the application herself. That way she can make sure that everything is just exactly perfect without having to use Kelly as a go-between.
At the end of the day, this type of platform and development approach helps to streamline app creation. Allowing team members to apply their expertise directly to an application reduces the number of dependencies for creating and managing technology. The result is a team where the whole is greater than the sum of its parts.
Publish Date: May 5, 2016 5:00 AM
When I moved from Chicago to Denver in 2010, I got myself a Google Voice number as an easy way to have access to a local phone number. Once you have a Google Voice number in most cases you can port it away from Google for a small fee and that can be your new phone number.
When I switched from an Android phone to an iPhone (which doesn’t support Google Voice natively) I figured it was time to port my Google Voice number to my account. I followed all of the steps necessary, but at the end of the day there was some restriction that prevented me from porting my number away.
“What gives?” I thought. So I created another Google Voice number that had a different (less desirable, to my idiosyncratic mind) prefix, but the same last four digits. I was able to port this number away from Google.
In the United States, as in most other North American countries, telephone numbers are composed of ten digits. This is known as the North American Numbering Plan (NANP).
The breakdown of a phone number is familiar to pretty much everyone. The first three digits are the area code, which refers to a broad geographic region. The next three digits denote the prefix, which typically corresponds to a smaller area within the area code’s region. With four remaining digits every local exchange has 10,000 possible unique numbers (from 0000 to 9999). This is known as the “line number.”
It seems that almost every telecom provider these days includes free nationwide calling in their plans, but before they did (and any of those that still don’t) prefixes and area codes signified to the PSTN what counted as a local call and what was long distance.
But let’s get back to those blocks of line numbers. When you think about all of the thousands of prefixes across the country that’s a lot of numbers to keep track of. That’s why the FCC utilizes number pooling to manage and reallocate numbers. Now the FCC doesn’t do all of this on their own. Neustar, a technology company, administers the number pooling efforts in the United States.
In order to foster competition within a given area, FCC regulations don’t allow any one company to come in and take all 10,000 numbers attached to a given prefix. Instead, these numbers are divvied up into blocks of one thousand that local exchange carriers can then acquire.
I’ll use my hometown of Rochester, Michigan as a hypothetical example. The area code there is 248, and growing up our prefix was 652. But as you can see from the table below, the last four digits of our phone number depended on our telecom carrier. If we had service with Carrier 3, our only options for a phone number would be from 2000-3999.
HYPOTHETICAL NUMBER BLOCKS
As mentioned above, Neustar administers number pooling in the US and you can actually see reports by region that detail which thousand-blocks are available, assigned, and retained throughout the country.
So if you’re looking for a new phone number or a phone number that includes specific digits or a sequence of digits and can’t find an available one that’s most likely because it’s already in use.
Think of phone numbers like web domain names. Sure it’d be great to own the domain name of a big brand, like Apple, or IBM, or Amazon, but those are already taken.
If someone else is already using that phone number or it’s controlled by a different carrier, you may be out of luck.
Thanks to the Telecommunications Act (1996), the FCC mandated that all local carriers offer number portability. This was later expanded to include provisions specifically for mobile phones as well.
There are two types of number porting, Local Number Portability (LNP) for fixed lines (i.e. landlines), and Wireless LNP (WLNP) for mobile numbers.
In the U.S. there are three different types of number porting.
There may be additional conditions and/or fees associated with porting a number from one carrier to another. But those vary from one carrier to the next.
In most cases porting numbers is a simple, seamless process. The FCC requires all carriers to allow customers to port their numbers out, but not all carriers can port every number in. Porting a landline to a mobile number, or a number from a pre-paid account to monthly billed account have been known to cause issues.
The reasons for this vary from one carrier to another. However, one reason proffered for the restriction relates to safety. Because an area code and a prefix are linked to a specific geographic area, restricting numbers ported into a given area ensure that help can reach you in the event of an emergency.
Regardless of the reason why, there are some numbers that carriers cannot port in to their system. If you’re switching carriers make sure to check with them beforehand to ensure that your number will port properly.
New phone numbers don’t just fall from the sky. From time to time, an increase of new devices and services in a given region results in using up all of the available prefixes. When this is eminent, Neustar begins the process of creating a new area code to serve that area. Each new area code generates 792 new prefixes (note: prefixes cannot start with 0 or 1), and each prefix has 10,000 lines.
Entities that have one or more toll-free number can port those numbers between different carriers as well. This process is more formal and is called a RespOrg, which is shorthand for Responsible Organization. The term is used as both a noun and a verb. How fun!
A responsible organization is any company that manages the registration for toll-free numbers in the U.S. (Note: Plum Voice is one such company.) A company called Somos (formerly SMS/800, Inc.) performs similar administrative duties for toll-free numbers that Neustar does for regular phone numbers.
Of course, the same limitations on number availability exist with toll-free numbers that exist with regular numbers. But as the number of toll free area codes grows, e.g., 800, 888, 877, there may be more opportunities to get the number combination you want.
All toll-free numbers are portable. “The FCC requires that toll free numbers be portable, meaning that a toll free number subscriber can ‘port’ his or her number to a new provider when changing toll free number service providers.”
If a customer has an outstanding balance on their account, or some other obligation to their incumbent carrier, that company may deny port requests for that customer’s toll-free number(s). But if all obligations are met, carrier resistance can come down to unwillingness or an attempt to retain a customer against their wishes. Of course, neither of these justifications reflect well on a carrier so it is in their best interest to release toll-free numbers for current accounts.
Sometimes I still wonder why I couldn’t port my original Google Voice number. It must have been one of those numbers that was simply unavailable. But I’ve made peace with that fact. Hopefully, you won’t experience that frustration and the information above helps you better understand where phone numbers come from, who controls them, and what options exist for porting numbers from one carrier to another.
Publish Date: April 29, 2016 5:00 AM
Omni-channel communications appeal to a lot of companies. And it makes sense that they do. Having that type of power at your disposal allows businesses to meet customers on their turf. While this means there are more channels to manage, when done right, the benefit is that omni-channel communications create a better customer experience.
Now omni-channel is different from multi-channel. Omni-channel centralizes information so that different communications channels same work in concert to create a seamless experience. Omni-channel work flows create a path to task completion that constantly moves forward. This isn’t always the case with multi-channel. Multi-channel is simply the existence of different channels, e.g. phone, web, brick-and-mortar. But in a multi-channel situation these different channels don’t intersect.
How many times have you emailed a company and gotten a response that doesn’t completely answer your question? Then you call the company and talk to an agent, but they have no idea who you are or why you’re calling, so you have to spend five minutes explaining how you got to that point. It’s as though once you picked up the phone the company pressed reset on your issue.
The goal of omni-channel communications is to avoid that reset process.
Even if you know all about omni-channel and want to utilize it with your company, with so many potential communications channels available it can be challenging to figure out just where to start.
When implementing self-service options, the telephone is a great place to start for a number of reasons. First, virtually everyone has a phone or access to one. That speaks to reach. Second, incorporating interactive voice response (IVR) is cost effective. Your ROI with IVR is about as close to immediate as things get. Third, a number of other channels build off of, or incorporate voice so it’s logical to get that channel up and running first to save time down the line.
Of course, just like Miles Davis’ Kind of Blue is a gateway album into the world of jazz, so too is IVR a gateway to omni-channel communications. Mobile apps, web, email, chat, social media, and live agents are all areas ripe for expansion once you’ve got your feet wet with IVR.
Getting all of these technologies to play nicely together is achieved using APIs. APIs make it easier to achieve a seamless customer experience using more than one communication channel. Because APIs make the integration process easier, companies don’t need to settle for a product suite that does one or two things really well and several additional things “just ok.” APIs enable you to seek out and utilize best-in-breed technology.
The reality of the situation is that customers don’t just opt for one channel or another. Oscillating between voice, mobile, web, social media, and email, for example, is very realistic depending on a customer’s preferences and the particular situation they want to resolve. APIs allow you to account for all of these possibilities.
Not only do APIs link your various communications channels together, but they also allow those channels to connect with customer data. This helps to keep track of customer preferences and to personalize communications.
All of this is well and good, but it doesn’t explain what–exactly–a seamless customer experience looks like. Let’s put some meat on the bones of what we’re talking about here with a practical example.
Pete keeps his money at Bank of the USA. He calls up the bank because he wants to check his transaction history. The Bank’s IVR picks up the call and he navigates to the right menu option. The phone system recognizes that Pete is calling from his mobile based on his customer profile.
Once Pete makes his choice, the self-service system, knowing that he’s on his mobile phone, asks him if he would rather view his most recent transactions in the Bank of the USA mobile app. Pete decides that that would be preferable, so the system sends him a link via SMS.
Pete hangs up the phone call, opens his text messages, and clicks on the link. This triggers the bank’s mobile app, and after Pete authenticates, he’s taken directly to a page that displays his most recent transactions.
While looking over his account information, Pete notices something unexpected. There’s a link within the app to call customer service so Pete clicks on that link, placing another call to the bank. With access to Pete’s customer profile the bank’s agent sees his recent activity and surmises that he is calling about his recent transactions. Pete explains the issue and they are able to resolve the issue.
In this scenario, Pete started with IVR, shifted to text messaging, which fed into the mobile app, before going back to the voice channel and speaking with an agent. That’s a total of four different communications channels and three transitions between them. By centralizing customer data and providing equal access to that information using APIs each transition in this scenario moved the process further along in a manner that was most convenient for Pete. Forward progress was constant and nowhere along the way did he have to restart from the beginning.
Furthermore, of the four different channel experiences we can identify here, three of them were self-service or driven by automation: IVR, SMS, and the mobile app. Therefore, 75% of Pete’s transaction was contained within Bank of the USA’s self-service workflow.
Not only did this process show Pete that Bank of the USA knew him and catered to his preferences, but it also enabled him to get the information he needed. For Bank of the USA, this transaction was a win because their costliest channel, the live agent, only came into play at the very end. The fact that the agent was prepped to help Pete when he called meant that the agent didn’t need to spend precious time re-hashing the situation. The result is a shorter, more efficient conversation for the agent, which makes the Bank’s agents more cost-effective because they can field more calls.
Let’s return to the suggestion above that voice is a great place to start when creating omni-channel solutions. In our example, a robust voice communications platform had a hand in every step. From the IVR, to the text message notifications, to voice calling integrated into the mobile app, to directing callers to a live agent, the common denominator throughout this example was the prevalence and utility of phone-based channels. This common thread is what makes voice the ideal place to start when implementing omni-channel customer service.
If you have any questions about how to get started with voice as the cornerstone of your omni-channel plans, one of our communications experts can help you out.
Publish Date: April 21, 2016 5:00 AM
What is disruption? It’s a buzz words that is bandied about like crazy in the tech world today. A lot of people set their sites on disruption but few actually achieve it. When you think of disruption as a paradigm shift that alters the way an industry functions, when it does occur the fallout can be seismic.
Cloud computing certainly fits the mold of a disruptive innovation. At least it did. You could argue that the disruptive phase of the cloud phenomenon has subsided as cloud solutions become commonplace.
Of course, just because cloud technology has reached the level of “accepted” doesn’t mean everyone has already adopted it as a business solution. That transition from disruptor status to ubiquity is the spectrum of evolutionary inevitability.
Why add the “inevitability” modifier there? When looking at cloud communications, for example, that environment provides so many benefits and cost savings that once companies sit down and do a cost-benefit analysis it’s pretty obvious which path is lined with a neatly pruned lawn and daffodils, and which one resembles something from a Stephen King novel. Ok, maybe that’s a bit dramatic. But the “doing things the way we’ve always done them, because that’s how we’ve always done it” mentality leaves a lot on the table.
We touched on some of the benefits of moving to the cloud in these pages recently. At this point, however, let’s focus on the hardware element and how the cloud is different from a legacy on-premises system.
Legacy on-site systems don’t function in an either/or relationship when it comes to sunken versus operational costs. The very nature of the system itself ensures that both exist. The problem is that the inherent obsolescence in technology means that overtime sunken costs increase. Adding new servers to increase capacity or replacing failed components just necessitates more financial resources.
At the same time, operational costs persist with a legacy system. When we’re talking about automated communications these include procuring voice and data lines. Don’t forget the cost of paying the system administrators who maintain and update both the hardware and software of an on-site system.
At an infrastructure level, the combination of both sunken costs and on-going operating costs makes premises-based systems expensive to manage.
Compare this situation to a cloud communications environment. Vendors purchase the requisite hardware so you don’t have to. Any concerns about technology obsolescence get transferred to the cloud as well. As a result of this, vendors perform all the upgrades and maintenance on the cloud environment. Thanks to economies of scale, switching to cloud makes sunken infrastructure costs disappear faster than Keyser Söze.
Operational costs assume an altered form after adopting cloud infrastructure, too. Many cloud vendors rely on subscriptions whereby companies that use their infrastructure only pay for the resources they use. Think of scalability like an accordion, so whether you use a lot or a little, like an accordion expands and contracts, cloud infrastructure has you covered. This helps to minimize overall operational overhead, if we want to get alliterative for a moment.
When using the cloud as part of a strategy to automate communications companies can realize even greater savings. Whether your needs include self-service, communications-enabled business processes, or messaging, using a platform as a service that automates these tasks in conjunction with a cloud environment can result in significant ROI.
These are the factors that can be easily measured. There are other positive ripples from the cloud, like less time having to figure out a telecom strategic plan, and the sheer peace of mind that comes from knowing your infrastructure is always up, running, and available.
Granted, there may be some internal disruption concomitant with migrating from a legacy system at the individual company level, but an improved bottom line helps to soften whatever blows that process may attempt. That’s the reason that “the cloud” is barreling down the fast track, past disruption, toward inevitable business solution.
Publish Date: April 12, 2016 5:00 AM
You can’t miss what you’ve never had. And having data and analytics for automated, voice-based customer interactions used to be unheard of.
This deficiency often led companies to take a “set it and forget it” approach to their automated voice communications channel. The problem with this is that the voice channel connects directly with customers. Therefore, treating it like a Ronco Showtime Rotisserie (remember those infomercials?) makes it impossible to know how your automated voice solution affects customer experience.
But the new dawn of voice analytics is here. VoiceTrends is an analytics toolkit designed to give users data for their automated voice applications. It’s built in to each of Plum’s cloud products: DEV, Fuse, and Insight.
Analytics provide insight into the efficiency and usability of your voice solutions. Having access to actionable data allows you to monitor voice applications and optimize them as customer needs evolve. This type of proactive concern for customer experience helps to develop brand loyalty.
Knowing what to look for is the trick to getting the most out of any type of analytics data. A few examples of common questions and problems that voice analytics can inform users about are:
Each of these gets at a different aspect of the customer experience, whether that’s respecting caller’s time, providing the information they need, or making your application usable. So let’s take a look at a use case for VoiceTrends and how it can help users make connections between data, application performance, and user experience.
We’ll start with a basic problem to get our feet wet. Take the first question from above: What is average call length and how can that be shortened?
To get a baseline, check out what your current average call time is. After logging in to VoiceTrends use the menu on the left to open up the Trend Analysis section, and then expand the Call Volume menu. Click on Average Call Length. This will display a graph and a bunch of other information in the main window.
Looking at the month of January it’s possible to see a steady rise in average call length after January 10th. On that day the average call length was 89.4 seconds. By January 31st the average call time increases to 150.2 seconds. This type of consistent increase is a pretty solid clue that something isn’t working well.
Now that you know there’s a problem (thanks data!), it’s time to come up with a fix.
Remember the large corpus of data that VoiceTrends accumulates won’t solve your problem for you, but it does help you make informed choices when problem-solving. There are a few best practices that can address call length issues.
The first is to make sure that prompts are bargeable. This means that callers can interrupt a prompt, or barge in, by making a selection before the prompt finishes. Repeat callers know what buttons to press and when, so forcing them to listen to entire prompts greatly increases the time they remain on the line. Unless it’s critical for callers to hear an entire prompt, make it bargeable.
Second, make sure all of your prompts are necessary. One common mistake we see in this area is with over confirmation. The more menus, prompts, and forms a caller encounters the longer the call is going to be.
Finally, make sure that the prompts present the information in an efficient order. Oftentimes prompts are designed to provide a list of instructions, e.g. “Press 1 for claims, press 2 for sales.” The problem arises when the instructions precede the information. Most callers understand that the options will follow each other sequentially. Therefore, a more efficient prompt would read “for claims, press 1; for sales, press 2.” You can bet that whatever the third option is the caller will know that they should press 3 to get there.
Let’s say that after noticing the trend of increasing average call length a savvy employee realized that they had forgotten to make the application’s prompts bargeable. After building and testing the solution, the updated application with bargeable prompts went live on February 1st. Then, on March 1st we can look at the results to see if the fix worked.
Click on the calendar icon in the upper right corner. This will produce a second drop-down menu for comparison purposes. We looked at January previous, so set this one to look at February. The results plot January in purple, and February in a blueish color.
Note that the blue line experiences a sharp and drastic decline on the first of the month. The rest of the blue line oscillates in the 80-100 second range, which is much more satisfactory.
Purpose-built analytics are pretty new to the world of voice communications. In other words, as we continue to update VoiceTrends and build out even more features, and there are some good ones in the works, identifying problems and testing results will only get easier.
Publish Date: March 31, 2016 5:00 AM
When you’re driving in the car you can opt for any number of routes to get from point A to point B. The most direct path or the scenic route both have their advantages. Regardless of which one you choose, as long as you arrive at your destination it doesn’t matter which course you drive.
The same is true of application development. Some companies have the resources to do things a certain way and others don’t. This isn’t to suggest that one way is better than the other; they’re just different.
In the spirit of education and clarity, we’re going to walk through two different approaches to building a simple voice application using two of our own platforms, Plum DEV and Plum Fuse.
The DEV platform allows users to build applications using VoiceXML, an open standard programming language similar to HTML. Plum Fuse is a rapid application development platform that has an intuitive, visual drag-and-drop graphical user interface (GUI).
Understanding how these technologies work goes a long way toward finding a solution to meet your specific needs, how to leverage a platform as a service (PaaS), and determining what resources are necessary to build an IVR application.
To keep things simple and concise in the following example we’ll look at how to create a basic auto-attendant application. Once the application answers the call the main menu starts with a simple prompt that gives callers four options. These consist of talking to support, sales, or customer service, or to get more information about the company.
The backbone of the application is the main menu. It’s the first thing callers hear after the IVR picks up a call.
For developers with HTML or XML coding experience, putting together the main menu in VoiceXML is pretty straightforward. First, designate and identify the menu
and how that menu will behave . This tag indicates that users will be unable to “barge in” or interrupt the prompt. (1)
In other words, if you called and pressed or said “1” before the prompt finished, the application would not recognize your selection. You would have to wait until the prompt finished to make your selection. Changing the value to “true” would enable barge in functionality.
Now you may be wondering how the automatic speech recognition (ASR) works here. Well the
tag takes care of that in this example, automatically incorporating ASR into the menu. There are multiple ways to initiate ASR, but this default method most closely represents how Fuse works.
The second step is to create the options. These are denoted with a tag. The “Support” choice looks like this: Support. (2) The DTMF component relates to actual key selections on your device. The prompt instructed callers to press 1 or say “support” for support. This line of code assigns the input “1” to the support menu. The “next” function simply directs the application where to go after the number 1 is selected. In this case its to the support submenu.
Because there are four total selections, the above code can be copied and changed to reflect each choice.
Building the same menu in Fuse is even easier. When you first open Fuse all you have is a blank workspace and a Start module. To set up the prompt navigate to the Modules sidebar on the left. Expand the “Basics” section if it’s not already open. The second option is a grey box titled Simple Prompt. (1) Either click the little + to the right or click the box and drag it onto the workspace.
Enter the text for your main menu prompt in the module’s textbox in the workspace. Then, simply click the circle node on the bottom of the Start module and the triangle node at the top of the Simple Prompt module to connect the two elements. Remember that the links between modules are the same paths a call will follow based on caller input.
To build out the menu options in Fuse go back to the left side bar and drag a SimpleMenu module (the second yellow box in the Basics menu) onto the workspace. (2) Our prompt provides four options so click the + sign in the module until you have four input rows. You’ll link these to their corresponding components later, but just add them for now, and select the desired number and verbal inputs for each option.
Note that Fuse enables ASR by default. If you want to turn it off, simply leave the “Say” fields blank and callers won’t have the option of speaking their selection.
What if someone says something that doesn’t align with the assigned choices in the menu? It’s a good idea to give callers a few chances in case they press a wrong key or the ASR doesn’t understand them.
In DEV there are two different tags you can use for error correction. They are and . The first, , covers the ASR if the caller didn’t say anything or if the caller didn’t press anything. (1) The second, , corrects for erroneous key inputs, or invalid speech inputs. (2) For example, if someone presses or says “6” when it’s not a menu option that’s a “nomatch” error.
Notice at the end of both of these sections of code, before closing the tag there is an additional command. This tells the application to go back to the main menu prompt and start the process over again.
The default setting in DEV for how many times the application re-prompts callers is three. See the discussion about the tag below if you want to change this default.
To set up error handling in Fuse go to the title bar of the menuChoice module where you will see three boxes on the right. Click on the triangle box and select the box next to “Error Handling.” This automatically adds “Silence” and “Invalid Entry” to the bottom of the module. (1)
Drag another SimplePrompt module onto the workspace. Type in the error message for either no match or no input. To create the second prompt, you can either repeat the same process, or right click on the module, select “clone this module,” and update the text as appropriate for that error message.
Use a counter to limit the number of re-prompts in Fuse. Expand the “Variables and Math” section in the left sidebar. The last yellow box is labeled Counter. Drag a pair of those modules onto the workspace. Put one next to each error prompt. In our example here we set the counter on both to three attempts. (2) Once either counter registers three failed attempts the program transfers callers to the error page.
Now connect the modules using the circle and triangle nodes on each element. You end up with two chains.
At this point we know the four options that callers will have, but we need to create their corresponding menus, as well as an error page.
Looking at the DEV code you can see that there are three different functions that these pages have.
The first block, Support, passes callers through to another menu. (1) Sales and Service both include a prompt to inform the caller about what action is taking place. (2) The application then transfers callers to the phone number entered in the module. The Info block simply includes a prompt before ending the call. (3)
Let’s go back and look at the Support sub-menu. In order for a caller to get through to support they have to first enter their customer support number. Note in the tag that the caller must enter eight digits because the minimum and maximum are both set to eight. (1)
Callers are prompted to enter their customer support number. Nested within the tag are and tags with associated counters. (2) Notice the nested within both of those tags as well.
The tag is the one here that controls the number of attempts. The event=“noinput nomatch” count=“3” modifier says that once the total number of errors reaches three, to prompt the caller and end the call (the tag). (3)
When the application records the entered number it is designated as “getNum” as indicated in the tag. So once eight digits have been entered, the application uses a prompt to repeat the number back to the caller. The tag tells the ASR what it will be saying, in this case numerical digits. (4) It also denotes which specific numbers to say by retrieving the value stored in “getNum”.
After confirming the customer support number, the application transfers the caller to customer support in the same way that transfers worked from the main menu to Sales and Service. (5) So that section can be copied, pasted, and updated with the correct number.
In Fuse you’ll want to create new pages (i.e. workspaces) for each sub-menu. Including an error page, that’s five total. This helps to reduce cluttered workspaces. To create a new page, click the “+ New Page” button above the left sidebar. Name the page when prompted and repeat this process for the other four pages necessary for the application. Notice that these pages appear at the top of the workspace like web browser tabs.
Now head back to the main application page. Find the Jump to Page module in the Basics menu in the left sidebar. Drag six of these modules onto the workspace. On the first Jump to Page module, choose “Support” from the dropdown menu, which will automatically be populated with the pages you created. Connect the node next to “Support” from the main menu to node on the Jump to Page module. (1) Repeat this process for Sales, Customer Service, and Info. (2)
The two remaining Jump to Page modules are for error handling. Select the error page for both of these. Link each of these to the counters in the error correction loops. (3)
That’s it for the main menu work flow.
Remember with the DEV example that the Customer Service and Sales sub-menus functioned the same way. Click over to the Customer Service page. Select a Transfer module from the Basics menu on the left sidebar. Type in the prompt text and the phone number for customer service. (1) Link the two modules and voila! Finished. Repeat the same process for Sales.
The Info and Error menus have similar call-flows as well. Click over to the Info page and drag a simple prompt module onto the workspace. Type in the prompt message. (1) Drag a Hang Up or Exit module onto the workspace. (2) Link the three modules together. Repeat the process for the Error page. Now four of the five sub-menus are finished.
The last sub-menu, the one for customer service, requires callers to input their customer service number. So drag a Digits Input module onto the workspace and connect it to the Start module. (1) Type in the prompt that callers will hear. Enter “8” in the “min” and “max” digits fields to account for number length.
Now, just like we created error handling on the main menu, we’re going to add it here. Follow the same process by clicking the triangle box in the module title bar and selecting “Error Handling.” Drag in your simple prompt, counter, and jump to page modules for both sides of the error process. (2) Enter all the appropriate text, values, and linked pages, and connect everything together.
The last piece of the call flow is the verification of the customer support number and transferring the call. Drag a Simple Prompt module onto the workspace, as well as a Say Variable module from the Variables and Math section. (3)
Link the Digits module to the Simple Prompt module, and then the Simple Prompt to the Say Variable module. Finally, pull in a Transfer module and link the Say Variable module to it. (4)
Enter the appropriate text in the Simple Prompt module, and set the Say Variable module to “digits.” Type the pre-transfer prompt text into the Transfer module as well as the phone correct phone number and the entire application is finished.
As you can see, when it comes to designing an IVR both coding and drag-and-drop have their advantages. Both approaches also get the job done.
The big question when choosing between platforms is what type of resources are at your disposal? If you’ve got developer talent at the ready, then the coding with DEV is a great option. Or, if you’ve don’t have developers, but still want professional IVR, then Fuse allows you to achieve that.
The preceding example barely scratches the surface of these platforms’ capabilities. Both platforms are free to try, so give one, or both, a whirl and dive into all the powerful features DEV and Fuse offer. Go ahead, build something great!
Publish Date: March 24, 2016 5:00 AM
With the rise of virtual personal assistants, like Siri and Cortana, the way in which they “just work” has started to create a perception that this type of technology should be ubiquitous in all voice applications. This is kind of like how crime procedural TV shows have led to juries expecting “CSI-like” evidence at trials.
Let’s face it, sometimes wants and expectations exceed feasibility. But it’s not enough to just dismiss an idea without explanation.
With that in mind, let’s address the elephant in the room: WHY is natural language processing (NLP) so difficult to implement over a standard voice line?
To begin answering that question we need to take a look at how automatic speech recognition (ASR) functions and compare it to NLP. Now it’s worth bearing in mind that ASR is a rather broad heading that includes. In other words, all NLP is ASR, but not all ASR is NLP. How’s that for alphabet soup?
We’ll cover how ASR and NLP work, and then move on to discuss the financial and technological constraints that NLP faces.
When interacting with a standard voice application over the phone audio data is sent to a computer. The computer turns that wave form into digital information. Then the frequencies derived from that audio are matched to phonemes. Grammars are compiled into trigrams that reflect larger phonetic sounds that can be matched, e.g. tio, nde, sth. The computer compares the audio phonemes to the trigrams to determine what was said. Or, in the very least it creates a list of what it thinks, statistically, was said as well as some possible alternatives.
Armed with this information, that information is matched to a grammar. All interactive voice response (IVR) applications have grammars that define the words the ASR recognizes. Once the information is matched to the appropriate grammar, the application generates a list of potential matches. The IVR then takes the appropriate action depending on whether the information is valid according to the program’s code.
Building a grammar for an IVR application isn’t a trivial matter, which is why we provide those to our customers. For example, a grammar that recognizes street numbers has to be able to recognize all the different possible ways someone might say the number 411.
Basically, what the ASR is doing here is trying to match what a user says with an IVR’s built-in grammar.
Therein lies the primary difference between ASR and NLP. When it comes to NLP, the software attempts to not just understand what is said, but what its intent was.
Think about how you would ask an application like Siri, which is essentially a natural language IVR, to remind you about and appointment on Wednesday at 3pm. There are thousands of different ways that someone could voice this request. Some pieces of this request are more static than others, such as the day of the week or time of day. But the words and phrases that surround those pieces of information can be extremely dynamic. This means to deduce a single intention, an appointment reminder, requires a huge amount of information.
All of the thousands of possible phonetic possibilities are converted into to trigrams. And those trigrams that are most likely to be associated, statistically speaking, with that intention are grouped together. The more an individual uses NLP the more accurately the software can refine and predict that person’s intent for that specific, well… intention.
For example, there’s a band called Camera Obscura, and if I tell Siri to “play Camera Obscura” it tends to place the intent emphasis on camera, and opens the camera application. That makes sense for most people though. It then becomes up to the user to clarify the intent of their request. In this case, “play music by Camera Obscura” generates the desired outcome.
NLP software essentially creates a series of bins where it stores all the different phonetic pieces that can then be grouped together to make more coherent intentions. A single intention will have a huge phrase list. Replicate this process for every possible intention and we’re talking about a lot of data.
Now if you’re thinking about how much it would cost to compile, analyze, and maintain such a large corpus of data, then the numbers on your mental cash register should be spinning at hyper speed.
There’s a reason that NLP isn’t more common. It takes a lot of money to build out the technology for a reliable system. We’re talking several million dollars to get it up and running and another $1–2M per year to continually fine-tune that database once it is built.
Remember that it’s thought that Apple paid around $200M for the Siri technology. But even before that sale, Active Technologies, the start up that spun out of the Stanford Research Institute, where Siri was first developed, raised $24M in funding for it. Pocket change this is not. When you consider that the Siri team at Apple remains one of the largest at the company, the cost of developing NLP keeps going up.
This is why “Big Data” companies with deep pockets and seemingly infinite resources, like Apple and Google, can afford to operate NLP technology. Also, it’s worth noting that the companies that do develop NLP typically only do NLP. This is because they already have a large corpus of data at their disposal so a good chunk of the work is already done. Re-using components for different projects makes NLP much easier for vendors. The focus becomes refining and updating the product.
With prohibitive ramp up costs, most companies can’t realistically implement their own NLP solution. Most companies don’t have the necessary type and volume of data that they can bring to the table either. For technology that is based on determining intents, it takes a lot of resources to get there.
As if the financial burden wasn’t significant enough, there are technological limitations with the PSTN that make natural language processing technology virtually impossible to implement over a standard telephone connection.
With speech recognition the quality of the audio matters. It really matters. This stands to reason. If you’re taking pictures, the more powerful your camera the better your pictures will be. Having a high resolution camera with high frame rate capabilities, will yield better results than a standard point-and-shoot camera.
The same goes with speech recognition. The bare minimum for satisfactory results is true 16bit, 16kHz audio data, but the better the audio data quality, the better speech recognition will work. To put this into context, professional sound recording, like that done in a studio, is recorded at 24bit, and 96kHz, and CD quality audio is 16bit, 44.1kHz.
The quality of the audio data transmitted through the PSTN, however, is way lower. It is typically 8bit, 8kHz compressed audio. The compression increases the capacity of the PSTN, but doesn’t do speech recognition any favors. Compressed audio loses a ton of data. It also cuts out background noise, which may sound like a benefit. But for speech recognition background noise is important for noise cancellation.
A virtual assistant, like Siri, doesn’t send audio over a network. The device captures the audio locally at a high quality with all the benefits of noise cancellation, too. The audio-to-phoneme process occurs locally on the device as well. It’s just the digital phoneme data, which is 1s and 0s, that are sent back to the server for processing.
The limitations of the PSTN eliminates the feasibility of achieving true transcription on a typical handset. And certainly open-ended transcription is particularly complicated. Many transcription providers will either leave errors in the transcription, like what you may see in your visual voice mail. Others use a hybrid approach whereby machines do the bulk of the transcription and humans just correct the errors.
The ease with which virtual assistants function these days makes natural language processing alluring to all kinds of companies. But understanding the financial implications for developing or incorporating that type of technology is vitally important. Of course, even the deepest pockets won’t be able to overcome the limitations of the PSTN for providing the necessary audio quality for NLP.
Fortunately, all is not lost for those concerned with providing stellar customer service. There are plenty of ways to create great voice applications that use ASR and defined grammars.
Publish Date: March 4, 2016 5:00 AM
There’s a scene in Wayne’s World, soon after Wayne and Garth sign a network contract, when Benjamin approaches Garth, who’s busy working one of his gadgets. Benjamin wants Garth to convince Wayne to change part of the show. With a frightened look on his face, and in a panic-stricken voice Garth responds, “Change? We fear change.”
While this piece of cinematography is a play on a clichéd idea, the fear of change persists. Yet, in call centers around the globe, change marches on. What does this look like? Recent research uncovered a number of trends that are only going to gain momentum in the coming years. Consolidating resources in the cloud, better self-service options, receiving more complex inquiries, greater security/privacy expectations, and the search for cost savings are all at the vanguard of this wave of change.
So let’s look at each one of these facets of change and suss out some ways in which the right technology can help to mitigate or alleviate the negative effects of change altogether.
In 2014, ICMI found that almost 50% of call centers used premises-based infrastructure, and another ~30% employed a combination of on-site and cloud. That’s 80% of call centers that rely on premises-based technology in some capacity.
Migrating to the cloud has many benefits for call centers. Housing communications in a centralized infrastructure helps to streamline many aspects of your call center’s technology. Mix in easy integration with emerging technologies using APIs and the future of the call center has a definite skyward trajectory.
So in addition to more efficient operations and as much future-proofing as is possible in tech, the cloud can save beaucoup bucks. At a time when ICMI found that 62% of companies viewed their call centers as cost centers, this is good news.
It’s true that digital communication channels are encroaching on voice, accounting for 35% of customer interactions, but even so this mean that 65% of interactions still occur over the phone. The rise of other digital communication channels is a very real trend, but integrating those should not come at the expense of the majority.
At the same time there is a strong over-arching trend, and customer preference, toward self-service. Combine the dominant voice channel with self-service and you get an IVR. This approach allows callers to get the information they need quickly and efficiently. Which is precisely why people like self-service so much.
Companies that offer self-help resources through various channels (e.g., web, live chat, social media, etc.) help some customers solve issues. Because self-help options cater to low-complexity issues, people with high-complexity end up using the phone. Having voice automation in place leads to better balance among call center resources. The voice app functions as a self-service option to handle routine and mildly complex issues. Concomitantly, this reduces the total call load on live agents, which enables them to spend more time on the complex issues.
At the same time, all callers spend less time waiting on hold because the automated system handles most of the calls. And those who transfer out of the automated system to talk to an agent can do so with little to no wait time.
One thing that customers value above anything else is their privacy. So while you’re providing a cloud-based, self-service option that balances your call center resources, it also needs to be secure. Industry security compliance standards, like PCI-DSS and SOC2 for finance and HIPAA for healthcare, distinguish the technologies committed to keeping data safe. Customers may not know these standards by name, but they have come to expect the security that they provide.
Let’s backtrack for a moment and return to the cloud to illustrate one more point. Legacy on-premises systems are expensive to maintain in terms of both human and financial capital. Switching to the cloud means your competitors don’t have to either. Many cloud vendors rely on subscriptions, where companies only pay for what they use.
The following example illustrates the savings companies can realize by making the switch from relying on live agents to a cloud-based IVR solution.
We’re not talking about petty cash here. That’s the type of savings that transforms a cost center into a smart investment. As the late Harry Caray (or in the very least Will Ferrell playing Harry Caray on SNL) would say, “holy cow!”
At the end of the day, it’s quite clear that voice communications are not going anywhere. Even as other digital channels encroach on voice the foreseeable future includes telephones and plenty of of them. Therefore, three options emerge: 1. Do nothing and let the competition pass you by as they differentiate through customer service; 2. Keep up with the Joneses; 3. Become one of the Joneses yourself by using IVR to set the standard for great customer service.
Publish Date: February 17, 2016 5:00 AM
When adopting a new piece of technology one of the concerns that anyone involved with the project has is whether the new solution will play nicely with what is already in place. How many potential technology purchases have died on the vine because of the “I” word? Integration.
When we’re talking about automating tasks there is no shortage of possible software to integrate with a communications application. For example, personalizing communication requires integrating with CRM or ERP databases. There may be additional databases or tools that you want to incorporate into your communications, too.
But it’s not always software that has to get along with other software, sometimes hardware is on the table too. When dealing with anything telephony related, figuring out which components communicate with each other can get confusing pretty quickly. (Our back to basics series breaks down the PSTN, VoIP, and SIP trunking, for those who want a quick primer.)
Obviously, if the new technology can’t integrate with what you already have, then there’s little reason to continue considering adopting it.
In The Hitchhiker’s Guide to the Galaxy, there is an alien fish species called a babel fish. One sticks the babel fish in their ear and it enables them to understand anything than anyone says in any language. It’s a universal translator. The role of the Application Program Interface (API) is very similar in that it helps different pieces of technology to communicate with each other.
APIs are basically a set of rules, procedures, protocols, and tools that enable technology to exchange information. Let’s use a database as an example. By codifying how an external source interacts with the database, i.e. which commands are allowed to be executed and which aren’t, the protocol for transferring information, and how that information needs to be structured in order to be used properly ensures that no matter what application is on the other end of the API the correct information will get to the right place.
In the world of cloud computing APIs make the world go round. Many companies that offer software as a service (SaaS) or other cloud-based technology create APIs for their product so that developers can build products and services directly into other applications. This cross-pollination is the reason why so many mobile apps and websites are able to integrate with social media channels.
APIs are ubiquitous. No doubt a quick search for your favorite technology and the term “API” will yield enough results to keep developers employed for quite some time. Even if there isn’t already an API in existence for a desired technology pairing, technology vendors are capable of creating custom APIs to guarantee that what once would not integrate is now capable of doing so.
APIs are not limited to a 1:1 ratio either. For example, if a programming platform uses multiple automatic speech recognition (ASR) engines, it’s possible to create a single API for all of the different ASR engines that allows users to easily switch between engines without having to integrate each one independently. Tapping into the API means access to all of the available engines is just a few key strokes away.
Finding the right technology solution doesn’t have to be a stressful, hair-pulling affair. Because compatibility and integration are so critical a lot of headaches can be eliminated at the outset of a product search by asking what APIs a given piece of technology, like a platform as a service, can accommodate and how willing a vendor is to create custom APIs for new integrations. The answers to these questions should help expedite the selection process.
APIs are one of the best ways to ensure that your technology is making the most of cloud technology. Anything else may just result in a jolting fall back to Earth.
Publish Date: February 10, 2016 5:00 AM
PROGRAMMING COMING SOON!