Viewing Options

Over the years Cisco has partnered with outsourced vendors for initial handling of many simple customer contact center front-line general information inquiries. Seamlessly connecting these vendors into a converged Cisco
® Unified Contact Center Enterprise (Cisco UCCE) environment is critical to providing high levels of customer service, but it is an expensive, sometimes complicated process.

Cisco's customer contact centers were experiencing increasing call volumes and costs combined with tightened budget constraints. The traditional way of routing customer inquiries over a PSTN was no longer feasible from a risk, budget, and customer service perspective. Cisco IT solved this problem by deploying the Cisco Unified Border Element (CUBE) solution with Session Initiation Protocol (SIP) trunking, and in the process, enhanced the scalability of its network for future services integration.

In the outsourced vendor approach, the Cisco UCCE system routed calls to the destination vendor over simple PSTN connections. This process was problematic due to the UCCE feature set and interoperability with external databases that capture and retrieve customer voice portal (CVP) and interactive voice response (IVR) data. Because the PSTN does not traditionally support the transfer of both voice and data, important customer information that could be provided at the entry IVR level was lost. Often, agents had to ask customers to reconfirm data that might have already been collected at the IVR level before the call was transferred. This gap prevented certain clients from using productive UCCE features, and negatively affected customer service and internal service-level agreements (SLAs) by prolonging agent talk times and increasing client queue times and the average speed to answer.

Moreover, when sending calls out via PSTN to vendor locations, there was no certainty that they had been successfully delivered. If this happened in the carrier cloud, Cisco's control was also limited. Calls were sent to a

predefined PSTN number configured at the vendor contact center, also known as a "blind push." If an outage occurred on the PSTN circuits or at the carrier exchange, a call might not be properly connected or delivered; however, Cisco IT was unaware of this issue unless informed by a client or by internal proactive line testing before, during, and after dedicated business hours.

In addition to the impact on customer service and service resiliency, routing simple calls between contact centers globally over the PSTN cost Cisco nearly US$8 million per year.

Solution

To reduce the significant spend, mitigate risk, and increase business resiliency, in early 2012 Cisco IT implemented CUBE on local Cisco 1000 Series Aggregation Services Routers with two DS3 SIP trunks between Cisco and the vendor (see Figure 1). This configuration enables Cisco IT to route the calls over dedicated IP links to the vendor's Cisco UCCE system, thus eliminating the blind push or the expensive PSTN hop (see Figure 2). Carrier spend is reduced, and there is assurance that all calls are being delivered.

With two SIP circuits and two PSTN circuits for failover at each site, Cisco IT immediately gained redundancy and survivability for these critical communications links.

The first phase of Cisco's CUBE implementation involved provisioning SIP trunks and PSTN backup lines and deploying the voice gateways. Importantly, Cisco IT ensured that the dial plan and Multiprotocol Label Switching (MPLS) configuration was correct and could make best use of its internal network. After in-depth testing, CUBE
went live.

In Cisco's CUBE deployment planning, the following tasks were emphasized:

• Clear documentation of the design. Critical data should be documented for all stakeholders to review, including carrier circuit and configuration and support processes.

In the second phase of its CUBE deployment, Cisco will consolidate its contact centers by implementing parent-child integration between its UCCE and the vendor's Cisco UCCE systems (see Next Steps).

Results

Deploying CUBE has produced significant cost savings and other, less tangible benefits for Cisco IT. In the first
round of SIP trunk deployments, Cisco IT expects to save nearly 25 percent of its current contact center calling
costs or roughly US$2 million per year. In addition, because the SIP trunk carries voice and data, Cisco IT can offer its vendors controlled, secure extranet access back to Cisco. So, contact center agents have access to the critical corporate tools they need to perform more complex customer-service tasks, while Cisco's network and intellectual property is secure.

The SIP trunking and CUBE solution has allowed Cisco IT to employ a consolidated vendor strategy. Initially, four different Cisco support organizations are being serviced at one vendor location. These four organizations share the new single IP links, providing Cisco value for the money and a streamlined relationship with its contact center vendor.

"This was a big step up from having multiple vendors supporting different parts of the business with different network connections and different contractual terms and conditions. It is a win-win situation for all," says Mulholland.

Consolidating calls with fewer global vendors will further improve service to Cisco's customers, and yield an additional US$1 million in savings annually for Cisco.

Lessons Learned

Overall, minimal effort and management is required when the CUBE solution is in place. For IT organizations contemplating a similar deployment, Cisco IT recommends the following best practices:

