Jan 292014

WebRTC – Ski Lifts for Contact Centers

Minimizing costs is the most important goal of most contact centers. Talking with a few contact center executives, their bull’s eye is on minimizing the amount of time an agent used to get prepared to help a user. If helping the user is skiing down the mountain, then, today, the agent (and the user) are slowly and painfully hiking up the other side first. WebRTC is then a high-speed chairlift, enabling the user and agent to use their time skiing down the mountain, rather than struggling to get to the top of the mountain. A ski lift that saves the contact center, and the businesses that it serves, a lot of money (agent time).

A Tale of Two Calls


The example above shows a user initiating two sessions to a WebRTC-enabled contact center (calls 1 and 2 in blue), and another user initiating two phone calls to a call center (calls 1 and 2 in red). Note the relative time length of the red sessions (the out of band phone calls to the contact center) – this out of band model causes the user and agent to hike up the mountain before they can ski down it (address the user’s problem).

Step 1a – the user seeks help from a contact center:

  • In the two contextual sessions, 1a is a short and productive step – like getting on to a ski chairlift. The user navigates the contact center’s WebRTC-enabled application (web-based or a native mobile app) to try to solve her problem. The user is in control and can easily find the information she seeks.
  • In the out-of-band calls to the contact center, the IVR is in charge of step 1a. The user is at the mercy of IVR trees and wastes valuable time.

    And this graph assumes a very good (and expensive) IVR with excellent CTI to pass information, and therefore eventually gets the user to the same level of value as 1a of the contextual session, but with longer time and higher costs.

    Unfortunately, that is the best case scenario! In other cases, the out of band step 1a will be very long and expensive, yet still not generate any value – a long hike most of the way up the mountain, only to tumble back down before reaching the top. How many times have you wasted minutes of your life in queues and IVR trees, only to be connected to an agent that then starts you back at square one, at the bottom of the mountain? Note also that if the user first tried to do self-help on a website or app, then the information (and value) from that session is not connected to his phone call.

Step 1b – the user connects with a contact center agent:

  • In the WebRTC-enabled contextual sessions, the user chooses when to add the agent to the session. Critically, this is not a new session, it is an extension of the session started in step 1a. This extended session, contextual communications paradigm means that the WebRTC application has already taken care of identification and authentication during the self-help stage (1a). It means the WebRTC app has also already initiated a session (behind the scenes) with the contact center, including adding information from relevant systems and databases (based on your credentials) to the session. So, when you choose to hit the contact button, the sessions are linked such that the contact center agent already has all the contextual information, including all the information learned during your WebRTC app self-help stage (1a) such as the key information from your clicks, swipes and touches in the WebRTC app. This not only means that the agent is able to help you from an excellent starting point, but also that the agent himself can be selected to be the one that best matches you, your information and the actions you took on the app. A linked, continuous, contextual sessions is your high-speed ski lift to the top of the mountain.
  • In the out-of-band call, 1b starts when the agent answers the call. In most cases, the agent will then need to use more time to do further identification and authentication. After the agent has spent this precious time, he next needs to slowly query one or more systems that house your data: find out what products or services you use, check out your history, grab your financial information and view your call history (remember, that was all done behind the scenes during 1a for the contextual session). You are at the top of the mountain, yet you still can’t quite ski. If you are fortunate, that agent will solve your problem.

However, we all know from experience that it is not uncommon to be thrown back into a queue to be transferred to another agent. In the out-of-band model, you are still hiking up the mountain for much of 1b. Helped by an agent, but still hiking.

In sum, this is why you see in the graph above that the red 1a and 1b takes so much longer and costs the contact center so much more money (agent time) than in the blue 1a and 1b.

Step 1c – the contact center session is terminated:

  • In the contextual session, most of the information is retained. The information gathered is therefore also valuable to future sessions. This could include a transcription of the session, possibly enabled for quick keyword-based search that also enables the contact center to efficiently watch relevant sections of the video or listen to select part of the audio.
  • In the out of band session, when you hang up, most of the past 30-minutes of your life are wiped out. The fact that the call took place will be logged and maybe the agent will enter some notes. If there is an audio recording then it will be an independent artifact – not correlated or connected with the rest of the session. Any information that could have been derived from your self-help session is effectively gone (perhaps “retained” in some web server logs; not connected or correlated in any way with your phone call).

