Cisco Unified Intelligence Center

Contact Center Scripting and Reporting: Discovery Creates Success

  • Viewing Options

  • PDF (315.6 KB)
  • Feedback


Deploying contact center technology is both an art and a science. Over the years we have observed and participated in hundreds of contact center deployments, many of them migrations from another vendor to Cisco. Many of them have been successful in making their organizations more efficient and providing great customer and employee satisfaction. Some have not. One common denominator has been that the successful organizations have taken an active approach to understanding their business goals and how to translate those goals to the technology. The goal of this paper is to facilitate that process by introducing you to Cisco’s contact center reporting and scripting interdependence and provide an overview of the discovery process. This discovery process will create successful deployments of the Cisco® Contact Center Enterprise solution.

The intended audience for this paper is prospective and existing Cisco contact center customers who are considering replacement or upgrade of their contact center environment. This paper is also useful material for any Cisco customer considering a migration from Cisco Unified Intelligent Contact Management (ICM) to Cisco Unified Contact Center Enterprise (CCE). The reporting and scripting capabilities of Unified Contact Center Enterprise are very powerful and flexible. Although planning for these transitions can require detailed work, the results are well worth it.

This paper guides Cisco customers and partners in the discovery process, its benefits, and how to get the most from a powerful scripting and reporting environment. Whether you are outsourcing some portion of the discovery and deployment or doing it all in house, this paper can help you ask the right questions, develop the right strategy, and ultimately implement a solution that demonstrates the alignment of your contact center with your business goals.

Why Is the Discovery Process Important?

The discovery process provides a disciplined method for all key stakeholders to own the success of the project and to form a team with common objectives. The information gathered and the planning and decision making that occur will provide the foundation for the solution development, implementation, training, and criteria for success. The key stakeholders include executive sponsor(s); line-of-business (LOB) managers; IT personnel; contact center supervisors; business analysts; the reporting team; the call-flow scripting team; and representatives from hardware and software vendor(s), implementation and integration partners, and possibly business process consultant(s). The ultimate objective is for all stakeholders to form a team where everyone owns the success of the project. It is imperative that the team works together toward a common set of objectives and treats each team member as an “internal customer”.

Objectives of Discovery

The objectives of the discovery process fall into the following categories.

Identify primary business goals:

- Focus on strategy before examining the details.

- What are your key differentiators compared to those of your competitors?

- Do you have benchmarked targets to model business process transformation?

- For example: Is it more important to handle a call with the most appropriate agent and therefore have a high first-call resolution percentage or to answer calls within a certain time and therefore have a high service-level measurement? Frequent trade-offs must be made to achieve both, but it is critical to have discussions about which trade-offs you can make.

Identify pent-up demand and wish list capabilities:

- The design should focus on current needs with future goals in mind. This process represents an opportunity to identify things that may have been difficult to implement with a prior solution and were abandoned.

Map out call flows and desired customer experience for:

- Voice

- Multimedia

- Self-service

- How should agent-assisted service be included?

- What external systems or databases will be used?

- What existing self-service applications exist and how do they work?

- Will they be retained or rebuilt? How and why?

- How will the self-service data be stored and reported?

Identify data and reporting requirements:

- How do you measure success?

- How will you capture, store, and report the data?

- Look for any special or uncommon data-set usage for reports and ask for detailed definitions.

- Focus on the strong interrelationship between how you capture the data during the call-flow script and how the business will use it.

- What other sources of data outside the contact center operational metrics are relevant to managing the business?

- Build a common naming convention framework - consistent nomenclature is critical.

Discuss the agent and customer service representative profiles.

- What are the important skills for employees? How are agents hired, taught skills, segmented, trained, offered incentives, promoted, and retained?

“Like-for-Like” vs. Looking to the Future

Contact center platform changes are generally expected to last a significant length of time--on the order of 7 to 10 years, in order to maximize the investment in products, services, and user training. As a result, the current business processes supporting the system being replaced are often a bit dated. However, businesses continue to use them because “that is the way the system works”, or “it will make the transition easier”. Many customers plan to implement the same thing they had before and then roll out the newer capabilities. We have seen that attempting to implement a new Cisco Contact Center by emulating feature-for-feature what is being replaced does not enable you to enjoy the full benefits of the new system.

That is not to say that you should change all existing processes. Certain business practices have longevity for very solid reasons, and should be retained if they still meet business objectives and continue to have a good return on investment (ROI). In some cases, reproducing the existing environment is introduced as a bridge from the old to the new. However, this approach comes with a danger that should be acknowledged, in that the bridge may never be replaced with the better process. The introduction of a bridge can actually encourage bad behavior and create a requirement to perform multiple training cycles. You can achieve the most effective outcome if you can evaluate and understand anew your existing business processes. This understanding will allow you to determine which process you should maintain and which you should optimize or replace.

