Like many large enterprises, Cisco Systems uses multiple contact centers to communicate efficiently with customers, channel partners, and employees. By 1999, Cisco had built or acquired more than 20 call centers located around the world, serving different types of callers and varied business needs.
Supporting these diverse and widely separated call centers presented large challenges. Cisco business managers needed ways to make operations simpler, consistent, and more efficient. Cisco IT needed to address the support and management challenges of many different systems and applications.
Cisco was rapidly growing as a company, particularly through acquisitions. With this growth came the need to manage diverse call centers, each with different systems, operating procedures, and business focus. Cisco business and call center managers faced several challenges, including:
Costly, inefficient call handling. Numerous small centers that handled only certain types of calls meant operational inefficiencies and high costs. For example, the ability to overflow calls between Cisco centers in California and North Carolina required tie lines and carrier routing services at an expense of nearly US$50,000 per month. In addition, call centers that served narrow functions incurred the substantial expense of dedicated facilities, equipment, personnel, and call transport.
Inconsistent service to callers. With so many call centers, it was difficult for Cisco to deliver a consistent and high level of service to callers. Variations in agent skills also created a negative impact on service levels and caller satisfaction. In many cases, callers endured multiple transfers or had to make additional calls before finding an agent who could provide the needed information.
Inconsistent reporting. Many contact centers had multiple locations, in multiple countries, on multiple PBX systems. Contact center performance was measured according to reports run locally on the PBX in each department. Each person could run reports differently and get different results, which made it difficult to consolidate performance data for management purposes. Because there was no centralized repository for call data and statistics, there were numerous inconsistencies in reported results.
Limited operational flexibility. To implement 24-hour availability for the customer service call centers worldwide, Cisco had to rely on traditional automatic call distribution (ACD) systems that simply forwarded calls from one center to another. Call routing was extremely limited, based primarily on after-hours routing or a percentage allocation of inbound traffic, without regard to customer need or agent expertise. This call forwarding from one ACD to another also required intensive administration and maintenance activity.
Limited knowledge sharing. The existing ACD systems did not support the knowledge base that agents needed, such as automatic information displays ("screen pops"), or monitoring tools for the call center managers.
Cisco IT's goal was to bring new technology to the call centers, while implementing standards that would reduce costs, improve service, and increase operational efficiency. To accomplish this, Cisco IT faced several technical challenges:
Lack of standards. Overall, there was no reasonable methodology for simplifying call center processes, using call center agents and resources to handle multiple call types, or easily outsourcing call center functions. Different reporting capabilities and terminology made it difficult to consistently measure service levels and agent performance across all Cisco call centers.
Migration to Cisco solutions. A corporate goal at Cisco is to use the company's own products wherever possible in the network, IT environment, and business operations. For the call centers, this meant replacing the traditional PBX, ACD, and interactive voice response (IVR) systems, as well as numerous applications for call handling and call center management.
Franklin King, a Cisco IT engineer, summarizes the business and technical challenges: "We saw a lot of needs, both internally and externally. We needed to apply economies of scale and consistent technology across all call centers. We needed to route calls on an enterprise level instead of to single buildings. And, we needed a way to get calls to the agents who could solve the problem on the first try."
Cisco IT was a major participant in the extensive effort to implement a multi-phase, multi-year plan for improving the call centers. One goal of this plan was to use Cisco network and call processing technologies: the Cisco Intelligent Contact Management (ICM) system and, in a later phase, the Cisco IP Contact Center (IPCC) solution.
Phase 1 of the plan for the call center migration, launched in 1999 and completed in 18 months, focused on three initiatives that would take advantage of the intelligence in the Cisco enterprise network:
"Our traditional voice system had 'look ahead' capabilities that provided a certain amount of intelligent routing, but it was expensive to use those features," says Scott Fairman, an infrastructure engineer for Cisco IT. "We actually eliminated many of the costs of call routing by integrating our call centers and making our call handling architecture more efficient."
Cisco ICM delivered a number of valuable features for the goals of Phase 1
An important Cisco ICM feature for combining the operations of separate call centers is the use of customizable, flexible scripts for call routing. These scripts reflect Cisco business rules and route each call to the best agent based on the call topic or the availability of agents with a particular language, skill, or other factor. Wherever an agent is based, the Cisco ICM system delivers the call and supporting customer and call data, which are drawn from a central database.
To complete each transaction, Cisco ICM profiles the customer using contact-related data such as dialed number and calling-line ID, caller-entered digits, data submitted on a Web form, or information obtained from a database lookup of the customer profile.
"Using Cisco ICM, we could route calls to different locations with better variables," says King. "We also gained visibility within each of our existing PBXs, including the number of agents, the number of calls, and activity reports. Based on that data, we wrote new routing rules so that calls would be answered more quickly and the workload would be distributed appropriately." Cisco ICM also enabled external outsourcing companies to integrate their PBX systems, of multiple types, with the Cisco ICM system for improved, real-time call routing and standardized reporting through Cisco WebView.
The Phase 1 implementation of Cisco ICM also yielded valuable information for Cisco call center managers. "At the end of Phase 1, every agent in the integrated call centers was visible in a single database, along with customer contact and case information," says Cindy Mike, a Cisco program manager. "This information was available to Cisco managers around the globe, which helped them to make better decisions about call center operations."
Phase 2 implementation for the call center migration plan began in 2002. The goals for this phase included eliminating the remaining inconsistencies in call handling, increasing the use of Web tools for knowledge capture, and deploying IP-based systems to replace the TDM-based PBX, ACD, and IVR systems as well as agent phones.
The Phase 2 technology architecture included Cisco CallManager for call processing, Cisco ICM to control call routing, Cisco IP IVR to control call queuing, Cisco WebView software for reporting, and Cisco Computer Telephony Integration Object Server (CTI OS) Agent Desktop software for agent control of answered calls. The Cisco WebView tool allows company managers to efficiently report all performance data for all contact centers globally, eliminating the need to compile numerous and varied local reports. Cisco WebView also provides consistency in report contents by maintaining a central database.
"Phase 2 required a fast schedule for migrating 13 sites from TDM systems to the complete Cisco IPCC infrastructure," says Fairman. The project team assessed the needs of the diverse Cisco call center groups and the different business and cultural considerations for locations around the globe. Most groups were housed in standalone call centers, but the Cisco headquarters site in San Jose, California accommodated 15 different call groups.
As part of this assessment, the project team determined which call centers served customers and which served only employees; in addition, which call centers had activity that could be contained within a single site and which groups supported global operations in multiple locations. The assessment also identified agent skill sets-from corporate operators who handle general inquiries, to the Cisco Technical Assistance Centers (TACs) that are staffed by engineers.
The project team found other challenges in preparing for Phase 2. In the traditional PBX environment, agents were accustomed to handling calls by pressing buttons on the phones. In this phase, agents migrated to the Cisco CTI OS Agent Desktop software, which controls softphone functions through a screen display on an agent's computer.
At the end of Phase 2, Cisco IPCC was implemented in 10 locations, connecting nearly 800 agents and handling approximately 100,000 calls per month. The call centers were using nearly 40 new applications, including Cisco WebView for managing reports.
Phase 2 was defined as a corporate initiative, with a challenging goal of a six-month deployment schedule. Through careful planning and a team that quickly applied the lessons learned at each step, the deployment was completed in seven months—still considered a rapid pace. "We learned in the early sites how we should design the migration tasks and applications, and that helped us to deploy the systems faster in the later sites," says Fairman.
Phase 3 of Cisco's plan for call center migration delivered the CiscoLive application, which allows a customer to click on a Web link to request a callback from a Cisco agent. CiscoLive also provides interaction tools such as URL sharing, form sharing, and text chat, which help the agent and customer collaborate in a Web session while talking on the phone. CiscoLive operates through the Cisco Collaboration Server and Cisco Media Blender features in Cisco ICM.
Cisco IT also used the Common Channel Interoffice Signaling (CCIS) Collaboration API (now called the Collaboration Server Session Platform SDK) to create custom applications such as an electronic "white board" and clipboard, which allow Cisco TAC agents to collaborate with customers online while on a support call. Another application is a Telnet session, visible to both parties, that allows a TAC agent to demonstrate procedures and run diagnostic tests.
The migration to Cisco IPCC has produced impressive results. As of 2005, in Cisco contact centers worldwide:
Cisco managers wanted to change the way Cisco worked while providing a consistent and positive call experience for customers and employees. The Cisco IT project team also had a mission—to migrate all of the separate, customer-facing call centers to a cross-functional, virtual organization that could take advantage of economies of scale and share resources to cut costs.
The Cisco IPCC migration effort achieved this business alignment through a combination of executive sponsorship, program organization, a well-considered migration strategy, re-engineering coaches, and ongoing communication.
Executive sponsorship. "Cisco's CIO was an enthusiastic executive sponsor for the migration to Cisco IPCC, which gave us the influence we needed to work with all of the groups involved. This included multiple Cisco voice and data groups, as well as the business groups in charge of the contact centers." says Mike.
Program organization. To manage the large number of projects required for the call center migration, Cisco designated this effort a technology program, with Cisco IT employees serving as program leaders for the various planning, implementation, and support teams.
Strategic site migration. "We started with low-risk call centers that served only employees, then implemented the higher-risk call centers as we gained more experience with the Cisco IPCC technology," says Fairman. "We wanted to resolve issues internally first. After we were confident of a successful implementation, we gradually deployed the technology to customer-facing call centers." Global customer-facing sites, such as sales and support centers, were the most visible to Cisco customers and the most likely to create a negative impact if the migration was not well executed.
As each center successfully completed the Cisco IPCC deployment, the Cisco IT project team tracked lessons learned and applied them to improve processes and standards for the next group of call centers. With this process, the Cisco project team gained site experience, infrastructure assessments, feedback, and, most importantly, acceptance from Cisco call center personnel.
Re-engineering coaches. Re-engineering coaches were a new role introduced for this program to help call center employees understand and accept the major changes in systems and operations. "We brought in someone from each call center to be a re-engineering coach. We asked that person to be our primary contact during the migration process for that group," says Mike. "The coach's job was to train local employees, participate in planning meetings, and communicate project status during the actual change in systems." Because of the coaches, Cisco IT staff did not need to be present during the system integration at each call center. Instead, the migration activity was remotely managed by Cisco IT staff, who worked with the local staff through phone calls, e-mail, and online interaction.
Ongoing communication. Regular communication to Cisco employees was vital to the smooth progress of the call center migration program. The migration team communicated program news, status, and schedules through the Cisco employee communications Website, e-mail aliases, and regular program meetings. Training tools, a glossary of terms, access to reporting tools, call center listings, and business rules were examples of additional information posted on the program Website. Each call center also had a dedicated Webpage that provided site-specific migration status.
Continuous improvement. At the end of each call center migration, the program team sent a Web-based survey to each agent, asking questions about the quality of advance communications and training on the new system. The survey also asked about any problems the agents had experienced with software, network performance, or voice quality. "Because of the information that came back from those surveys, we could fix things in real time, and not impact the deployment." says Mike. "We had 39 Cisco IPCC deployments in total, and at the height of our activities, we could successfully migrate four call centers in a week."
A team within Cisco IT continues to work with the contact center managers on deploying new product versions, assuring standardization, and developing new applications as needed.