Steps 2a – 2c – another session from the same user, but one with a head start

The subsequent sessions shown in the graph above – steps 2a – 2c – mainly mirror the first sessions. The key difference is that the contextual session builds on the information gathered in the first contextual session – notice where the blue 2a starts, compared to where the red 2a starts.

This means the second contextual communications session can be even more effective and quick than the first session. On the other hand, for the out-of-band session, if you call again in five minutes, then you will be back at square one, back hiking up the mountain via IVR prompts and back struggling through music-on-hold ice patches, and an agent will eventually be wasting time again (costing the contact center money), also starting from square one. So, not only does the WebRTC call center save time and costs on each call, they save even more time on subsequent calls (from the same users).

Other cost savings?

The example and graph above focused on the agent costs and time that contact center executives feel is the most important and viable to minimize. There are of course many other costs that can be saved by WebRTC call centers, especially once sessions become end-to-end VoIP and video over IP. These costs include PSTN costs (including toll-free), PBX costs, CTI costs and agent endpoint costs (replace expensive desk phones with software on agent computers, tablets and mobiles). It also makes it easier and cheaper to distribute call centers (including to homes), leverage cloud-based services and easier to make changes (compare making web site changes to making IVR, ACD and PBX changes).

Can WebRTC also help the revenue side of contact centers?

WebRTC call centers can also add value (revenue), especially to relationship-driven call centers. To simplify, let’s consider two types of contact centers (and some of course are really in the middle):

  • Cost-driven contact centers. These contact centers deal with calls about transactions that are relatively low-value, low-interaction and low repeat sale oriented. The performance of these contact centers is not perceived as moving the needle on the revenue side of the house. The CFO has this contact center on the top of her list, but the sales and product VPs barely know it exists.
  • Relationship-driven contact centers. These contact centers seek to maximize customer satisfaction. They are focused on relationship management, support, sales and marketing of high-value, high-touch, repeat-business, long-term relationship focused products. Sales and product VPs work hard to get budget allocated to improving these contact centers because these centers generate revenue.

I will discuss the potential revenue-side benefits (especially to relationship-driven contact centers) in more detail in other posts, but the overall drivers are that WebRTC enables the contextual communications sessions described above (which can add value, in addition to decreasing costs), and can add revenue driving functionality such as screen sharing, persistent chat and video. Meanwhile, one quick example below.

Adding faces to contact centers

As a quick example of the revenue benefits of WebRTC, how much better would it be if you could choose your favorite contact center agent, similar to how you might walk into a store and choose your favorite clerk or salesperson? In some cases, you could schedule the session to make sure you get the contact center agent that you like to work with – similar to how you might choose a specific doctor, mechanic or hairdresser. WebRTC can help humanize and personalize relationship-driven call centers. How does that help revenue? We buy more when we are comfortable and we are less inclined to move our business if we have strong relationships.

Contact center agents don’t need to be presented as faceless, interchangeable commodity parts. This won’t make sense for all contact centers – specifically some of the cost-driven contact centers – but WebRTC can help enable our relationship-driven contact centers to show us brief profile and videos of each available agent, and let us initiate a video session with our agent of choice, and then let us choose that agent for future sessions if our experience is good, even scheduling the interaction ahead of time.

Contact center conclusions

There are many verticals and domains that WebRTC could help. I think contact centers are one of the strongest, partially because they have a cost-side business case. Business cases based on cost savings tend to move quicker than cases that are only based on the revenue side, especially in the communications industry. Meanwhile, there is tremendous revenue potential around WebRTC-enabled contextual communications sessions as well.