You can gain the most value from the new system by finding ways to improve the overall business process to meet the needs of the business today and for the future. Over the past decade of implementing Contact Center Enterprise, our greatest successes have come from this approach. We strongly urge the stakeholders to explore new ways of thinking about how to meet the real business challenges and not focus on the technical elements or the way it has always been done when seeking an overarching “business architecture”.

Discovery Process Methodology

This section provides a recommended approach to the discovery process. It is not meant as a prescriptive set of steps but rather as a set of best practices that we have seen work with many customers. Depending on the size of your organization and the amount of change in your practices, you may need some or all of these steps. There is also a wide range in the number of people required. In some organizations, one person represents multiple roles on the core teams. In other organizations, a group may jointly be required to represent one role.

Step 1. Identify the core management team.

The first and most important task is to identify the relevant team members and the right size of the team. You need to include the constituents who can define what is important to the business (that is, added services, more effective business processes, reduced costs, etc.).

For the discovery kick-off meeting, at least the following stakeholders (roles) should be identified:

Senior-level director or VP (executive sponsor)

Call center operation manager

Scripting team manager

Reporting team manager

IT manager

This team should identify the key business objectives; discuss the contact center discovery process, high-level work agreement and resource commitment, time commitment, and deadlines; and set the rules and conflict-resolution process to the whole discovery.

Step 2. Identify the core technical team.

Identify the core team of technical personnel who will take part in the detailed discovery process. This team should consist of a group of trusted advisors who can represent the view of their organization and effectively work within a team. They will typically be nominated by the core management team in step 1. There should be at least one point person from each of four functional areas, plus optionally Cisco Contact Center application experts as the application design team. Each point person may work with a larger group to collect, compile, and optimize the business requirements. Core technical team members can include:

Business operations

Call routing team

Reporting team

IT services

Application design team (typically partner or Cisco Advanced Services)

This team is responsible for development of the requirements that will be prepared in the template, described later in this document and agreed upon by both the core technical team and the core management team.

Step 3. Identify key business requirements.

Start with the business requirements and allow them to direct the reporting and call-flow requirements. The business requirements should represent overall goals of the organization and may not be limited to traditional contact center goals such as service levels and average speed of answer. The business requirements may be for the entire corporation or for each LOB, or there may be some requirements at both levels. Some examples of key requirements follow:

Service levels must be kept at 80 percent for all calls.

Increase agent retention by 20 percent next year.

Add multichannel capabilities without increasing staff.

Reduce customer turnover by 10 percent.

Increase customer satisfaction.

Reduce costs through consolidation and/or virtualization of equipment.

Reduce training costs and increase adoption through standardization of applications.

The application design team is responsible for designing the overall contact flows. This team also must make sure different business requirements do not contradict one another and differences are resolved within the core technical team. Ideally, the number of key business requirements is small to enable the team to focus on the most critical areas first. This list may be something that the team regularly reviews after deployment to either add or change objectives based on success with the initial ones.

Finally, the role of the IT team lead is to enable the business to follow best practices during the lifecycle of the project.

Step 4. Develop an application design.

An Application Design document defines the scope of application development work and how it is aligned with the business requirements. It provides detailed Cisco Unified CCE configuration, interdependency between various components of the solutions (self-service, reporting, etc.) and call-flow scripting diagrams. Thisdocumentdescribes in detail the end state of the final design but also works as a living document for regular updates during the entire lifecycle of the project.

This document contains high-level physical and logical architecture diagrams, detailed call-flow diagrams, naming convention rules, and lists of all the objects to be configured in the system for successful development and rollout of the solution. The descriptions and example lists in the following sections should be used as examples and not an exhaustive list.

Identify naming conventions.

The business users should create the naming conventions, with input from routing and reporting users. IT users or the reporting users should document to ensure that the conventions are maintained for the following Cisco items:

- Agent

- Agent team

- Peripheral variable

- User variables

- Skill groups and/or precision queues

- Call types

- Agent desk settings

- Scripts

- Dialed numbers

- Self-service scripts (network Voice Response Unit [VRU] and network VRU script)

- Attributes (for precision routing)

Naming conventions for LOBs and/or business units is also helpful, and likely already in place. You should document these naming conventions and make them available to the entire team for reference, and the IT team should publish them.

Design the call-flow template.

