Software Defined Contact Center

If you are a technology professional, then chances are that you are aware (maybe to the point of annoyance) that everything is getting defined in software these days. We have Software-Defined Networking (SDN), Software-Defined Data Center (SDDC), Software-Defined Storage (SDS), and the list goes on and on. Software defining anything has become such a powerful trend that we now have a generally accepted name and acronym for just that: “Software-Defined Anything” or SDx for short.

Despite the widespread nature of the trend, Software-Defined Contact Center (SDCC) is nowhere to be found amongst the Software-Defined goodness that floods our social media feeds on a daily basis. Software-Defined Contact Center is so absent from the online world that if you search Google for the term you get only articles that reference Software-Defined Data Center, seemly because 3 out of the 4 words are common to both. If you search for the #SDCC hash tag on Twitter you will find yourself at the official account of the San Diego Comic Con. This raises the question, why isn’t SDCC “a thing?” This question is particularly relevant since Cisco’s Intelligent Contact Management (ICM) has been allowing us to build Software-Defined Contact Centers since the late 1990s. Let’s take a look at how ICM delivers on the Software-Defined paradigm for Contact Centers.

Defining something with software will deliver different benefits, depending on what it is you’re defining, but there are a few key things that are common to most software definition exercises: a separated controller, the ability to use disparate systems together, and an abstraction for the configuration elements of the systems. While this list is short, each of the benefits can be correlated directly to business and operational value provided by software defining something.

Separating the controller of a solution simply means that we put the intelligence and configuration of many systems into a central place, where the systems or devices participating in the solution can connect and receive instructions for operation. Intelligent Contact Management delivers the controller functionality through its logical Central Controller, which is comprised of the Router and Logger components of the solution. The Central Controller stores information about configured elements of the overall solution and executes routing scripts in response to Route Requests from systems that participate in the overall solution. Having everything configured in a single place allows us to easily gain visibility into what the current state of configuration is and begin troubleshooting from the top down. Business stakeholders get the benefit of focusing on the controller as a single capabilities set when designing changes to their centers. It’s also the one place for the business to get visibility into the aggregate customer experience, since every contact relies on the controller for routing instructions as it traverses the systems comprising the Contact Center solution.

Having the ability to use disparate systems together is something that everyone wants; it is the reason that we have standards bodies developing protocols and manufacturers supporting the protocols in their products. Software-Defined technology solutions generally use a very mature protocol as the basis for disparate device interoperability and then layer on another standard for the device to use when communicating with the controller. In the case of Cisco ICM, we use a number of protocols to move contacts around between systems but they are all widely implemented and generally reliable. Voice contacts may move between nodes on the Public Switched Telephone Network and the IP network using standards like Integrated Services for Digital Networks (ISDN) and Session Initiation Protocol (SIP) via a Voice Gateway, or they may use H.323 to move onto a Private Branch Exchange (PBX) or an Interactive Voice Response (IVR) server. Email contacts may be routed between relay servers or mailbox servers using Simple Mail Transfer Protocol (STMP). All of these systems that handle part of the contact’s experience get instructions from the ICM central controller via some ICM specific communications standards like GED-125 or GED-145. The solution uses the right combination of protocols to make systems from different manufacturers work together without exposing IT or the business to a large risk because the standards are mature and therefore will likely be well implemented by the product’s manufacturer. The business also gets to leverage existing investments in hardware and training. Whether we have an IVR or PBX from Avaya, Siemens, or Cisco (or maybe all of them) we can use it to build and change the customer experience in a very rapid and cost effective way.

The last, and arguably most important, facet of the Software-Defined idiom that we are going to touch on here is the abstract for configuration elements. An abstract for configuration is simply a model that represents common configuration or functionality on multiple disparate systems that are part of the overall solution. In Cisco’s Intelligent Contact Management (ICM) we can find a perfect example of an abstracted confirmation element by looking at a Label. At the most basic level, a Label is a string of characters that represents an address on one of the systems participating in the solution. This may be a station number on a phone registered to a Cisco Unified Communications Manager, a Vector Directory Number (VDN) on an Avaya ACD, an ACD Group Pilot on an NEC PBX, a SIP URI, or even a phone number on the Public Switched Telephone Network (PSTN). Using the Label as an abstract for the destination of the contact allows data to be configured and captured without concern about the type of device that terminates the address of the Label. These simple abstracts allow our business and experience owners to work from a standard nomenclature and it allows IT to change the underlying devices that comprise the solution without constant re-education of the business.

These are just a few of the many benefits of using a Software-Defined approach to our Contact Centers, but hopefully it was enough to get the wheels turning and possibly look at our Customer Collaboration platforms in a slightly different light. Now get out there and impress the masses with your bold new ideas about how you can bring your Contact Centers into the Software-Defined age!

Share