Of course, it is not *just* WebRTC. The combination of pervasive retail Internet access, mobile and tablet proliferation, cloud-based applications and data analysis and correlation are the building. But WebRTC is the door that will enable many contact centers to walk in. And enable many of us to take the high speed quad chairlift up the contact center mountain.

Net Neutrality in 2014

 Posted by on January 15, 2014 at 22:49  internet  No Responses »
Jan 152014

I am a Net Neutrality advocate, meaning I agree with the precepts and objectives of Net Neutrality. However, I don’t agree that regulation is the answer.

Let’s start with three basic questions. In the US:

  • Is the Internet a flat playing field?
  • Do we have world leading Internet services?
  • Do we have pervasive broadband service availability?

No, no and no (if you believe we have a flat playing field Internet then read up on CDNs, QoS including DSCP, CoS and MPLS schemes, ISP peering and ISP transit agreements).

Yet, we have had Net Neutrality on the books since late 2010 and in practice it has essentially always been there. So why hasn’t NN resulted in those three desired outcomes?

Because the most important root cause preventing those three outcomes is the ISP monopolies and duopolies that dominate most US areas. And Net Neutrality does nothing to address that root cause. FCC governed NN is a band-aid, at best. A band-aid on a geyser.

We need to focus our efforts on opening up free market ISP competition, rather than tacking on more regulatory band-aids. Examples of where we need to focus our efforts:

  • Solutions to make better use of white space and available spectrum such as software defined radios
  • Improvements to wireless solutions and protocols and development of new ones – especially ones that can be extended to cost effectively cover larger regions.
  • Continued development of P2P solutions and related protocols (helps indirectly)
  • Taking back spectrum from entities that are not fully using the spectrum and opening it up
  • Continued development of software based routers and switches (lowers barrier to entry for new ISPs and enables more ISP innovation)
  • Eliminating regulation designed to extend the monopolies and duopolies (for example, the regulation that ISPs are sponsoring to limit competition from municipal providers)
  • Innovation in areas like WebRTC that can help distribute, diversify and grow real-time communications – which would make it less prone to ISP interference.

An argument could be made that we should do all of the above and we should fight for FCC governed Net Neutrality. But to make that argument you need to:

  • Believe the ISPs are capable of profitably doing (bad things) if they aren’t governed by Net Neutrality regulations
  • If you believe the ISPs are capable, then you also need to believe that regulation would effectively prevent those ISPs from finding ways to do those bad things in other ways.
  • If you believe both of the above, then you also need to believe it for the long-term. That the state of the Internet will remain close to what it is today, and that FCC regulation will remain a good deterrent to bad ISP behavior.

Looking quickly at all three of those:

The ISPs are not capable
Some ISPs can execute some one-off NN offenses. Block a certain site or protocol. Maybe even slow some traffic down or prioritize their own content. But not at scale and not over an extended time period. Think about it:

  • Why can’t you buy a premium service today from your ISP that guarantees you no packet loss for real-time communications services, zero buffering gaps for streaming video and five nines of uptime for your connection? Correct, the ISPs can’t effectively build, sell, deliver and operate that service…yet we think the ISPs can do it for Netflix if the FCC doesn’t block them? I have worked in VoIP service provider environments for the past 15 years…it is quite a leap to think the ISPs can deliver this type of service; in fact many would argue that it is near impossible with today’s protocols and Internet architecture
  • Which content, app or service providers would actually pay the ISPs for preferential treatment, even if we assume the ISPs could cost effectively offer such a service? Are the ISPs going to invest heavily in the technology and operations involved and then hope they can sell it? Are the app providers going to buy the story, without seeing it actually work? We would have a serious chicken and egg problem here. And, even if ISPs go build it, there is still no guarantee that anyone buys it, even if it does somehow work
  • Finally, the classic oversimplification of “pipes” is harmful in that it creates some fears that are mainly unfounded. Throttling Netflix traffic does not necessarily improve the performance of your connection or application performance. Improving Netflix traffic performance does not necessarily degrade the performance of your connection or app. Most Internet issues are transient, a function of factors that the last mile ISP doesn’t control or due to last mile ISP variables that are not directly related to pure load.

