This is the second of a multi-part blog series, explaining some of the many features and functions found in the newly released PowerMedia XMS 3.3 software.
Outbound calling applications – reverse 911, contact center call-backs, medication reminder notifications, and conferencing applications all depend on detecting whether an outbound call was completed, and then, whether it was answered by a person or a machine. Correctly detecting the success (or failure) of an outbound call allows an application to decide whether to retry the call, leave a voice message or connect the call to an agent. Dialogic has been a leader in developing reliable Call Progress Analysis (CPA) algorithms since the early board-level DSP products, carrying this expertise to XMS.
One of the challenges with CPA is the variability of network tones around the globe. If you’ve ever called into Europe or Asia, you know that ring-back, busy and network error tones vary based on the destination of the call. Automatic detection of these country-specific tones is sufficient for some applications, but having control over the algorithm detection parameters and profile can improve reliability and efficiency.
Previous PowerMedia XMS version have supported Call Progress Analysis (CPA) for some time, and XMS 3.3 enhances CPA with several API extensions to give the application developer more control over the process and detection profile.
“Notification and Reverse 911 applications depend on detecting whether an outbound call is answered and whether the call was answered by a person, answering system or received a network error,” said Diane Myers, Senior Research Director, IHS Markit. “The enhanced call progress analysis controls included in XMS 3.3 will be especially useful for developers.”
The newly released PowerMedia XMS 3.3 expands the CPA API controls and is ideal for outbound calling applications that will server a global marketplace. Interested in giving it a try? You can download a FREE trial copy of the software at the PowerMedia XMS Product Landing Page.
Publish Date: May 5, 2017
According to some research from the GSMA, all is not lost with the SMS battle against the IP messaging services. With WhatsApp, Facebook Messenger, and WeChat at about 1 billion monthly active users, it would seem that it’s just a matter of time before SMS becomes extinct. However, according to this report, “SMS retains its lead in markets that were early adopters of unlimited SMS bundles,” which makes sense. Start using it and you get used to it, especially if there are no extra charges.
What does this mean for service providers? I mean, the concept of early adopters in this market is long gone. What’s done is done. And the IP messaging services also offers their own value added services such as video calling and making payments. So, I don’t think IP messaging services would suddenly go away even if all the service providers offered free SMS. In fact, due to the value add offered, they will continue to grow.
But it also doesn’t mean the end of SMS. SMS can be used on non-smartphones (not everyone has a smartphone!), and not everyone is on the same IP messaging service. But everyone can get an SMS. Additionally, we are seeing a resurgence of SMS due to IoT, as SMS can send messages to and from non-smartphone devices. So no, it is not over for SMS anytime soon.
Publish Date: May 2, 2017
Ah, the pain of being called “boring,”, “not innovative,” “commodity,” or “dumb pipe,” and recently being spanked
by the CRTC (Canadian Radio-television and Telecommunications Commission – the equivalent of the FCC in US) for trying to offer a “free data” ride to certain OTT services to differentiate and attract users. Can we say the service providers are struggling? Yup! It has been tough and not a lot of fun.
I will not dwell on what’s apparently obvious or continue to jump on the bandwagon with the rest of the finger pointers. Rather, I want to take you on a fun trip into the future - a future where at least some of service providers will possibly take the spotlight. If massive corporations like IBM and Oracle can continue to “steer the ship” to be relevant and not end up like DEC, Polaroid, and Blockbuster Video, so can global service providers. They will just need to change the way they operate and innovate.
Service providers have an absolutely incredible asset. They have access to millions of customers, but they have lost touch with those users – or perhaps never had it. Have you tried calling Verizon, Bell, Telefonica, or Rogers? If it’s because of a problem, why are we having to call in the first place? Perhaps that could already have been figured out by the service provider and solved automatically so customers never need to attempt a call. Here’s a question for you. Can we please get rid of the old school IVRs that ask you to select your language and give you a set of random numbers to select while you’re hoping to talk to a human? That’s just cruel in this day and age. Sorry, I said I would not poke! Back to the future.
Artificial Intelligence (AI) is starting to touch our daily lives; we have robots that clean our floors, cars that self-park, and an intelligent personal assistant app on our phone that not only answers our questions but also can turns on the lights in our home. What is the next touch point when it comes to how we communicate? Can AI be something we can hope and expect from our communication service providers? Can AI be “connected” to the traditional services like voice and messaging? The answer is yes!
As a consumer, I want you to imagine a future where you have all your communication needs (messaging, voice, and video) assisted by intelligent automated bots that utilize artificial intelligence to turn current dumb IVR systems into exceptional experiences. Can you picture the following scenarios?
All the above scenarios are doable today, and the reasons why these actions are not ubiquitous is not a technology problem. It all has to do with three major roadblocks:
Changing will be somewhat painful. Like as it was for developers moving from waterfall to agile development methodologies, speed and agility will need to be a key component to any new product introduction. Some ideas will fail, some will get adopted, and few will expose new killer apps that will bring amazing new solutions to the users.
The AI market is starting to heat up with the usual suspects including Apple, Amazon, Google, and Microsoft. Few service providers are moving in aggressively (Orange with Djingo) as they are afraid to partner with above “motley crew” but most are still wondering how to approach this fragmented space.
Dialogic is focused on helping service providers break into new applications and solutions quickly with our DialogicOne™ suite of solutions. We work on next generation solutions that bridge the silos and integrate platforms to create innovative applications quickly.
We are experts in telecom with over 30 years of experience as well as architects of next generation applications and services for the service providers globally. We have solutions to address the roadblocks service providers face, and a proven track record working with them to leverage the past and move aggressively into the future.
Next time, we will dive into the absolutely “Wild, Wild West” called the Internet of Things and how service providers can leverage that revolution for their return to the spotlight.
Cheers - here’s to the future!
Publish Date: April 28, 2017
Everywhere in the world, small and big enterprises spend a considerable part of their budget on Antiviruses, Firewalls, and other appliances to protect their network and data. The typical network hacker usually targets the larger enterprises which are potentially a better mark with deeper pockets and lucrative secrets to keep. The PBX hacker though does not care about your enterprise size, because you can be as lucrative as any other company one hundred times bigger than you. When telephony shifted to IP, it brought many advantages, but it also exposed the voice to the same threats as the network. Being able to access your extension and use it outside the office via internet is great for both you and the hacker. It opens a potential door that the older PSTN PBX’s had not. Interestingly enough, most of the time, IT administrators are concerned about the Wi-Fi, router, email, and other services authentication processes but end up neglecting the PBX. Maybe the new mindset hasn’t settled in yet and the PBX is not being given the same importance as the company’s firewall or router as a defense point of the enterprise network.
Not long ago, I witnessed a situation at a small enterprise that got a two hundred thousand US dollar phone bill. The cause was simple: a default password had not been changed on the PBX which was connected to the Internet. This resulted in thousands of calls fraudulently made to exotic locations such as Sierra Leone and Moldavia. With typical network hacking methods, such as Ransomware or others, the victim has the choice to pay the hacker or not. The only consequence of the decision of not paying the hacker will be the data not being recovered. On the other hand, you cannot exactly tell your service provider you are not paying the phone bill because you were hacked…The severity of this issue is not to be ignored and can bring even a decent sized company to its knees. Yes, VoIP brought tremendous advantages but it also introduced several deadly traps. Luckily, protecting the enterprise voice service has evolved and it does not depend exclusively on the IT administrator using complex passwords or firewall rules.
The evolution of Unified Communications (UC) and subsequently Unified Communications as a Service (UCaaS) has hardened the defensive mechanisms of enterprise communications. The fact that the systems can run on a typical COTS server with increased compute power allows running complex defense mechanisms when compared to the ability of old hybrid PBXs. One of these mechanisms involves Machine Learning (ML). The typical voice protection systems are based on rules, which in my view can either be too permissive and still allow some dubious behaviors to occur, or too strict and have the IT administrator waste more time acknowledging false positives and adding certain numbers or routes to the whitelist. When it comes to enterprise voice, one cannot assume that the premise “one size fits all” applies. Each enterprise has different call behaviors. Just because a country is likely to be connected to call fraud, does not mean every single call to that country is fraudulent. This is where ML is extremely effective. It can analyze your typical trends and behaviors and flag only what is unusual. Rules are static and a hacker can get around them simply by testing the waters until he finds the weak spot. ML is dynamic and the alarm threshold changes based on the current call flows when compared with the historical behavior.
When choosing a UC or UCaaS system, do not overlook the type of protection it offers. Chose a system that offers real-time detection and dynamically changes the permissions based on your company’s profile. The previously mentioned small enterprise that got hacked could have benefited from this since an ML-enabled system could have flagged and blocked those calls. If not for the unusual destination, it would definitely have spotted the sheer unusual number of calls. The typical excuse for not getting proper protection for the voice system is that the enterprise is too small and doesn’t need to spend that amount in “just” protecting the voice system. Well, that voice system can be “just” the cause of the enterprise’s demise. So, when it comes to PBX hacking, no victim is too small.
Publish Date: April 25, 2017
Can a Class 4 softswitch really run in the cloud? This was a question I got at Mobile World Congress from a prospect because he was questioning whether a core telecom infrastructure node can actually run in the Cloud / AWS. The answer is yes, for sure - the networks have improved so much, and AWS has been running many mission critical, latency critical apps outside of telecom that a switch can certainly run in AWS. In fact, we have made the Dialogic NGN Softswitch and IMS MGCF (Dialogic ControlSwitch System) run on AWS and have already sold it and deployed it with customers.
The reason someone would want to do this is obvious –a next generation customer would want to be able to transfer IP phone calls to the PSTN, but would need to do it via AWS because their entire infrastructure is already on AWS. The public cloud infrastructure offers enhancement of service agility (i.e. scaling up and down) and also offers transfer of CAPEX to OPEX, which fits their business model better.
For Dialogic, it wasn’t that difficult to move the Dialogic ControlSwitch System to run in the Amazon Cloud. The ControlSwitch already ran on COTS servers, and has a unique modular architecture that decomposes functionality into discrete building blocks / Virtual Machines (VMs). The underlying cloud computing infrastructure is used only when it is needed, for example, when processing a call request. The ControlSwitch System draws the necessary resources on-demand (like compute servers or storage), perform a specific job, then relinquishes the resources after the job is done. The ControlSwitch can then elastically scale resources based on traffic load and service demand and can execute the off net call to the satisfaction of the voice subscribers.
In other words, yes, a Class 4 softswitch can run in a cloud. If you want to read more, please read this whitepaper.
Publish Date: April 25, 2017
Mobile World Congress, for me, has always been a combination of looking forward towards our future while at the same time reflecting on the massive changes I’ve seen in this industry. I mean, years ago, who would have thought that Microsoft today would be both a large service provider and an enterprise PBX behemoth via Skype for Business / Lync? (And I remember when Microsoft insisted Lync or whatever they called it back then was NOT a PBX.) More recently we’ve seen Facebook and Amazon respectively become huge movers and shakers. I saw it all in full force at MWC.
Facebook has always used MWC to drive its agenda. These days, Facebook is driving the Telecom Infra Project (TIP) that, according to the TIP Website, is “an engineering-focus initiative driven by operators, infrastructure providers, system integrators, and other technology companies that aim to reimagine the traditional approach to building and deploying telecom network infrastructure.” I bet half of those working on the project see opportunities while the other half are scared. Either way, it’s likely that Facebook will succeed in driving some software-based telecom infrastructure that is likely to have a large open source component.
Regarding Amazon, the whole telecom world wants to run their apps and/or infrastructure on Amazon ECs. I recently watched an Andy Jassy (CEO of Amazon Web Services) keynote from the Amazon reInvent conference in November and noticed that it’s a $13B revenue run rate business with 55% YoY growth. That kind of growth from that size of a company! Wow! If you didn’t think cloud computing was important, or didn’t think the move from customer premise equipment to the cloud was a trend, think again! And while Amazon Web Services had no presence at Mobile World Congress, their cloud was floating around everywhere, with many telecom services running on it.
Telecom is alive.
Publish Date: March 28, 2017
Remember as a kid your TV show or radio broadcast being interrupted by an announcement, “this test of the Emergency Broadcast System,” followed by the squeal of a test tone? Reverse 911 has essentially made that old system obsolete – what is Reverse 911 and how does it work?
When I was a kid, I lived down the street from the volunteer firehall. If there was a house fire, car accident, or medical emergency, the fire company would summon the volunteers with loud siren mounted on the roof of the firehall. Once the firefighters arrived, they would hop on the side of the truck and roar off to the emergency. Eventually the ear-splitting siren gave way to the digital pager, giving a precise address to the firefighters in an instant, allowing them to drive their own cars directly to the emergency, saving valuable time.
Communicating to the wider community about fires, floods, rising water, or other natural disasters has always been a vexing problem. Sirens and the Emergency Broadcast System were a byproduct of the nuclear threat of the 1960’s and fortunately was rarely (if ever) used in most communities.
With television and radio listening habits changing, the advent of on-demand services and the invention of the mobile phone – community emergency response services needed a better way to communicate quickly and concisely to the citizenry within select geographic bounds. Since most every household has at least one telephone, it seems natural that calling those houses in the affected area with a voice message would be a good idea. The idea for Reverse 911 was born.
To create a Reverse 911 system that can call many households in a community, you need a few things:
1. The ability to make outbound automated telephone calls.
2. The ability to know if a person answered the call, an answering machine answered the call, or if there was no answer.
3. Allow the recipients to use DTMF responses to acknowledge.
4. To detect network error tones, including Busy, All Circuits Busy, and Out of Service tones.
5. The ability to record and playback a voice message.
6. The ability to scale massively, allowing thousands of households to receive the recorded message in a relatively short period.
7. A database of every household, their address, and phone number.
Any combination of media gateways or session border controllers and SIP trunks can provide the connectivity to the PSTN and initiate outbound telephone calls under the direction of an application server. The difficult parts are items 2-5, being able to accurately detect whether the person being called answered or not, and properly detecting responses and network errors. This capability is Call Progress Analysis (CPA), and in a SIP architecture, is accomplished by a media server.
To initiate an outbound call, an application instructs the gateway or SBC to dial the telephone number of the intended recipient and requests that the media (audio) during the calling process to be sent to a media server session. The media server uses the CPA algorithms to “listen” to the ringback tones, busy signal, network error tones, or for a human voice to answer. If a human voice is detected, a decision is made as to whether it was a simple “hello” or a longer greeting that ends with a beep tone, suggesting that an answering system picked up the call. The result of all this analysis is sent to the Reverse 911 application, allowing the application to play the prerecorded announcement or a message on the answering system. By having a high confidence on the result of the CPA, the Reverse 911 application can deliver the important message, waiting for the recipient to answer or the beep of an answering system. Without CPA, the application would likely not wait for the answer, leaving only half a message or must repeat the message multiple times, wasting resources and slowing the delivery of critical messages.
The Dialogic PowerMedia XMS media server software is ideally suited for this application as it includes advanced CPA algorithms. With over 20 years of improvement, the Dialogic CPA algorithms have been tuned and tested over millions of test telephone calls both domestically and around the globe. Accurate and quality CPA algorithms improve the efficiency of Reverse 911 applications, reduce network usage and more accurately inform the community about potentially harmful emergencies.
(And most importantly, we don’t have to suffer though the Emergency Broadcasting test tones any longer.)
Publish Date: March 16, 2017
Robo-Calls are rightly getting negative press and regulation. But Call Progress Analysis (CPA) has many legitimate uses beyond enabling Robo-Calls. Dialogic has been getting quite a few questions lately about software based CPA because of the legitimate uses as discussed last week.
CPA was first enabled via sophisticated algorithms that first started being employed via DSPs. But as hardware such as call processing boards have morphed into software modules, the CPA algorithms might not be quite the same.Host processing, say using Intel CPUs, may not be as powerful. And porting algorithms from DSPs to software may not yield the same functional performance. As such, some software CPA clearly may not behave the same as CPA deployed via DSPs.
We know this since we’ve been through this. Dialogic has been shipping software based media servers since the early 2000’s. We were the first to do this as part of Intel. As we ported many DSP functions to our HMP product, we saw small variances in many functional areas. And we worked hard to correct the behavior in all areas (not just CPA) so it worked as much as possible the exact same as a DSP-based board system. And note that just because an API is the same doesn’t mean a function will behave the same!
As I said above, Dialogic has been getting questions about CPA lately. Take a look at our PowerMedia product line if you are interested in using the premier software based media server.
Publish Date: March 14, 2017
Robo-calls are making the news lately. I even wrote a blog about them last year. We all hate getting those calls. While most contact centers follow the rules, there are companies that don’t and they are the ones that cause consumer frustration. But just because Robo-calls are bad, it doesn’t mean that the technology that allows those kinds of calls are bad. Call Progress Analysis (CPA) is one of those technologies, and CPA is but one of many technologies that enable the bad apple Robo-Calls to happen.
CPA is what enables the robo-call, as it rips through its many calls, to try and find a live person to talk to. The calling system uses CPA to see if a call is ringing, if the line is busy, or if a call is answered, and then to figure out if it’s an answering machine, fax machine, or a live person. In other words, analysis of the progress of the call, hence the term Call Progress Analysis. And the calling system does this by trying to figure out the background noise, overall energy of the answer, etc. The overall outbound calling system then uses this information to figure out when to put a live agent on the phone.
There are very legitimate uses for CPA and the outbound dialing systems that utilize them. For instance, you may have chosen to be contacted by mobile phone call by your airline. If say, the airplane is delayed, then the airline would need to contact everyone. Some may choose email, some may choose text, some may choose a voice call. If say 70 people chose voice call, then the airline can put this into their outbound system and have it call everyone. If someone answered, then they can choose to talk to the person with a live agent (maybe if they are a high status flier), or they may choose to play an announcement about the flight. I’m sure you can think of many other examples like this.
Next week I will discuss the impact of CPA moving to software based call systems.
Publish Date: March 7, 2017
Whether it’s one bad connection degrading the quality of the entire conference, or problems with the underlying media server or conference call architecture, a poor conferencing experience is avoidable. For large scale video conferences, the Selective Forwarding Unit (SFU) architecture may be a good way to go.
SFU is a topology allowing for clients to send their encoded video stream to the centralized media server where it is then forwarded/routed to the other clients. The SFU topology is an attractive approach to addressing the server performance issue, as it doesn’t involve the compute expense of video decoding and encoding. Additionally, without encoding/decoding, the latency of the added SFU media server is minimal. Lastly, the clients with full correspondence with the SFU media server have complete control over the streams it receives, and because the client is receiving the streams it wants, it can have full control over the user interface flexibility.
While the SFU topology has become a popular choice among WebRTC communities, perhaps the most common overlooked shortcoming of SFU topology is the default to using the ‘least common codec’. This means every participant in the conference needs to use the same codec. For those multiparty conferences where all participants are using PC/laptops, the issue is negligible but introducing a mobile device that is hardware optimized for H.264 acceleration would be better suited using a different codec. The inability to transcode video streams can limit the type of clients that can be connected together.
Additionally, traditional SIP based platforms cannot handle the multiple streams produced by the SFU. For this reason, without a gateway function in the middle, the SFU topologies are restricted to WebRTC only.
However, since each architecture has its pros and cons, an architecture enabling both topologies could be better, depending on your application. I’ll talk more about the pros and cons of a hybrid architecture next week. Stay tuned.
Publish Date: January 24, 2017
Over the summer, I wrote about how Internet of Things will sometimes need to merge with Real Time Communications. Dialogic even created an infographic on this concept. Let me explain more since I’ve had a few questions come in since then.
IoT in its simplest form is basically sensors sending data. That in and of itself is not that interesting. What is interesting is that some kind of analysis gets done on the data, and if something is akilter then an alert is triggered. In many cases, this alert will go to another machine (M2M!) and that machine will do something. For instance, if there is a system to measure soil humidity, and the soil humidity gets below a certain set threshold, then a sprinkler system could be turned on.
In other cases, the alert will go to a human. For instance, if water pressure is measured to be low in a pipe in a city system, then a human will be dispatched to look where the pressure is low and where presumably a leak is. And the pipe can be fixed. Or if a beer keg in a bar measures low beer, a text message can go to the beer provider so another keg can be dispatched to the bar in time before disaster strikes! Phew.
As we get further into when an alert will go to a human, in some of these cases, real-time communications will need to occur. As I wrote in my summer blog, there may be a case of a car crash and then the car can go into a mode to talk to the driver. This conversation can be overheard by a human who could then send help if required. I’m sure you as a reader can think of other examples of this. For instance, let’s say some emergency is happening (the IoT devices figured that out because of various anomolies in their standard readings), then a conference call to the proper authorities can be kicked off by the IoT system, replete with video of the emergency. Or maybe closer to home, if someone is ringing your doorbell, then a live video feed can go to your smartphone so you can see if you want to actually get up and go to the door. There have also been many healthcare examples written about where voice and/or video would be required.
Dialogic has been doing real-time communications since it’s inception almost 35 years ago. We have both the underlying technology to help you create a cloud-based RTC IoT application, or we can even create a customer application for you.
Publish Date: January 10, 2017
Skype for Business, Google Hangouts, various other so-called Over the Top providers, AT&T, Sprint, T-Mobile, Verizon - they all offer VoWiFi. And it is expected that VoWiFi minutes are going to surpass VoLTE by 2019. So if you are a provider of value-added services to the mobile providers, VoWiFi support needs to become part of your offering.
There are many implications and technical hurdles to overcome to make this happen. And I have written multiple times about this in 2016. One implication I have not written about yet is the impact on Value-Added Services. Let’s take a basic Value-Added Service like voicemail as an example. If you are a voicemail provider, you’ll need to make sure your voicemail system handles the proper HD voice codecs used in VoWiFi voicemail. And if you want to offer VoWiFi voicemail, you likely need to upgrade your system to handle this.
Conferencing is another example. Yes, codecs will be important there too, but a conference call with a VoWiFi client may cause issues for everyone on the call because of potentially poor performance and bandwidth. So a “smart” way via analytics to handle a poor subscriber may be necessary.
Ultimately though, VoWiFi will likely also offer value-added services above and beyond the traditional ones I’ve written about above. We all use WiFi, and we all use video when using WiFi (just look around the next time you are hanging out in a Starbucks or similar place). So it’s likely video will be involved in future WiFi Value-Added Services. When a video call is involved, video calling via a mix of a MCU and SFU (more on that in a couple weeks!) architecture may be the best approach.
We also all use social media apps. It is likely voice will be part of (not central to) these social media apps – giving users a choice to call.
These apps will also most likely be offered in the cloud, or as part of an overall NFV solution. Utilizing a modern software based media server to provide the underlying codec support, call functions, and scalability will be essential. Dialogic is happy to help.
Publish Date: January 4, 2017
With IVRs, many of us understand that when we make a call, we may not even actually talk to a person. We may be talking to a computer. And we totally accept it. The computer voice will be the onramp to some database and find us the answer. And if we really, really need to talk to an actual living person, we can do so.
But when you’re on the web looking for the customer service support number, you may get into a chat, or get offered to get into a chat. When you do, you may be chatting to an IVR-like chat machine who would get to an agent for more complicated matters.
And Visual IVRs enhance the IVR experience, especially for those using smartphones. Unlike traditional IVR, Visual IVR displays a full set of menu options on a device’s screen. It allows callers to quickly choose the path that is right for them.
Video has also entered the contact center. Depending on your vertical industry, such as insurance, video can play an important role in a conversation. For example, when making a claim during a car accident, you can allow the insurance company to “see what you see” simply by recording a live video of the accident.
Integration of chat, even WhatsApp, into contact centers, is the next phase. And like I said last week, clearly integration of IoT apps into the contact center is even a “nexter” phase. Probably in the distant future, companies will incorporate virtual reality into their contact centers.
Enterprise contact centers continue to evolve, driven by the need to both reduce expenses and enhance customer service. What we once thought strange, such as not talking to a live person has morphed into a plethora of communication options, which will continue to evolve.
Publish Date: December 27, 2016
Last week, I talked about the different contact center channels. I mentioned that airline contact centers do a good job of keeping up with customers’ demands and expectations of communication.
Many of us travel quite frequently so just looking at how an airline operates is a great example of a modern contact center. Right now as I write this, I am in the middle of an intercontinental trip. I asked for an upgrade via use of a “coupon.” I was informed multiple times via email (my preferred communication method as per my signup) where I stood with this. Ultimately, I did not get one, but the communications to me were fairly frequent. My boarding passes appeared on my smartphone and also in my email inbox. And since I had a connecting flight, I opted in to find out how this part of the trip was going, and so I was kept up to date with text messages.
The proactiveness of this whole experience was very good. I’m sure it also kept expenses down for the airline since less agents were needed to handle phone calls (which is how we used to do things – and I’m sure some of you probably remember the banks and banks and more banks of phones at airports). I’m sure we’ll see even more proactiveness in the future. IoT may even play a role. Dean Bubley was the first person who brought up that IoT can help you and airlines track your checked luggage. Hopefully, your luggage is not in New York if you are going to Los Angeles, but at least you’d know where it is.
Publish Date: December 20, 2016
The contact center has always been technically innovative. The quest to both improve customer service while reducing expenses at the same time, while potentially oxymoronic, gets pulled off in this space because of technical innovation. In fact, the contact center used to be called a call center, because, well, the only way to contact one, or to have one contact you, was to place a phone call. Contact centers were one of the first industries to really embrace IP communications because of this very reason. Today, with the advent of push to talk, email, texting, and specific smartphone apps, there are multiple contact points. Let’s take a look at the different contact center channels.
Phone Call – Sometimes it’s easiest to just call in to a contact center and explain the situation verbally than to type it out in text/email/chat/etc. But before you talk to a live person, you’ll likely run into their IVR system to route you to the right department or to try to solve your problem without getting to a live person. This classic way of getting in touch with a contact center is modernizing, however, to keep pace with customer demand and expectations, especially if you’re on a smartphone.
Live Chat – The number of customers using live chat support has doubled in the last two years from 14% to 28%, according to this infographic. I can understand why this is a popular option for customers and contact centers. It allows customers almost immediate access to an agent and it allows each agent to handle multiple customers at once, making the contact center more efficient.
Email – Email is less immediate and isn’t the fastest platform for a conversation, but there are many benefits to email. It’s heavily automated, it’s 24x7, it’s easy to attach images/videos to demonstrate what’s happening to a service or product, and there’s clear, lasting paper trail.
Text – Contact centers strive to be efficient and keep costs down without compromising customer satisfaction. So automated, proactive communication and workflow makes sense. Text messages are a great channel for automated, proactive communication and workflow. I’m also seeing it used quite a bit for security from the perspective of texting a code if you are communicating from an unknown device, or have deleted your cookies.
Social Media – Social media isn’t a part of a contact center per se, but a lot of people do turn to social media for customer support. Consequently, some companies have made a separate customer support social media account. It’s also the most visible of channels so it lets angry customers voice their complaints publicly and it allows the company to let the customer (and the public) know that the issues have been heard. The actual problem solving, however, happens privately in DMs or the customer is directed to a contact center.
Mobile Apps/ Video Chat – Mobile apps have also made it easier for customers to interact with companies. Some apps support video chat, which helps the issue get resolved quicker. Customers can show, not tell, what’s going on with the product or service.
All of these channels have to be integrated into one seamless customer experience. One exemplary industry that I think does a good job of incorporating all of the different contact center touch points is the airline industry. Next week, I’ll explain how they do that.
Publish Date: December 13, 2016