Today I want to spell out some big challenges ahead for WebRTC specific to the call center space, an area in which I’ve been deeply immersed for the last 5 years. I have followed WebRTC quite closely, written about it, experimented a bit and I am certainly bullish. I definitely see immediate potential in the UC/collaboration space as well as in “person-to-person” OTT communication. But my enthusiasm is much more guarded about one particular application: Using WebRTC to connect call center agents to consumers.
To keep the conversation manageable, let’s just focus on one simple scenario: A consumer connecting to a call center agent for a real-time voice conversation via a WebRTC client that is embedded in a browser. Let’s ignore video, the mobile case and the agent-side of the equation. Essentially, I’m describing a “Skype-like” experience for a caller that allows a smooth transition from a web interaction to a voice interaction, without needing a plug-in. Pretty straightforward, right? Well, not so fast.
Let’s think through all the factors that have to line up in order to have a browser-based WebRTC voice call. The caller needs:
1. The right browser (and version)
2. A headset correctly configured to be the input and output device for the browser (that can be tricky… I stumble on this one sometimes)
3. Sufficient bandwidth for 2-way audio (which means both speed and low latency)
Together, I call these issues “client-side connectivity & readiness”. Now the question is: What’s the connection “success rate” for a given audience? 80%? 90%? The number is definitely going up, but it’s certainly not 100% and it won’t be for a while. As a sanity check, ask yourself, “Of the last 20 Skype calls I’ve had, how many times has someone fumbled with the headset, or had some other glitch?”
(Note that I’m excluding cases like Mayday, where Amazon has unified control over a locked-down environment. That is great situation to be in, but most companies are not Amazon!)
Now, you might argue that the success rate is “close enough” and for many applications I agree, but the call center case is special. To see why, let’s imagine you’re a call center executive deciding on technology investments. Let’s walk through the secondary effects.
Your first priority is to have every customer end their call with positive feelings about your company. That’s often an uphill battle. The customer may already be upset (because the flight was canceled, the package was lost, the service is down, etc.) before the call even begins. Hold times might be long and agents may not have the power to fix the customer’s problem. The last thing you want is connectivity problems on top of that.
Frustrated customers already blame you for things you can’t control (the weather) and things you could theoretically control, but are budget-constrained (hold-times). Imagine the rage-tweet: “Acme kept me on hold for 20 minutes and then the audio was so crackly, I had to hang-up and start over. #worstcompanyever”. In the world of social media, you don’t have a chance to explain that the customer’s poor coffee-shop Wi-Fi signal was not your fault.
Of all the “moving pieces” in a modern contact center environment, the dial-tone is one of the most reliable. There better be good reason if you want to add another major variable to the chain.
As a call center executive, you also have to keep a close eye on metrics, like average handle time. Agent time is your most precious commodity, especially since employment costs are typically 80% of the operating budget. Do you want agents to be troubleshooting WebRTC sessions: “Are you sure your headset is plugged in? Maybe your microphone is muted?” There is a real cost associated with the extra time spent playing the “can you hear me now?” game. You’ll have to include that in the ROI calculation.
[As an aside, I have a lot of experience with a nearly identical concern. Fonolo’s In-Call Rescue solution replaces hold-time with a call-back — a great way to improve customer experience, reduce abandon rates, and deal with spikey call volume. The way it works is, when a call gets through the queue to an agent, a call is placed simultaneously to the customer. As a result, the agent has to wait until the customer answers. Although this is a short time – usually around 10 seconds – it’s still something that we have to measure carefully and include in the analysis. So I know exactly the impact of any extra time at the beginning of a call.]
Lack of Fail-Over Option
When you or I use Skype, Hangouts, or other OTT communication channels in our personal lives, we make allowances for them to have occasional hiccups. We’ve all been on a Skype call where things aren’t going well, so everyone agrees to switch to “land-line”. The fact that we have the good ‘ole PSTN as a fail-over is critical. (We often don’t give enough credit to how incredibly reliable a landline is.)
But, this fail-over trick doesn’t work in a call center situation because most call centers don’t allow direct PSTN access to an agent. In other words, if the WebRTC session isn’t working for some reason, you have to give up and start over by dialing in. There’s no way to connect back to the same agent, maintain your place in line, or keep the context of call. (Yes, it would be possible in theory, but it would take a lot of work.)
But I’m Still Bullish!
These are not insurmountable problems. I want to be clear that I think WebRTC will indeed play a huge part in the contact center of the future. But as someone “in the trenches” everyday with real-world call centers, I see a need for a reality-check on some of the exuberance.