If the ISPs are capable then would FCC enforced Net Neutrality be a successful defense?
Maybe I am wrong. Perhaps the ISPs can effectively and efficiently execute source-based or stream-based type service schemes. However, if they can do that, then would the FCC really be able to block it?

Long-term, there is very little chance of FCC regulation being the best answer.
There would be unintended negative consequences. There would be waste. Look no further than the PSTN and the Universal Service Fund if want examples. Also don’t disregard the long-term with the thought that we can change off of FCC regulation later. Once the FCC is in, it will be hard and costly to get them out, even when the world changes and they are no longer wanted. Again, look at the PSTN situation. And keep in mind all of this only applies to wired ISPs…when the more important discussion is really the mobile providers…

This has been my position for years – see previous Net Neutrality posts). That actually makes me a bit nervous – there has been enough change that I feel that view may no longer be as valid. But if I quickly think through the arguments then I always come back to the above. In fact, maybe ironically, I think the second best “solution” might be somewhat the opposite – a legal mandate for US ISPs to connect every household with top tier quality – even if that meant some FCC oversight, though of course done in a way to foster free market competition (which means this probably will never happen as it would be very difficult given the players and dollars involved). But I don’t like any of the middle ground type solutions, and I think the current FCC version of Net Neutrality is exactly that, so I prefer to focus our efforts on the root cause, the monopolies and duopolies, and the innovation that can help change that. What do you think?

largest WebRTC deployments

 Posted by on January 3, 2014 at 18:15  WebRTC  No Responses »
Jan 032014

The second most common type of WebRTC question that I get is size. Who has the largest deployments, which use cases have scale, which will be the largest.

Amazon Mayday and Google Helpouts may seem very different. But they are the same. Contextual video. Monetized contextual video. And at scale…two very likely answers to the question of future largest WebRTC deployments.

They are also similar in that neither currently uses WebRTC. However, it is only a matter of time before Google Helpouts goes WebRTC (Helpouts is based on Hangouts and Hangouts almost certainly goes WebRTC in 2014).

Meanwhile, if Mayday is successful then Amazon could use WebRTC to expand Mayday to browsers and other tablets. Amazon could instead elect to reserve Mayday as a Kindle sales tool, but my gut is they would enable Mayday everywhere, while using the Kindles to enable new and special Mayday features. Larry Dignan also makes some great points here on how Amazon can expand Mayday use within its ecosystem

Does that make Google and Amazon into communications service providers? Of course it does. Think about that…

Oh, and what is the most common WebRTC question? Where is the money? And actually Amazon and Google are decent places to look for possible answers to that question as well.

strep throat treatment

 Posted by on December 30, 2013 at 11:28  healthcare and medicine  No Responses »
Dec 302013

I rarely get sick (maybe five total missed work days in the past 15 years).  But when I do, it is almost always strep throat. Well, I got strep again this year, a few days ago.

This time I decided to avoid the antibiotics (I have used amoxicillin and various penicillin variants in the past).  Not because the antibiotics didn’t “work” in the past – they seemed to – or at least the worst part of the symptoms would subside in about 48 hours.  But because I had three main questions swirling in my mind:

1.  If I let my immune system attack the strep “naturally”, will I be more equipped to not get strep next time (as opposed to my history of getting it every few years)?

2. Are antibiotics “good” for my long-term health, immune system fortitude and susceptibility to “superbugs”?

3.  In previous years, how much did the antibiotics really help – did they kill the bug or at least accelerate the recovery process?  Are antibiotics the best choice to fight strep throat?

After some Google research, raw honey, apple cider vinegar and vitamin C (from fruits) were the main alternative treatments that seemed to be the most credible.  So I tried it (all three).  The result?  About the same as the antibiotic route, at least judging by the symptoms.  Fever/chills have subsided.  Throat pain is there but less severe.  Only time (years) will tell if this route helped my immune system build its own strep prevention.  I will also try this treatment combination more proactively – e.g. consistently ingesting some amount of all three.

