Contact Center Redundancy: What You Need to Know

Before we get to the actual best practices for contact center redundancy, let's start with a brief historical overview to explain why we need to be talking about redundancy at all.

Years ago, a primary business objective was to provide an avenue for customers to reach your company when they needed answers to their questions. This type of interaction evolved into a “call center” when at the time, phone calls were the only communication channel with which a call center could operate.

With the exponential growth of technology, customers now have multiple channels to connect with your company. Now we can’t refer to our once known “call center” as a call center anymore; it is now a “contact center.” Contact centers provide many ways for customers to contact your company, in addition to phone calls.

As the evolution from call center to contact center was occurring, there was a corresponding growth in company’s business data consumption rate. Data consumption refers to the ever-increasing thirst for an organization to analyze the data it collects on an hourly/daily/weekly and monthly basis. We refer to this as “Business Intelligence” or BI for short. Companies that wanted to use these analytics discovered that if they had a contact center, there was an existing application generating this data already in their organization.

Now, when a company combines a contact center with Business Intelligence, it creates a map or journey of a customer’s experience (CX) from outside to inside your organization. Now, CX is the new acronym we associate with the previously known call center/contact center.

At this point, you may be asking: “How does any of this relate to contact center Redundancy?”

With CX in mind, companies want to understand the customer’s journey before they ever arrive at a representative to have their questions/requests handled. At the very beginning of this process, before you start looking at staffing, workforce management, or quality analysis, it is essential that this now ever-important data analytics engine works and keeps running.

Redundancy in the contact center is the ability to ensure that the application keeps running when a planned or unexpected outage occurs. There are usually two paths to redundancy. The first, and least likely path, is designing the redundancy from the outset. The second is via rapid growth which causes a need to implement the redundancy after the fact. Regardless of how you arrive at the redundancy option, here are a few things to consider.

Geographic Separation

When looking at redundancy, you need to plan for the unexpected. The first thing you want to examine is the ability to separate the primary and the redundant contact center servers. The further your redundant contact center server is from your primary server, the more resilient your contact center becomes. Physical distance is not the goal here, what's more important is that the redundant location resides on a different power grid.  Therefore, if power goes out to your primary site, the redundant server will not be affected by the local outage.

Typically, when you separate the locations you also want to ensure that separate carriers and disparate media types serve each site. Again, this protects against a specific carrier’s outage as well as physical issues like cut fiber or copper.

Wide Area Network Connectivity

With a redundant contact center distributed over a geographic area, the next piece of the puzzle is the connectivity between the primary and redundant locations. The connection between these locations should be served with a low latency connection, either MPLS or via an SD-WAN solution.

Most redundant contact centers operate in an active/active or active/standby paradigm. At some point, the two applications are “speaking” with each other, and their communication is what transfers information and the collected BI back and forth. This continual synchronization is what keeps both locations up to date with the most current routing information and data configurations before an unexpected event occurs.

When an event, expected or unexpected, causes the primary contact center server to go offline, callers and agents can register and route to the redundant location. If the WAN connectivity is suspect or your backup connection is one that does not usually support voice traffic, the customer experience would be less than satisfactory which could translate to a loss of revenue and customers.

Trunk Failover

In a scenario where you have a primary and a redundant contact center server across a geographic area, another item you want to address is the failure of trunks into each location.  A carrier outage or an outage of the location where the trunks reside can cause trunk failure.

The first thing you can do is to have multiple carriers at each location. For example, if you have three PRIs (Primary Rate Interfaces) at a location, use two to three different carriers to deliver those services.

Another option is to have different trunk types delivering the service. As mentioned above, instead of three PRIs you implement two PRIs, each with a specific carrier, and the third delivered via SIP (Session Initiation Protocol) trunks.

The above would address carrier specific outages, and trunk redundancy locally, but not enterprise-wide outages. When delivering any trunk service to the contact center locations, you need to work with the carrier to ensure that you have set up call forwarding to your redundant trunks. Therefore, if the service goes down at the primary location, the calls at the carrier level will be forwarded to the redundant location.

Active Failover Testing

We've discussed how design and architecture relate to a redundant contact center. Now, the key to maintaining a redundant contact center is to ensure that it actually works. If you set up everything in the most fault tolerant, resilient configuration but never actively test the configuration, you still do not have a redundant contact center. At this point you are waiting with your fingers crossed that a failure will never happen.

The successful redundant contact centers are those that regularly force their infrastructure into redundancy mode. If you can control when your contact center is in a redundant mode, you can identify potential issues with the failure, as well as validate the technology works as expected.

All of this advice is meant to provide a high-level overview of the items to understand and implement in a redundant contact center. While it may seem like common sense, it's essential. If you are someone who has recently inherited the management of the contact center or its infrastructure, take the time and ask these questions to see how your redundancy is set up. You may be amazed at what you discover, but you won't know unless you ask the right questions.