Recent conversations around the office have gotten me thinking about network services and the role they play in customer contact technologies and services. Over the past several years, there have been fundamental shifts in how the “network” has been used for services, moving from a data-only transport to a world where voice, video and sometimes data on the same network is commonplace. Portraying the complexities of today’s solutions is a daunting task in and of itself, and many companies struggle with the transformation.
A lot of our clients are moving from what I would term as a site-based contact center model or even overall communication plan involving PBXs and ACDs. This means that today they are housing a system that largely — or even exclusively — is self-contained within one site. If a call or interaction arrives at that particular site, then the ACD, IVR or other communication system at that site has to process the call.
This was OK back in the 1980s and ’90s, and maybe even into the 2000s (the years known as the “oughts” in my mind —as in, “Back in ought seven, we decided to look into VoIP”). But, in today’s world, the voice over IP (SIP mostly), video, chat, email and mobile interactions have dictated that customer interaction systems get a massive makeover. This has turned most site-based systems into distributed systems.
As we were talking in the office (don’t be jealous of our scintillating conversations), I’m not sure that all clients understand the complex interaction between a distributed system and the underlying network(s). Namely, the network has moved from being a simple transport mechanism that delivers emails internally to a critical backplane that ties together disparate servers and processes. And the real fine point to this technological revolution is that a client could purchase the pieces of a distributed system, but without a finely tuned network, the system and services it supplies is doomed to failure.
In particular, VoIP services have forced network transformation arguably more than any other service in recent memory. The idiosyncrasies around how to architect, engineer, and operate a network carrying VoIP traffic are numerous. At its core, VoIP is the definitive real-time protocol or transaction. To make a point about the differences, compare VoIP and a database transaction. Transferring and consuming information in a database is an example of a transaction that can have a bit of delay or be retransmitted if needed. In VoIP flows, this simply isn’t true: If you miss part of a person’s conversation, then it’s gone and can’t be retransmitted.
If you dig down into the hardcore technologies in which converged networks operate, you would notice that voice is treated differently than the data on the same network. If the voice or video doesn’t arrive on time and in the order expected, then the entire interaction could be rendered useless; so, network engineers put these real-time transactions within a special queue on the network. This is particularly true on the Wide Area Network (WAN) that connects sites together, and even the voice queue has special engineering constraints that must be taken into account.
There have been many instances over the past 10 years in which we have run across poorly designed or operated networks that are impacting VoIP services. This can be frustrating to our business partners and is sometimes blamed on the VoIP system itself, which is incorrect. That’s not to say that VoIP systems don’t have their own internal issues from time to time, but it’s been my experience that generally a new instantiation of a VoIP ACD or PBX will have at least two or three major network incidents that affect it.
In the end, the network plays as much of a role in the success of a new technology customer interaction system as the system itself does. In fact, I would argue that in the end, you need to view the network as part of the system itself.