• Know your customer call path. Understand your true call flow. For organizations with calls originating globally, it is essential to understand how a customer call will traverse your internal network and carrier network to hit your vendor/CUBE. This understanding is both critical for planning and basic to advanced troubleshooting.

• Design capacity for change. Although capacity is generally a milestone in any deployment planning, it cannot be over-emphasized. Your deployment design should be robust enough to accommodate changing business requirements. Take the time and perform due diligence. Investigate and understand your team's current and future roadmap, and build this input into the design. Take time to discuss this information with the carrier to ensure that it can offer the services you require, and also look at possible future requirements.

• Test redundancy. Make sure that the PSTN failover configuration is correct. Test this configuration periodically to ensure it will take over if there is an MPLS failure. Also split out the peripheral gateways and other hardware on both sides to ensure that the design is redundant at all levels per the UCCE SRND recommendations.

• Institute solid change management. Without an enforced change management process, there might be discrepancies between the configuration and the vendor/carrier that can impact call quality or call delivery. When making changes, ensure all parties are engaged and that the proposed changes are approved by all designated stakeholders. A solid process also prevents ad hoc uncontrolled changes in the shared environments. In addition, ensure that any change to the configuration made by the carrier is approved by your organization and the vendor as part of the change management process.

• Know your carrier configuration. When designing your network, understand the carrier alternate paths in the cloud. If the carrier makes changes in the cloud, will it impact your call delivery, e.g., automatic reroute at exchanges when carrier paths failover, adding call hops before final destination?

• Keep preferred carriers to a minimum. This item can be challenging; however, try to use as few carriers as possible. Determine if the carrier or carriers can offer services for your complete design (particularly if it is global) as this will reduce troubleshooting complexities and may produce cost savings if you use the carrier to provide other services. The large carriers generally have more diverse global portfolios but might be more expensive. Smaller carriers might have lower costs but less global reach and perhaps limited support.

• Know your carrier support model. This item can be overlooked until it is too late. Understand your carrier support model. Know the basic ticket SLAs to the critical escalation processes. Carriers tend to deal with large numbers of clients, so it can be challenging to get timely support particularly if the carrier is using other vendors to route calls in specific regions (carrier interconnect agreements, etc.). In turn, know exactly what data the carrier requires. Getting the correct data in a ticket the first time can dramatically increase the chance of a faster resolution. Moreover, does the carrier have online tools that you can use to make simple changes to configuration items versus opening a ticket? As always, document this information in an agreed-upon location for all stakeholders to reference.

• Evaluate carrier costs for today and tomorrow. Do not focus only on the initial costs but evaluate longer-term costs as well. Try to extrapolate current to expected data volumes and calculate appropriately. Can you benefit from cost savings if your call/data volumes increase, opening up room for negotiation?

Next Steps

In the near term, the robust SIP trunking network design will allow Cisco IT to implement parent-child integration between its UCCE and the vendor's Cisco UCCE systems, regardless of vendor location. This approach will enable true global enterprise call sharing, simplified global call routing administration, and configuration inside Cisco.

In short, a peripheral gateway instance is added at the vendor location so the UCCE sees it as another child or automatic call distributor (ACD), which may be deployed in a parent-child model where unified intelligent contact management (ICM) is the parent and UCCE is the child. This model closely resembles the deployment model of unified ICM with ACDs from other vendors. It is used for a highly scalable deployment because it provides call routers, data servers, and so on for each product, although there are more components to manage and maintain.
It is also used for a distributed model when isolation is needed between unified ICM and UCCE, such as in an outsourced operation.

Cisco IT will also deliver detailed, accurate call reporting using its Cisco Unified Intelligence Center reporting and dashboard solution, which will facilitate better management and use of vendor resources overall.

Moreover, this solution will help Cisco offer high-level service to its customers by automatically routing calls that require specialized handling to the first available agent with the right skillset, regardless of the time or where the vendor contact center is located.

"When handling customer calls, any impact to this service can be costly and negative for our business," says Mulholland. "Using CUBE gives us the sound peace of mind that our calls are getting through to the right agent at
the right time and at the right location whilst saving valuable IT expenditure."

To read additional Cisco IT case studies about a variety of business solutions, visit Cisco on Cisco: Inside Cisco IT
www.cisco.com/go/ciscoit.

Note

This publication describes how Cisco has benefited from the deployment of its own products. Many factors may have contributed to the results and benefits described; Cisco does not guarantee comparable results elsewhere.

CISCO PROVIDES THIS PUBLICATION AS IS WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING THE IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Some jurisdictions do not allow disclaimer of express or implied warranties, therefore this disclaimer may not apply to you.