Planning the Cisco CallManager Implementation

This chapter is from the book

Cisco CallManager Best Practices: A Cisco AVVID Solution

Learn More Buy

This chapter is from the book

This chapter is from the book 

Cisco CallManager Best Practices: A Cisco AVVID Solution

Learn More Buy

Assess the Current Voice Environment

Organizations profit from the unique expertise and skills of their employees and partners. A properly configured, flexible telephone system can help you take advantage of these unique skills by providing customized features at users' desktops. But deploying these customized features requires that the installer understand the skills required of each individual in the organization. Deploying appropriate phone features and eliminating unused features makes the most effective use of the system. You should inventory user requirements and skills and then categorize users into user classes. User classes are an effective method of distributing the right features and capabilities to the right users. Planning this activity before the initial installation and configuration avoids customer frustration and change orders and saves you time and money.

Creating user classes has an ongoing advantage. As new users are added to an organization or existing users are moved from one part of the organization to another, they inherit phone feature requirements associated with their new positions. Applying an existing feature template that efficiently serves users with similar job descriptions consumes less time than creating a customized template for each new user. Over the system lifetime, it is this concept of user and feature templates that saves system administrators configuration time. CallManager provides softkey templates, phone button templates, device profiles, and device pools to aid in developing user class-based configurations. In addition, Cisco provides several different phone models designed for different types of employees. For example, phones models differ in the number of line/feature buttons they provide, because some employees, such as executives or their assistants, might need more buttons than other employees.

Conduct a Feature Inventory and Create User Classes

