Cisco Solutions for CRM Integration

As mentioned earlier in this chapter, Cisco integrates with popular CRMs via elements of the Cisco IP Communications suite, which includes the Cisco IPCC Express and the Cisco ICM and IPCC product families.

The two product families include core and optional components that offer SMBs and large enterprises alike the ability to scale and adopt a customer contact solution that is most suitable to their unique needs. Both families are closely coupled and share several of the same optional components. However, the ICM family represents somewhat of a subset of the IPCC family because the IPCC family encompasses the core component of the ICM family and combines it with Cisco IP Telephony products to create a fully IP-based contact management solution. The IPCC Express is a scaled-down version of IPCC aimed for contact centers of up to 150 users.

Cisco ICM Product Family

The core component of the ICM product family is the Cisco ICM Enterprise Edition, formerly known as the Cisco Intelligent Contact Management. Additional family components include the Web Collaboration Option (formerly called the Cisco Collaboration Server), the E-Mail Manager Option (formerly known as the Cisco E-mail Manager), the Enterprise Reporting, and the ICM Hosted Edition.

The ICM Enterprise Edition (ICM EE) software provides a customer contact platform that transcends the concept of a more traditional contact or call center, which typically offers a single mode of customer interaction by phone. ICM EE creates a dynamic and varied customer contact environment that Cisco calls the Customer Interaction Network.

SMBs that deploy ICM EE can communicate with their customers via both synchronous and asynchronous communications channels—including phone, web, text chat, e-mail, or Voice over IP (VoIP)—all during the same session. ICM EE is not a CRM solution in and of itself. It integrates with CRMs and can use data from a CRM database to facilitate even more incisive and precise call routing than is possible based only on the initial customer input (dialed number, number called from, customer responses to voice prompts). ICM EE's core capabilities are skill-based call routing, queuing, and monitoring, coupled with extensive fault tolerance features in the event of a component failure.

The ICM EE is available with many different hardware configurations that scale in capacity to service one or more call centers, with a varying number of agents per call center. The ICM EE operates on Intel-based hardware platforms, with storage requirements varying as a function of the final configuration, but typically in dozens of gigabytes. The software components of the ICM Enterprise Edition include the following:

• The Central Controller

• The Peripheral Gateway (PG)

• The Network Interface Controller (NIC)

• The Administrative Workstation(s) (AWs)

Central Controller

The Central Controller component of the ICM EE software uses one or more computers and is responsible for making the call routing decisions. The Central Controller is composed of several software processes, which include the CallRouter, Database Manager, Logger, Synchronizer, and Agent. Each of these processes has unique functions, and when an ICM deployment is viewed through a hardware (as opposed to a software) lens, some of the individual computers on which the Central Controller is installed might be referred to by the process name.

It's common to have a call router and database server computers in an ICM deployment. The Logger, Synchronizer, and Agent processes offer interface functions within the Central Controller as well as between it and other elements of the ICM architecture.

The database server relies for its operations on the Database Manager and Logger processes, which are always installed on the same computer. Typically, the CallRouter is installed on a separate computer, except for the smaller deployments, which actually apply in most SMB environments. The database server (SQL Server) stores the central portion of the ICM database, with the local elements of the database residing on the AWs. The composite database (central and local) is composed of approximately 200 tables in a dozen categories.

A portion of the ICM database is designed to facilitate a proper ICM integration with a wide variety of on-the-premises phone systems and provider networks. Collectively, the tables that comprise the information about the ICM's interfaces to local and public phone systems are referred to as device data. Cisco offers a detailed schema of the ICM database (all the tables and the fields in each table) as part of the ICM product documentation.

ICM integrates with the Cisco CallManager (see Chapter 8), as well as with phone equipment (ACDs/PBXes) from Avaya, Ericsson, Nortel Network, Siemens, and others. ICM also integrates with Interactive Voice Responses (IVRs) and Voice Response Units (VRUs) from at least a dozen vendors. The provider networks include major phone companies like AT&T, British Telecom (BT), Sprint, France Telecom, and others.

