Plum Voice - ContactCenterWorld.com Blog Page 3
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.
Scale Customer Service without Breaking the Bank
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.
Reduce the Cost of Payment Processing
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.
Take Customer Feedback to Heart
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?
Problem #1: The Cost Center
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.
Problem #2: Getting Locked In
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?
A Better Way
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.
The Case of Rupert’s Insurance
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.
A Winning Strategy
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.
Who Controls Phone Numbers?
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
Finding the Right Number
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.
- Inter-carrier: transfers control of the number from your incumbent carrier to your new carrier. This is the most common type of porting that end-users experience.
- Intra-carrier: This moves a number from one switch on a carrier’s network to a different one.
- Number Pooling: This is when blocks of 1,000 numbers are assigned to a new carrier.
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.
Creating New Numbers
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.
Omni-Channel vs. Multi-Channel
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.
Start with Voice
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.
Expanding with APIs
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.
A Seamless Experience
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.
Why Start with IVR
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.
Sunken Costs vs. Operational Costs
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
Why Data Matters
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:
- What is my average call length? Can I make it shorter?
- How often do callers transfer out of the application? Can I prevent that from happening?
- How often do callers repeat a menu or prompt? Can I make the call-flow easier to understand?
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.
Understanding What You’ve Got
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.
Fixing the Problem
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.
Evaluating the Results
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.
Just Getting Started
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
To Code or Not to Code: A Comparative Guide to Building Voice Applications Using VoiceXML and Drag-and-Drop Technology
Know Your Options
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.
Phase 1: Main Menu
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.
Phase 2: Error Handling
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.
- Silence > “I didn’t hear you” Prompt > Counter > Start (3)
- Invalid Entry > “Your entry was invalid” Prompt > Counter > Start (4)
Phase 3: Sub-Menus
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.
How Traditional ASR Works
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.
How NLP Works
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.
How Much NLP Costs
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.
Limitations of the PSTN
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.
Choosing the Right Solution
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.
1. Embrace the Cloud
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.
2. Self-Help is the Best Help
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.
3. Balance is Key
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.
5. Don’t Break the Bank
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
The Compatibility Quandary
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.
The Babel Fish of Software Integration
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
Right Like a Weatherperson
Seemingly bold predictions are all the rage at this time of the year, as though flipping your calendar to a new month will magically alter trends that started long ago. What does “Year of the PaaS” even mean? What is the year of anything? How do we measure this type of thing? Market penetration? Ok, fine. But how granular does that analysis have to be?
The point here is that it doesn’t matter if 2016 is the right year that other companies adopt new technological solutions. In reality, the “Year of the PaaS” is any year when a company steps forward and decides that it wants to reap the benefits of a PaaS. For that company, that year is the year of the PaaS.
It seems that for several years in a row technologists, analysts, and businessmen alike have predicted that this year is when the Platform as a Service is really going to catch on. Others lament the unrealized potential of the PaaS and openly wonder when it will take its proper place in the cloud computing realm.
Some in the tech world argue that PaaS doesn’t quite pass muster for many businesses yet because of platform lock-in, and the lack of a true platform ecosystem. Are these volleys fair or a generalization?
Don’t Spit and Tell Me It’s Raining
These roadblocks may be real for some platform vendors, but to suggest that, as a rule, they are shared universally misses the mark. The very fact that “as a service” connotes a cloud environment suggests that there is an intrinsic need for flexibility and adaptability.
On the matter of platform lock-in, this may be true of large vendors offering turn-key solutions on their platforms, but what if you don’t need an entire suite of applications, or you require something unique to your organization or industry?
In the world of communications having a locked-in platform doesn’t make much sense because the entire purpose of communications is to, well… communicate with other entities. Hamstringing a platform to only perform particular functions rather than giving developers free-reign to create their own solutions is bad for communications, and therefore bad for business.
The same goes with claims of a deficient ecosystem. What does that even mean? The very nature of a web service means that a platform must be able to interact with a range of other services and applications, such as databases, file storage, security, and messaging.
If we again focus on the world of communications, then the need for interoperability re-emerges in high-relief. The entire idea of making a development platform available in a cloud environment is to more easily facilitate these operations. An attentive vendor will have APIs available to accomplish this goal, or if an API doesn’t already exist then they will work to create one. Suffice it to say that supporting APIs ensures that a PaaS isn’t lacking in the oomph! department.
The Real PaaS Advantage
One doesn’t need a crystal ball or to channel the spirit of Nostradamus to make predictions. All one has to do is look at industry trends and roll with those. A recent study [pdf] by Wikibon claims that PaaS revenue will jump from just under $2B in 2014 to over $68B in 2026, which corresponds to an 11% increase in total public cloud revenues. In other words, PaaS solutions are catching on and their upward trajectory is definitely in positive territory.
As companies look for way to increase efficiency and lower start-up costs a move to the cloud becomes increasingly appealing. Of course, the sooner a company adopts the cloud, the sooner they can start to realize these savings. There’s also the benefit of having a leg up on the competition as well.
Twenty-sixteen doesn’t have to be the year of the PaaS, just make it your year for PaaS.
Publish Date: January 13, 2016 5:00 AM
Studying the New Deal is often an exercise in processing acronyms. More than one university professor has accurately described all the programs created during that period as alphabet soup. Heck, even the president who oversaw the New Deal is referred to by his initials–FDR. Naturally, between the FDIC, WPA, TVA, PWA, AAA, RA, REA, NYA, and CCC, historians lament the fact that acronyms aren’t allowed in Scrabble. At least when your tiles include five vowels and two consonants you’d have some option.
The alphabet soup affliction similarly applies to the world of technology. It seems that everyday a new abbreviation works its way into the lexicon of the digital world. Over the past couple of years there has been a steady growth in different “as a service” offerings. These are basically different types of cloud computing options, the most common of which is Software as a Service, or, more briefly–SaaS.
Most end-users think of “the cloud” as the place where they store their pictures and back up their important files. For businesses though the cloud is how they get things done. This is the place where systems run, applications are built and executed, and all those tasks that end-users just “do” are designed to do just that.
One Pyramid, Hold the Hieroglyphics
There is more to the “aaS” family that SaaS, however. In general terms there are three different components of the cloud computing stack.
Imagine, if you will, a pyramid. We’ll call this the Cloud Computing Stack Pyramid, or the CCSP. Just kidding. We don’t need another abbreviation to deal with. Getting back to the pyramid idea, imagine that there are three different sections where the base of the pyramid is infrastructure (IaaS), the middle represents platform (PaaS), and the top is software (SaaS).
Now let’s work backwards from the top-down to unpack what each of these components are and how they differ.
In a cloud computing environment, SaaS is likely what people are most familiar with. SaaS refers to web applications that reside in the cloud. These can be licensed software like Microsoft’s Office 365, Adobe Creative Cloud, or ArcGIS Online. Not every SaaS option is subscription based, however, and applications like Dropbox and PayPal fall under the broad heading of SaaS, too.
These types of applications allow users to complete tasks over the web without the need to install anything on their local hardware. Because the primary functionality of the software is server-based, SaaS applications lend themselves to sharing and collaboration much more easily than traditional, installed applications. In other words, users access the application through their web browser and not by clicking a desktop icon.
A cloud based platform differs from a service in myriad ways. Whereas a service is a finished product intended for end users, a platform is designed for software developers. This means that all of the tools necessary to build, test, and deploy web-based applications are hosted in the cloud. As stated elsewhere in these pages, a platform is like having a Lego baseplate and a slew of Lego bricks.
In other words, a SaaS is something that is ready to use, while a PaaS provides the environment to build a SaaS. This is especially helpful for projects or companies that have multiple developers collaborating on a project because it enables all parties to work with the same tools and resources. There is no need to manually share various elements of a project because everything is housed in a single, central location that is easily accessible by everyone.
There used to be a much more distinct line between PaaS and IaaS, but that line has blurred in recent years as more PaaS providers begin to manage their own infrastructure. Nevertheless, IaaS is when the actual hardware used to operate a PaaS, the servers, switches, and other physical media necessary exist in a cloud environment. Some of the most notable vendors in this category are already household names because the likes of Google, Amazon Web Services, Rackspace, and VMWare offer IaaS.
The benefit of IaaS is that companies can significantly reduce the cost of operating web services. Many IaaS providers have subscription plans or allow users to pay for the resources they use. Because these items are maintained by a different company the costs associated with maintenance and upgrades are the responsibility of the vendor.
As more PaaS providers include infrastructure as part of their service, vendors exercise greater control over their cloud environment, which allows them to offer more competitive rates, and ensure better responsiveness and scaling for applications built on the platform.
It’s worth pointing out that cloud computing technology is constantly evolving so these “aaS” conceptions are fairly broad, and what’s included under each heading may change. For example, Plum Voice is a good example of the convergence of PaaS and IaaS. We operate three, geographically dispersed data centers in the United States and a fourth in the United Kingdom. Having access to, and control over this much infrastructure enabled Plum to build a secure system that is PCI-DSS, HIPAA, and SOC2 compliant.
The range of tools offered through Plum’s communications platform, therefore making it a CPaaS, is diverse and includes everything necessary to create powerful IVR, messaging, self-service, CEBP, and other applications. In other words, it’s possible to use Plum’s IaaS and PaaS to build a really powerful SaaS. Phew!
Publish Date: January 7, 2016 5:00 AM
Holding your phone at arm’s length and yelling at the top of your lungs at the automated voice on the other end may seem like the type of thing reserved for a TV sitcom or a video about the challenges of speech recognition engines understanding a Scottish accent. Yet, the reason that these images resonate so deeply with a broad cross-section of people is because the bogey man of poor automation is one that is understood through experience.
A Bad Rap
Interactive voice response (IVR) gets a bad rap in large part because of how it was abused in the past. Focusing on the bottom line and not on providing good customer service is a typical culprit in this situation. For many companies their call center doesn’t provide the type of ROI they want to see. In some cases, the goal for a company is to active prevent calls going to their more expensive service channels.
Others may have gone into automation with good intentions, but never put the time into properly fine tune or update their application. This leads to a “set it and forget it” situation where the automated system produces long hold times, a never-ending string of messages assuring callers that their call is important, and phone menus that are so labyrinthine that not even David Bowie would be interested in using it.
Blaming the technology itself is like blaming a golf club for slicing a shot and breaking a window. In reality, the root of the issue lies in user error. After all, an IVR application is only as good as the person who designs it. That’s why putting the extra time into planning and design is key.
It Just Works
And yet… and yet… When a company has a good, well-designed IVR no one ever says, “Wow, that was a great phone system!” It’s just the nature of the beast that the things that “just work” are taken for granted. People don’t associate these applications with IVR because that’s not the lived experience that most people have.
It doesn’t have to be this way. IVR has come a long way since those not-so-halcyon days when it was used almost exclusively as a virtual receptionist. Advances in automatic speech recognition (ASR) makes hands-free navigation of phone menus easier than ever. To use an industry term, ASR may not be at a “five 9s” level of reliability yet, but good engines are at least in the 90th percentile or better when it comes to accuracy. Those times when ASR doesn’t come through though, systems with error-correction built-in still make it easy for callers to complete tasks. At the end of the day, attention to system design is a vital operator.
Therein lies the crux of the thing. The ability to quickly and easily complete tasks on the phone is the hallmark of a good IVR. A truly customer-focused company understands this, and continually optimizes and improves their self-service applications to provide great automation. Just like in Hollywood, filmmakers want their CGI effects to be so realistic that you can’t tell whether they’re real or fake, so too should enterprises make their IVR applications so seamless that a caller never even considers transferring to an agent.
Hold The Applause
Let’s be honest. Given the bad rap that IVR gets the last thing you want to build is a typical IVR. So don’t! Instead, use IVR technology to design, build, and optimize a voice application that caters to the needs of your callers. The fact that an application like this boosts ROI all while providing great customer service, is more than a fringe benefit. It’s justification for extending customer experience principles to self-service systems.
Naturally, your customers would thank you, but with a well designed automated communications app they may not even notice. After all, that’s the goal, right?
None of this is submitted without a dose or realism though. What many don’t realize is how expensive it is to have something that “just works.” There’s a reason that for every Siri or Cortana there are thousands of less sophisticated IVR applications. Apple spent $200M to acquire the technology behind Siri, and the Siri team remains one of the largest at the company. We’re not talking about pocket change here.
Then again, not every company wants or needs a voice application with a personality like Siri. A company like FedEx, which has robust ASR technology in its IVR application, spent millions developing it, and maintaining it isn’t an exercise in frugality either. There remains a need to balance the cost of developing and maintaining that technology with everything else on your plate. Exploring and understanding what it takes to get great ASR is critical if you want to include it in your automation plans.
Publish Date: December 17, 2015 5:00 AM