If you're migrating from an existing phone system, the simplest path to efficient inventory and classification is to use what is already at hand. In many cases, an enterprise's voice team already maintains separate spreadsheets or databases of users and the phone features associated with their jobs. Frequently, these databases associate a named user class to each user. This user class represents a set of users with equivalent requirements and skills. Common phone features are normally assigned to each phone in a given user class. In the absence of an existing spreadsheet or database, some PBXs have tools to create such databases or spreadsheets based on the existing PBX configuration. Use these tools when available to provide a good starting point. Third-party data extraction tools such as those from Unimax (http://www.unimax.com/) can aid in the transition as well. You can find a list of all certified partners at the following link or search Cisco.com for "AVVID find a partner":

http://www.cisco.com/pcgi-bin/ecoa/Search

Data extraction tools can form the basis of CallManager softkey and button templates. Without these tools or existing data, you would need to create the database from scratch. The accuracy and time required for this inventory are a direct function of the scope of the inventory: The broader the database, the longer it takes to create it.

The approach of gathering the inventory has two extremes—representative sample and exhaustive sample. The representative sample is composed of a sample of the user population that represents a reasonable percentage of each user class in the organization. The exhaustive sample approach requires an interview with every user in the organization. An advantage of the representative sample approach is that the time required to complete the interviews and inventory is considerably shorter than with the exhaustive sample approach. The primary disadvantage of the representative sample approach is the likelihood that one or more special user classes will fall through the cracks, necessitating follow-up interviews and inventories.

The recommended approach includes a combination of representative sample and exhaustive sample. Conduct random sample interviews of up to 10 percent of the total organization's population. Conduct a 50 percent sampling of users identified as having critical positions within the organization. When an organization has fewer than five critical users, interview and inventory all of them. In addition, consider a baseline of users across all job functions that might require special features or services. For example, users with hearing impairments have special requirements such as amplified handsets. Finally, event-specific features associated with an event or brief task normally are not assigned as common features to a user class. An example is a malicious call trace, which might be applied to an individual's phone during a brief interval.

The first step in creating the feature inventory database from scratch is to construct a list of all users to be interviewed. List all user features and capabilities in rows, and list all the interviewees in columns. As users in the listing are interviewed, query them for the features they have used in the past and the job responsibilities they have not been able to fulfill as a result of existing phone feature deficiencies. The goal of the interview is to identify requirements as well as deficiencies in previous phone configurations that have prevented or hindered users from accomplishing their jobs. Table 1-1 is a sample interview form.

You can complete the form by devising a legend for interviewee responses, such as R for a required feature, D for a desired feature, X for an unused feature, and so on, and marking the interviewees' responses in the row associated with each feature. Be sure to have a second page listing all the interviewees' names so that you have a place to make notes during the interviews. You can photocopy Table 1-1 or download it (FeatureInventory.pdf) from the Cisco Press website (go to http://www.ciscopress.com/1587051397). If Table 1-1 doesn't satisfy your needs, use it as an example for the tables you design. Be sure your tables include all the features and custom IP phone services your deployment offers.

Table 1-1 Sample Interview Form

Click to view Table 1-1

For future releases of CallManager, the form you use, whether Table 1-1 or the downloadable file shown in Figure 1-3, should be updated to include new features.

Figure 1-3 Exec Admin Tab on FeatureInventory.xls

The interviewing sessions with members of the various user groups in your organization are also opportunities to educate users about new features, services, and capabilities that could help them work more effectively. For example, Cisco provides a broad range of mobility solutions that give mobile users choices for staying connected while on the road or moving around the organization's campus. Exposing these new capabilities to users allows you to provide a solution to a user's problem that might not have been solvable with a previous phone system. The interview also serves as an opportunity to set user expectations about phone system operation, planned training, and installation and configuration plans.

After the feature inventory is collected, create a set of user classes that represent a common set of user features and capabilities identified during the interviews. Although CallManager can store hundreds of button template configurations, you should try to limit the number of user classes to a reasonably manageable quantity—10 or fewer—to most efficiently manage subsequent personnel moves, adds, and changes.

Document the Existing and Desired Dial Plan

During every installation, whether new or existing, you should document the dial plan in fine detail—down to the last known number. Whether you are integrating with a PBX, replacing a PBX, or bringing up a new site, the dial plan is an essential element you must master.

If you don't know the numbers in use in your system, you are completely in the dark. In some cases, you might be neglecting certain populations of users without knowing it. When the cutover to Cisco IP Telephony occurs, those users will not have 100 percent service. At the worst, you might be assigning numbers to IP phones that are already in use in other parts of the network, which can cause serious havoc.

The most common uses of dial plan numbers are

• Internal extensions

• Rollover extensions (if line 1 is busy)

• Emergency numbers

• Trunk-access codes

• Tie-line access codes

• Message waiting indicator (MWI) on/off numbers

• Application numbers (call center, voice mail)

• System speed dials

• Route/hunt patterns

• Translation patterns

You must meticulously document the existing dial plan and determine where the IP phones and applications will fit. The best way to do this is by using a spreadsheet that details the number ranges in use, groups of devices to which the number ranges are assigned, and any number translations in use. For an example of a dial plan document, check the Cisco Press website (http://www.ciscopress.com/1587051397) for a downloadable dial plan document in Visio format called Sample-Dial-Plan.vsd. You can modify this sample document and use it for your deployment.

Document Classes of Service

It's important to understand any existing restrictions and to whom they apply. By understanding the current environment, you can provision CallManager to meet the same level of restriction. Many times, only the simplest forms of restriction are implemented. Some of the most common classes of numbers in the U.S. are

• Internal-only

• Local

• National

• International

• Intra-LATA (Local Access and Transport Area)

• Local toll

• 900

• 976

Non-North American Numbering Plan dial plans might use classes such as

• Internal-only

• National

• Mobile and pager

• Emergency

• Premium rate numbers

• Free-call

Normally, partitions are designed around some of these classes of service. They are classes of numbers that represent route patterns that can be assigned to partitions, which are then assigned to calling search spaces (CSS), which in turn are applied to phones. You can use any combination of these classes to create calling search spaces that result in classes of restriction for users. Restricting calls by using calling search spaces is discussed in more detail in Chapter 7, "Configuring CallManager and IP Telephony Components."

How the classes actually get implemented depends on your company culture. Some companies like to restrict long distance calls for certain employees. Generally, all premium-rate services (such as 976 and 900 numbers in the U.S.) are blocked. Publicly accessible phones generally offer local calling only. These are just guidelines; every organization is different.

Document the CDR Method

If you're migrating from an existing phone system, you should document the method you're currently using to gather call details. It's important to understand the existing system, if any, and to choose the right CDR package to meet your billing and call accounting needs. If you are not using any CDR method currently, Cisco provides a solution. The CDR Analysis and Reporting (CAR) tool offers some CDR functionality. However, in most cases, and especially for deployments with existing CDR systems, a third-party tool may be required.

In most PBX environments, transfer of CDR data is achieved via serial interface to the PBX using a printer, PC, or spooling server. One improvement that IP telephony brings, especially in a centralized call processing environment, is that a single CDR management system can service many sites. Traditional PBXs require a PC at every PBX location.

See Chapter 11, "Administering Call Detail Records," for more information on CDRs.

Talk with Existing Users

A critical component of any successful deployment is learning from the various user communities how people actually interact with their phones. Without direct input from the end users, it's impossible to determine the proper softkey templates and training topics. If you have an existing PBX, you have to pay close attention to the difference in feature access methods and address these differences in your training sessions.

Talking to manager/assistant (boss/admin) users and to console operators or receptionists is essential. You'll find that many boss/admin interactions differ. Not everyone uses the functions in the same way. For some users, IP Manager Assistant (IPMA) is the right application, but for others a simple shared-line scenario suffices. Depending on the type of business or organization, other user types might include the following:

• General worker (individual contributor)

• Mobile workers/telecommuters

• Sales or marketing

• Dorm residents

• Teachers/professors in a classroom

Get a representative sample of users from all these types and other types that are applicable to your organization or business. See the earlier section "Conduct a Feature Inventory and Create User Classes" for more information.

It's also critical to understand how end users interact with callers and how their customers are used to being handled. Do not make any assumptions. During the planning process, be sure to sit with some end users and watch them work using the current system. Try to map what they're doing to possible CallManager configurations, but at the same time, try to build a better mousetrap using CallManager's advanced functionality. Perhaps you can improve their call-handling iterations. A good example is how PBXs handle music on hold (MOH). Generally, a single music source is attached to a CD player. With CallManager, up to 50 different groups or departments can stream different, specially recorded messages to callers on hold. Rather than meaningless music, you can play a unique message that can positively impact your clients or customers.

Categorize users into various groups based on how they use their phones. You will surely find that the majority of users use hold, transfer, and conference. You also might find a group that uses park and group pickup.

The user features get implemented using different CallManager components such as button templates, calling search spaces, partitions, and more. So, after you talk to the users and build a matrix of user classes and features, you can use it to define each of the required components. If you are not yet familiar with components such as calling search spaces, partitions, and softkey templates, read through the documentation and other Cisco Press books in the Cisco AVVID Solutions series and get a little hands-on experience. The following list provides some examples of user features.

• Calling restrictions required by different user types—These allow you to start scoping the different calling search spaces, such as Internal/Emergency, Local, National, and International. You'll read more about calling restrictions in Chapter 7.

• Line appearance requirements—You can define different phone button templates, such as Standard (Cisco IP Phone 7960 with one line appearance), Manager (7960 with two line appearances and a privacy button), Receptionist (7960 with a 7914 line expansion module to have 10 line appearances), and so on.

• Feature requirements—You can define the different softkey templates, such as Standard, Manager (iDivert), Receptionist (CallBack, Quality Reporting Tool [QRT], Malicious call trace), and so on.

• MOH requirements—You can define multiple MOH audio sources, with names like Silence, Standard, Department Specific, and so on.

With these components created, plus the other device-specific features defined within the matrix, the specific user classes can be accurately described in a way that anyone can implement. Table 1-2 provides an example.

Table 1-2 Sample User Classes and Configurations

Determine the Current Applications

Determine all the voice applications that are currently running on the voice network. These may include but are not limited to those listed in Table 1-3, which are provided either natively in CallManager, via an optional Cisco solution, or optional third-party solution. Table 1-3 does not provide a comprehensive list of partner solutions. You should check the Cisco AVVID Find a Partner page on Cisco.com at the following link for the complete list of third-party solutions, or search Cisco.com for "AVVID find a partner":

http://www.cisco.com/pcgi-bin/ecoa/Search

Table 1-3 List of Features and Cisco Equivalents

You should have a migration plan for each of these applications, all of which can be developed either natively with CallManager or Cisco products or with third-party solutions. The point is to avoid overlooking anything and to address all needed applications at the beginning of the project. Nothing puts a project off schedule like missing applications. You also want to avoid having to explain why an application doesn't work as expected.

Document All Existing Hardware

Various types of nonphone hardware are in use at most companies or organizations. These include devices such as

• Headsets

• Amtel units (user-to-user text messaging)

• Recording equipment

• Dictaphones

• Attendant consoles

• Conference room speakerphones

• Remote microphones

• Wallboards (used in call centers for displaying real-time queue statistics)

• CD players

• Muzak units (piped-in ambient music, also known as elevator music)

• Wireless phones such as Cisco Wireless IP Phone 7920 or other third-party wireless (DECT) phones

Check and fully test the compatibility of each of these devices with CallManager. In some cases, you can phase out the existing equipment and use native CallManager functionality. A good example of this is CD players used for MOH. Given the prevalence of the MP3 file format, you might decide to stream hold music directly from a server rather than worrying about connectivity to a CD player or Muzak box.