Post navigation

WebRTC and the Call Center: Challenges Ahead

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)

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.

Accountability

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.

Agent Efficiency

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.

4 comments on “WebRTC and the Call Center: Challenges Ahead”

When the customer is requesting to speak to an agent, the portal that is presented to the customer could require the customer to answer 2 questions 1. Does your computer have speakers and a microphone (maybe even a camera) and 2. What browser are you using? (To me that is much less painful than being in IVR hell). If the answer is negative in either case the customer would then enter their preferred device's phone number and that agent would generate a immediate call back to their customer.

There are really 2 categories of issues here. (In hindsight, I would have written the post to make that more clear.) The first is "What percentage of your audience is WebRTC-ready?". This really goes to the economic argument. If that number is too low, can you justify the effort? The second is, of the people who technically *are* WebRTC-ready, what the success rate of connecting them? More specifically, what's the "set-up" time for those calls? Because of that number gets to high, then you also have an economics issue (in terms of wasting agent time).

Having these questions as hurdles to speak with a CSR is unacceptable. The only place I could see it being accepted is in a technical Help Desk. Peddling WTC as an acceptable contact center technology is just as bad as shoving callers through IVR Hell by offering too many prompts leading to too many attempts at self-service apps "just because we can." It's customer abuse via technology overreach.

Thanks for the comment, Kevin. I think WebRTC *will* have a significant impact in the future, provided we tackle the issue like the ones in the post. Hopefully we do a better job, as an industry, rolling out this technology, compared to the others that have come before.