Application design should include a call-flow template based on the naming convention with proper provision for reporting. Try to harmonize the call flow at a high level so that customers have a cohesive and consistent experience with the company. This process should also simplify maintenance of the call flow. This application design discovery should include both routing and reporting requirements, and should happen in the same room with active participation and leadership from the business users. This template should include at least the following items:

- Call-flow name, LOB, and business unit

- Call routing during office hours, non-office hours, overflow, and holidays

- Special events handling

- Emergency call-flow handling

- Dialed number

- Script name

- Reporting requirements: When designing the application, remember that custom reports are usually needed in a call center.

Align the call-flow template with the business requirements.

After you have designed the call-flow template, you should cross-reference it with the business requirements. You should make every effort to conform the business requirements into the call-flow template based on the naming conventions. If the template and naming conventions cannot address the business requirement, then you should modify the template rather than circumventing the call-flow template, thus changing the application design.

Cisco Unified CCE is a real-time enterprise-wide routing engine that provides a single point for decision making about how contacts are handled. It provides an opportunity to share resources and virtualize across the organization. This change can sometimes be difficult in organizations that have been operating as autonomous groups. You may need to make trade-offs if the business as a whole has decided to provide a common approach rather than have each group operate independently.

Define the use of shared scripting and reporting resources.

Cisco Unified CCE enables several ways of tagging calls and passing information to the agents for desktop integration. This variable space, labeled Peripheral Variables in Cisco Unified CCE, needs to be shared, and agreement about what information is required for historical reporting is necessary.

CallTypes are used to label calls, and a call can be associated with only a single CallType at any one time. For example, a call may come into a center and be given an initial CallType, but it may be associated with a new CallType after you have gathered additional information or if you want to provide service-level information that does not include interactive-voice-response (IVR) activity. Peripheral variables are stored with the Call Detail Records (CDRs) and are therefore available for historical reporting, whereas expanded-call-context (ECC) variables are temporal so can be used for short-term requirements (screen pop or other integrations). Use of CallTypes, skill groups, peripheral variables, and ECC variables should be an integral part of the discovery process.

We recommend discussing the following to determine the correct shared approach:

CallType: If you have to change CallType more than three times, then consider other strategies, such as peripheral variables.

Real-time vs. historical data: Determine what data is required in real time vs. historical.

Peripheral Variables reports: Peripheral Variables reports are custom reports. Will you have time to develop these reports as part of the rollout? If not, what is the mitigation?

Naming conventions

Peripheral variables (stored for historical reporting) usages

ECC variables (stored during active call) usages

Special events (group training)

Emergency handling (fire drill, snow closures, and site down)

Agent skill-group membership and default skill settings

Third-party data elements, attributes for special routing, and corresponding reporting needs

Reroute On No Answer (RONA) and Cisco Unified Customer Voice Portal (Cisco Unified CVP) Requery (behavior for when an agent walks away with the phone in Ready state)

How overflow of calls from one center to another will be handled and reported

Use of conditional routing for handling high-priority calls or other conditional activities by use of custom functions

Step 5. Get agreement from all parties on the design.

Both the core technical team and the core management team should approve the design. The focus should be on the business benefits to the organization and not on level of effort, but this focus must be balanced with achievable goals and the ability to deliver the design. If necessary, a phased approach may be required to get to the overall business goals. Conflicts should be handled in an amicable and collaborative way, keeping the main solution in mind, with clear implications explored for each choice. In the end, we have observed that the best outcomes are ones that include compromise from each of the team members. It must be a joint decision to move ahead with a particular design that has each team member’s support.


Delivery and deployment of reporting and scripting cannot be serial. If reporting requirements direct the solution, scripting can become overly complex, and if scripting requirements direct the solution in a vacuum, business users may not be able to get the data that they need to run the business. The overall strategy for the business needs to direct the discovery and guide decision making throughout the planning and deployment process.

Reporting and routing requirements should be captured and analyzed simultaneously and co-developed because reports can only present the data as it is captured in the database. The routing, architecture, call flow, and configuration determine what is collected. For example, if an agent can be a member of more than one skill group, then the data in the database table will have one record per agent per skill group per interval. The reporting end user will need to understand this type of data collection so that appropriate checks and balances can be incorporated into the reports.

Note that application design (call-flow routing and reporting) is an iterative process, so all the stakeholders should focus on the transient nature of business and design the solution in such a way that it is flexible enough for future changes and enhancement requests.

The outcome of a comprehensive discovery will be motivated team members who are ready to transform their organization by following best practices. Aligning to business requirements will enable faster adoption of new features and will maximize the return on investment (ROI). In short, investing in a discovery process that engages all constituents pays off with better use of the technology, a better match to requirements for today and the future.