Similar to how the heart of the ICM software is the Central Controller, the heart of the ICM database is the collection of tables that facilitates the selection of the most suitable resources to address a customer's needs. The resource selection is based on the following:

• Required type of service (What does the customer need?)

• Agent skills (What is the knowledge level of agents to address the customer needs?)

• Agent availability (Is anybody around? How long is the wait?)

• Current service levels (How busy overall is the system?)

The best destination for each call is chosen as a function of these variables. To select the best route, the Central Controller must interact with the PGs (located on the SMB's premises) and a provider's public telephone network. The Central Controller's interface with the PG(s) takes place over the LAN/WAN infrastructure where ICM is deployed. The interface to the provider's network occurs via the Network Interface Controller (NIC). (Note that this is not the other NIC—which stands for network interface card—with a MAC address that connects a PC to a LAN!)

Peripheral Gateway

The PG acts as the interface between the site's phone system (PBX, CallManager, or a hardware-based ACD) and the Central Controller software. The site's phone system is referred to as the peripheral in the context of ICM deployment.

The PG accepts input from the peripheral that relates to the status of the system (agent availability, call wait times) and forwards it to the Central Controller following a conversion into the ICM-database compatible format. The Central Controller, in turn, uses the information from the PG to make call routing decisions.

The ICM software has features referred to as prerouting and postrouting. Prerouting applies during the Central Controller's interaction with the NIC (see the next section), whereas postrouting applies to exchanges between the Central Controller and the PG. With postrouting enabled, the PG can receive routing instructions from the Central Controller, which effectively turns the phone system (peripheral) into a routing client to the ICM. The practical impact of the postrouting feature is the ability for intelligent call transfers either between agents or VRUs, which further enhances the ability of the ICM software to service the customer.

Network Interface Controller

The NIC interfaces the Central Controller with the public signaling network, typically SS7. The signaling network assumes the role of a client with respect to the Central Controller, with the NIC acting as an intermediary between them. Through the NIC, the signaling network delivers instructions about an incoming call to the Central Controller and expects to receive instructions before the call is forwarded to its final destination. The instruction that the Central Controller receives is the routing request from the caller, which includes all digits that have been entered by the caller (the dialed number and any caller-entered digits [CEDs] in response to prompts) as well as the caller's billing number (typically, the calling line ID).

Based on the status of the site's phone system that the Central Controller obtains from the PG, the Central Controller might decide to accept the call into a particular call center or pass routing instructions through the NIC into the signaling network for additional call routing to the best destination. Prerouting is the feature of the ICM software that allows the Central Controller to interact with the signaling network through the NIC before the call is delivered to its final destination. The NIC as a software process might run on separate hardware, with the appropriate interface into the provider's network, or it might run on the same hardware as the CallRouter process.

Administrative Workstation(s)

The purpose of an AW is to allow real-time monitoring of call center activities and to provide tools for managing the ICM software configuration. The configuration tools include the Configuration Manager and the Script Editor. The Configuration Manager is used to update the ICM database with information regarding skill groups, agent assignment to skill groups, data for devices with which the ICM interfaces, and all of the other relevant configuration information that is stored in the approximately 200-table ICM database. The Script Editor is used to create routing scripts that match a contact with a particular route and queue, which translates into the assignment of an agent to handle a particular contact.

At least one AW is required per ICM deployment. Multiple AWs offer redundancy and facilitate a greater degree of distributed configuration management. There are two types of AWs in the ICM architecture: distributor and client. The distributor AW maintains a direct connection to the Central Controller element of the ICM software and receives from it real-time and historical data about the call center activities. That data, in turn, is passed on to the client AWs that do not communicate directly with the Central Controller. In a multi-AW scenario, with a distributor and client AWs present, the distributor AW offloads the Central Controller from having to communicate with and transfer data to all of the AWs, thus allowing the Central Controller more CPU cycles to perform its core function of routing calls and communicating with the NIC and PGs.

Factors That Affect ICM Deployment Design

Deploying the ICM Enterprise Edition, with or without any of the options, is a serious design decision. You and the potential SMB need to take multiple variables into account while proceeding through the design process. These variables will affect the final configuration and the cost of the system. Assuming the decision is made to proceed, consider the following:

• Size and number of call or contact centers— ICM scales to multiple sites, but it can be deployed at a single site as well. For multiple sites, a WAN or Internet connectivity is assumed. The size of individual call centers affects the hardware requirements. ICM uses highly distributed hardware architecture and, as a function of the number of agents servicing a call center, it becomes possible to combine software processes on fewer or even a single hardware platform, which is a major benefit for SMBs.

• Location of the contact center(s)— Are all of the contact centers in a region serviced by the same phone provider, or is the SMB global in nature, with multiple locations serviced by different providers? The location of the contact centers will affect the number of NICs and their interfaces to the public telephone network(s).

• Existing phone equipment— Is the existing phone equipment compatible with ICM? Check the latest ICM documentation to verify the compatible PBX/ACD/IVR equipment vendors. Existing equipment will affect the selection of interfaces for the PGs.

• Differentiation in the agent skill levels— Are all of the personnel at a similar skill level, or is there a significant differentiation between them? Does the nature of customer support require a significant skill level differentiation? Determining the different skill levels before implementation will be extremely helpful during ICM configuration.

• Server hardware— Does the selected and/or available server hardware meet the minimum specifications for installing ICM? Consider selecting equipment with performance and storage capacities that are higher than the recommended minimums for better scalability in the event of growth. Cisco provides a Bill of Materials (BOM) that identifies the hardware processing and storage requirements for installing ICM in varying configurations. As a function of the size and/or topology of the ICM deployment, consider what processes can be combined on the same hardware platforms and which require separate units. Two key variables that affect hardware requirements are the number of agents and the maximum busy hour call attempts (BHCA). BHCA represents the number of calls coming in at the busiest time. Ideally, all calls should be answered properly.

• Operating systems (OSes)— Are the OSes for the selected hardware compatible with ICM? Make no assumptions; verify compatibility by checking the latest Cisco documentation or by consulting an account representative who has access to knowledgeable system engineers.

• Database design— Have you familiarized yourself with the ICM database and decided on the values for the various categories of tables? It's advisable to develop the ICM database before implementation as part of the design process.

• Documentation of the current network— What is the state of the current network documentation? If the current network is poorly or not at all documented, the implementation stage of ICM might suffer. One reason that the current network should be documented is to fit ICM components into the existing IP addressing scheme.

• Fault tolerance— What is the desired level of fault tolerance in the ICM system? What are the business goals behind building fault tolerance into the system? ICM uses hot standby and synchronized execution approaches to implement fault tolerance. In hot standby, critical processes are duplicated, with the primary performing the active tasks while the secondary remains idle. In the event of the primary task's failure, the secondary process takes over. In a synchronized execution approach, critical processes are duplicated on separate computers and run concurrently in synchronized fashion. In the event of failure of one of the synchronized processes, the other one continues to run. A Node Manager process within ICM is responsible for restarting any failed processes.

Cisco IP Contact Center

The IPCC platform combines the ICM software with Cisco IP Telephony products to create an IP-based contact management solution. CRMs integrate with the IPCC through the ICM software. The IP Telephony products that are part of the IPCC include the Cisco CallManager and the IP IVR application. CallManager is a VoIP PBX and is a core component of the numerous IP Telephony solutions from Cisco, including the MCS 7800 series and the retiring ICS 7750. IP IVR is a software application that is used in the IPCC environment for call queuing and the playing of announcements to callers, in addition to prompting callers for input regarding their accounts or menu options.

Although IPCC is an entirely IP-based contact solution, given the extensive Time Division Multiplexing (TDM) integration options of its components (the ICM software and CallManager), it readily integrates with TDM-based legacy telephony platforms. This means that SMBs considering migrating from a legacy to a fully IP-based contact platform can do so in increments, especially when multiple call center locations and a considerable amount of legacy equipment are involved.

The IPCC deployment topology follows the models that are applicable to the CallManager and, consequently, the CallManager-based solutions, as discussed in Chapter 8. Architecturally, when comparing the deployments of IPCC to that of ICM with the traditional ACDs, the IPCC deployment simplifies routing, decreases system load, and even allows for the combining of optional software components on the same servers, thus reducing the hardware requirements. From the overall design perspective, it follows that all of the design considerations that are applicable to CallManager and the ICM software (see the previous section) also apply to IPCC. Table 7-1 summarizes the design considerations that apply to the IPCC solution.

Table 7-1. Design Issues Applicable to IPCC

Design Issue	Relevant Characteristics
Topology	As applicable to CallManager (CM), the ICS 7750, or the Media Convergence Server (MCS) 7800 series solutions: single site, distributed multisite, centralized multisite
CM hardware	As applicable to CM, ICS, or MCS
ICM minimum hardware	Pentium III or Xeon based servers with 1 to 4 CPUs, 1 to 4 GB RAM, CPU processing speed of 733 MHz and up (typically, 1 GHz+)
Servers OS	Windows 2000; always check latest data sheets
Site phone equipment	Interfaces with ACDs, PBXes, IVRs, and VRUs from major vendors
Carrier interfaces	Major carriers: AT&T, Sprint, BT, France Telecom, and others
Fault tolerance	Extensive fault tolerance via CM, ICS, and MCS; ICM hot standby and synchronized execution
BHCA	From 7000 to 250,000
Agents supported	From 200 to 5000+

In addition, when considering IPCC, you need to think about the implications of CallManager being an IP-based telephony solution. IP Telephony offers flexibility in the deployment topology of call agents (folks taking customers calls, not software processes)—a flexibility that is not found in TDM-only scenarios.

It follows that IP connectivity between all of the physical locations where the agents are located is a must. But if you consider how readily IP broadband connectivity is available between most locations over the Internet, then even a SOHO, an employee's home, or a small branch office suddenly becomes a viable element of a distributed IP call center. A key element in the decision to proceed with an ICM product family versus IPCC might boil down to what telephony equipment the SMB already has in place and how distributed geographically the skill resources are.

IP Interactive Voice Response Application

IP IVR from Cisco is an application that integrates with both the ICM and the IPCC product families. The IP IVR includes the following:

• Application engine— Manages the IVR applications in response to the incoming calls.

• Administration web interface— Configures the application engine itself.

• Editor— Develops the actual IVR applications that fit the unique needs of each installation.

In the IPCC environment, IP IVR can be installed either on the same server as the CallManager (smaller deployments) or on a separate server as a function of need for a greater overall system capacity.

The IP IVR differs from the traditional IVRs because it does not have physical telephony trunks or interfaces. In IP Telephony environments, physical trunks terminate at voice gateways rather than at IVR servers or ACDs. The IP IVR supports up to 150 logical ports, whereas a single CallManager supports up to 4 IP IVR servers. These numbers translate into a total support of up to 600 IVR ports available in a single CallManager installation, which accommodates call center needs from the smallest of SMBs to large enterprises. From the system availability perspective, in an IPCC IVR deployment, CallManager supports redundant configuration of the IP IVR servers.

IVRs can support call queuing if the required skilled resource is temporarily unavailable and the call cannot be routed anywhere else. While the call is in the queue, an IVR application can perform its more routine functions of making announcements, playing music, or collecting additional input from the callers. In addition, when IVRs are integrated with a contact platform like ICM or IPCC, the information that is collected through them becomes part of the comprehensive reporting that is required for the effective functioning of customer contact platforms.

IVR applications can be deployed in numerous SMB scenarios (technical support, insurance claims processing, delivery services, and transportation), but they are particularly popular in the financial services industry. Most banks and financial institutions now have online account access and an IVR application that interfaces with the core banking software. The IVR allows customers to perform many of the same account maintenance functions that are available online. The convenience of IVR in the banking industry is that in situations where online access is not feasible, customers have the option of inquiring about their account status by phone. This availability still tends to be more common than Internet access.