I am sharing this because I believe case studies are important and there are not enough of them in the public domain.  I would much rather see comprehensive medical records shared to be continually statistically analyzed (including correlations with specific genotypes and other factors), and hopefully one day case studies will simply be data points combined with all that other data to form more conclusive information.


  • I strongly believe everybody and every situation is different.  The raw honey, apple cider vinegar and vitamin C (mainly oranges in my case) treatments worked for me this time.  But I wouldn’t have done it if I had infants in my house.  I wouldn’t have done it if I wasn’t very healthy to begin with.  Etc.  
  • My personal belief is that medicine/treatment is extremely specific to each individual’s genetic makeup and environment.  What works for one person will not necessarily work for another.  
  • I have zero medical training and didn’t see any scientifically conclusive evidence to make me take the apple cider vinegar, raw honey and vitamin C route.    

So…please take this for what it is…simply one more strep throat case study added to the public domain.




WebRTC Conference & Expo – notes

 Posted by on November 21, 2013 at 10:39  WebRTC  No Responses »
Nov 212013

Brief notes from first couple days of WebRTC Conference & Expo III as we start day three:

Edge apps

The power of WebRTC is that it makes it feasible and viable for any application to incorporate real-time communications and collaboration capabilities.  That should drive communications into the long tails at the edges of communication.  We all know that but we have been waiting to see these types of edge apps – not telecom apps but communications apps.

Well, I have seen or heard of three interesting edge apps so far at the show: Minerva (education), Soundtrap (social music) and buildAR (augmented reality).  Check them out.  Look closely at them.  Many of their use cases are not viable without WebRTC (viable due to cost, scale, extensibility, complexity and/or speed).  That’s huge – it is a start of the hockey stick growth curve of edge apps.

Most of us are missing the big interoperability story

I am not talking about Apple or Microsoft.  Or SIP.  Or even the great_media_codec_debate.  Think about it – what will be the most dominant need for interop?

Mobile to non-mobile and vice-versa.  We know mobile is eating the world.  Not only does mobile often have different voice and video codecs, but mobile has completely different environments.  The interop needed is not just lowest common denominator interop – it is optimized user experience on both sides (or all sides in a multi-party).

For this type of interop, we need visibility, hooks, session management, use case intelligence and real-time adaptive behaviors. Interop between fixed and mobile is the biggest and most interesting interop story and it is not well enough represented yet.

Tools and diagnostics – mainly MIA

The early days of VoIP were all about the core technology and services.  But I remember when the operational aspects started developing.  Diagnostics, test tools, call generators, QoS and MOS, EMS, NMS, correlation, CDRs, security-focused functionality, etc.  That’s when we knew an inflection point was coming.

WebRTC is not there yet.  Not even close.  But arguably it may be more important with mobile, thin clients and last mile variety (device and network).  I did see ConMon – an interesting passive packet monitor.  I expect to see much more in this area at the next Expo.


Very strong showings from Tokbox, Requestec and Crocodile.  Looking to build the next killer video app, or just add video to another app or service?  Start with those three.

The crowd

The crowd is what makes or breaks these events – the side conversations, debates, questions and ideas.  Very good crowd again.  Less developer-heavy than Atlanta, which is surprising out here, but maybe the business folks are simply catching up.

Lot more Google Glass (and maybe some imitation wearables?) and even at least one video robot (Double Robotics).

The organizers and moderators were excellent again.  They have a nice set of articles here if you want to dive into a particular topic.


  • I haven’t see many definitive contact center deployment details.  Going to look harder today.
  • Hints are that Google Hangouts will be “fully” WebRTC in 2014.  Will it beat the ratification of the standards?  Does Google want it to?
  • 2014 is also big for mobile.  Increasing deployments of chipsets supporting hardware encoding and decoding.  Of course the continued overall growth of mobile data and mobile compute.  The emergence of VP9 (half the bit rate for comparable quality).
  • Voice is underrepresented.  Interesting as a browser is now the cheapest phone on the market and there are still an awful lot of audio calls.