CCIP y VoIP conceptos para un diseño

Best Practices for VoIP in the Contact Center; Part 1: Planning a Successful Transition


Written by Lori Bocklund and Brian Hinton

Once you’ve decided to implement VoIP, you’ll need a plan that will help you decide what you want to gain, who can help guide the process, how you will communicate your vision internally, and how to evaluate your options.
Voice over Internet Protocol (VoIP) has reached a new level of maturity in the contact center industry. We can now shift the conversation from “Why should I do VoIP?” to “When and how should I move to VoIP?”
Because VoIP is such a rich, deep and complex topic, defining best practices for planning, implementation and support requires more than one article. Therefore, this article is the first in a series to help those that are on their way to VoIP — or anticipate they soon will be — to prepare for a successful transition that has lasting business value for the company and the center.
Start a VoIP Planning Process
VoIP offers many opportunities for delivering business value. While the multisite is the “killer application” for VoIP, single-site environments can also find business value in this new system, including pseudo-multisite configurations for remote agents in satellite offices or homes, and business continuity and multimedia contact center operations.
What value do you expect to derive from VoIP? Most find reducing costs and adding flexibility and agility to adapt to changing business needs are two of the main drivers. Others include:
· Agent efficiency and a common routing and reporting engine across all sites through virtualization
· Reduced technology costs through centralized intelligence for a distributed network of sites
· IT operations, administration and maintenance efficiency through multisite centralization
· Operating efficiencies considering aggressive growth or acquisitions, or the need for more distributed staff
· Operating efficiencies for multimedia contact handling (e.g., email, text chat, Web collaboration, fax in addition to voice calls), including a common routing and reporting engine for all media
· Enhanced disaster recovery/business continuity strategies
· Peak call-handling flexibility/agility
· Readily tap escalation re­sources across the enterprise
· Facilitate home agents or satellite offices for an expanded, flexible labor pool
When is a good time to transition? There are many events likely to force discussions on platforms, vendors and architectures, and generally will lead to a path to VoIP — whether through gradual transition of a hybrid platform or outright conversion to VoIP. Some of the triggers that prompt the transformation include:
· Out of support technology or other reason for considering upgrade or replacement
· Major growth
· New site, facility or move
· Merger or acquisition
· Leadership change, cultural change, power shift or other organizational event
· Replacing or pursuing adjunct applications such as CTI, QM, WFM
· Reorganization or other operational change that tears down silos by site or group
· Vendor dissatisfaction
Companies find many reasons to move to VoIP. Then the real planning can begin.
Build a Crossfunctional Team
Implementing VoIP in the contact center impacts several areas of the organization. It is essential that a team made up of representatives from contact center operations, IT and Telecom coordinates the VoIP project. Table 1 lists the minimum required team and purpose of each player’s involvement.
The primary project sponsor will likely come from IT or the contact center(s). However, the project has limited possibilities for success without all of these departments involved as stakeholders in the transition. Some projects also include analysts, training representatives, human resources, change management and others, at least for specific meetings dealing with issues pertinent to them.
Table 1. Crossfunctional Team Members and Their Roles


Develop a Vision
With the team in place, the next step in VoIP planning is to develop a clear vision that is communicated and understood throughout IT and call center operations leadership. Everyone must see how VoIP will help the center achieve the defined business goals, what it will look like in the organization, why it makes sense, and the path to get there.
It is also important that IT understand how the new system architecture fits in its overall goals and strategic directions, and how it will successfully implement and support the new environment. Because there is more than one way to implement VoIP, you will need to develop a VoIP technology strategy and transition plan as part of the vision. The technology strategy and plan lead to architectural decisions for IT and functional capabilities for the center.
Consider Options, Choices and Design Decisions
One of the primary responsibilities of the team and one of the key components of the technology plan is to decide what VoIP really means in the organization, given the variety of ways to implement it. The choices depend on many factors, including the current infrastructure (in­vestment, configuration, age, support, vendor, network readiness, etc.), the business goals and the triggering events pointing to VoIP. The approach will differ for an enterprise versus a contact center focus, and for evolving the current platform with the existing vendor versus replacing the current system.
A good starting point in considering all the options, choices and design decisions the team must make is to take stock of the factors and influences in the current environment. Then you can proceed through the planning phases shown in Figure 1 on the previous page.
VoIP can primarily be for call management (agent availability and routing decisions), delivering the call to the desktop as TDM or VoIP — as data packets over the network. You will need to address the strategy for phone replacement and many other questions about the desktop: Gradually evolve to IP phones when TDM phones are at end-of-life (an option only when evolving the current vendor’s platform)? Move to IP on a standards-based phone based on Session Initiation Protocol (SIP) or a vendor’s own flavor of IP? Place phone controls on the PC (soft phone)? Put the voice path through the PC? Connect the PC to the phone and use the phone as a switch, or have two jacks and data paths to the desktop? Plug the IP phone in or use PoE (power over Ethernet)?
While these are just some of the design decisions faced when transitioning to VoIP, the following are others you’ll want to consider:
· Scope — enterprise or contact center(s) only
· Vendor — evolve current vendor or choose new vendor
· Overall architecture — hybrid/transition from TDM, full VoIP
· Sourcing — premise-based solution or hosted or managed services
· Other contact center applications — leveraging current or seeking new applications beyond routing and reporting — e.g., CTI, IVR, QM, WFM
· Server architecture — redundancy, locations for applications and media servers, gateways and interface devices
· Network architecture — termination locations and dial plan strategy for toll free and local, MPLS or other network protocol between sites, converged voice and data or separate voice network
· Endpoints — TDM or IP, soft phones and/or hard phones, SIP or proprietary if IP
· Desktop power strategy — PoE or local power, backup
· Desktop connectivity strategy — two jacks/network access, or single jack with PC connected to phone
· Encoding strategy — compression across WAN, or full G.711 throughout network
· Quality of Service strategy — what methods at what layers
· Security strategy — consistent with data networks and applications, or any differences for voice
· Testing and retesting/monitoring strategy — for jitter, latency and packet loss, at a minimum
A key decision is whether to integrate or replace other current applications. Many contact center VoIP vendors have other applications already integrated with their solutions. In fact, ACD, CTI and even IVR can be part of the core solution. Some vendors bundle quality monitoring and call recording, and even workforce management. Current investments, current use and the vendor solutions in play all impact these decisions. Table 2 summarizes considerations for key adjunct applications.
One of the benefits in a multisite environment is the ability to install the primary hardware/software in one or two hubs — reducing cost and facilitating business continuity/disaster recovery. Now more decisions arise: how many hubs, where will they be, and what gets installed at each location? With the data-like architectures of today’s voice systems, these hubs may reside in a data center rather than a call center location.
There are also some interesting blended options available that again depend on the current investment and architecture. Some companies with multiple sites and various, up-to-date PBXs at each site will use IP (not Voice over IP) for agent availability and routing decisions for pseudo-virtualization. Virtualization depends on tie-lines for call movement. Business value comes from agent efficiency through virtualization but not the IT/telephony benefit of VoIP with hubs and centralization. This can be a more complex and expensive environment to maintain and support. See Figure 2.

Figure 1. VoIP Planning


Table 2. Key Considerations for Adjunct Applications


Complete the VoIP Planning Process
With a vision, key decisions regarding options, and a common plan for virtualization in a multisite environment, you are nearly ready to move on to implementation.
Of course, standard best practices in project management apply. Document decisions and issues, and prepare a project plan that defines not only the technology steps but the related organizational, process and operations changes that will accompany the VoIP project. Prepare to involve the staff in the trenches — both in IT/telecom and the call center — if not already engaged.
Our next article in the series will provide best practices for implementation, covering the key steps for network preparation, design, configuration and development, testing, pilot, and rollout. Part 3 will provide the critical elements of supporting and effectively applying the new VoIP environment.

The Virtualization Opportunity
One of the primary drivers for VoIP is the cost savings through virtualization. This can be a result of agent virtualization and server/application virtualization across sites. The potential for agent efficiency through virtualization depends on the contact center’s virtualization readiness, and the degree of virtualization sought. The figure below shows varying degrees of virtualization, with greater change but also potential benefit on the far right end of the spectrum.
Figure 2: Virtualization Continuum

The maximum value from virtualization occurs for multisite or multiple, smaller functional groups that transition to any agent, any time routing schemes. However, this is often difficult to achieve in practice. Is every agent capable of handling every call? Can every agent access the required applications? Is it possible to train every agent to process every call type? Are there any licensing or other regional issues? Can processes be standardized across all sites/functions? In most centers, the answer to these questions is “not completely,” but there is usually some potential for cross-training, skills consolidation and process standardization. Many will start modestly and continue moving in the virtual direction. Define the process changes, application changes, training or technology such as Knowledge Management required to get the benefits of full virtualization. This decision and vision is a key part of planning for virtualization in a VoIP environment.


Best Practices for VoIP in the Contact Center; Part 2: Steps for a Successful Implementation
');
document.write('');
document.write('');
document.write('');
document.write('');
//-->




Written by Lori Bocklund and Brian Hinton
With your VoIP implementation plan in place, the relationship you’ve built with your IT department and vendor will really come into play. Take advantage of this teamwork to get the most value out of your project.
Voice over Internet Protocol (VoIP) has reached a new level of maturity in the contact center industry. We can now shift the conversation from “Why should I do VoIP?” to “When and how should I move to VoIP?”
Because VoIP is such a rich, deep, and complex topic, defining best practices for planning, implementation and support requires more than one article. Our first article addressed how to plan for VoIP and the important decisions to make regarding virtualization, technical design, functional capabilities and other factors. This article, the second in the series, focuses on implementation. We hope it will help those who are on their way to implementing VoIP — or anticipate that they soon will be — take all the right steps to be successful.
Click here to read Part 1: Planning a Successful Transition.
Build a Detailed Project Plan
Building a project plan marks the transition from planning to implementation. Oftentimes you can leverage the vendor’s project plan as a starting point or for input in building your master, internal detailed project plan. Be aware, however, that the vendor’s plan is generally very limited in scope, and you will probably need to document your detailed plan before the vendor’s is available.
The project plan links all the key players. Table 3 in Part 1 of this article series detailed the cross-functional team members and their roles. Each team member has critical functions to perform to ensure a successful migration. While IT probably knows it needs to prepare the network, and telecom probably knows it needs to prepare the facility for installation, and operations knows it needs to prepare the staff for process change, the detailed project plan is the only way to reveal dependencies among the various tasks so these many efforts come together at the right times.

First and Foremost — Properly Prepare the Network
There are many things that lead to a successful implementation but there is one item that is THE primary enabler of success — the data network has to be properly prepared to carry voice! Often, IT feels its data network is ready for VoIP or it can be with minimal changes. This position must be backed up by detailed assessment and testing. In reality, IT may need to make key changes and upgrades to make the network “VoIP ready.”
A comparison of traditional voice and data network characteristics (see Table 1 below) reveals why moving voice onto a data network should not be trivialized. A network built for the behavior of data packets is not adequate for carrying voice as data packets.
The differences in voice and data characteristics drive the following requirements for VoIP:
· We need quality controls that prioritize voice (quality of service, or QoS).
· We need to monitor and manage performance (latency, jitter and packet loss) to acceptable levels.
· We need to use different protocols (RTP/UDP vs. TCP) that emphasize speed over accuracy.
· We need highly reliable, scalable, secure networks.
· We need standards for voice that are adopted by all (with session initiation protocol, or SIP, being the “winning” standard in today’s market).
The addition of voice places new demands on the IT team even though many of the same principles for effective network and systems operation apply in creating secure communications and a scalable, reliable network. Voice traffic sizing must consider whether the voice is compressed or not. This decision generally applies across the WAN but not the LAN (most LANs today have adequate bandwidth so don’t require compression). Users accustomed to a “five nines” reliable voice environment expect their voice communications to continue to be available at all hours, in all circumstances. As we emphasize below, assessments, testing, and ongoing monitoring are keys to success.
Most likely, you will be putting voice on a converged (data and voice) network. Regardless, with VoIP you will be putting voice onto a network designed for data. Since voice and data communications have completely different characteristics, IT must monitor and manage the network differently to assure control of the voice packets for optimum delivery. Most companies apply QoS strategies to ensure tolerable delay in packet arrival (latency), variability (too late, too early or out of sequence) in packet arrival (jitter), and packet loss. For better network management and control, many change their network service between sites (across the WAN). Multi-protocol Label Switching (MPLS) is typically used as it enables voice packet prioritization.
Some companies take a more conservative approach and use a separate voice network to avoid either voice or data traffic suffering under load. This approach can solve network capacity projection concerns. It can also simplify the testing required. However, it comes at a greater network and resource cost.
A best practice is to have a thorough network assessment by your chosen vendor or a third party that specializes in network assessments. This assessment will identify changes required to your network for capacity and functionality, and may lead to switch and/or router upgrades or replacements. Your vendor needs to validate network readiness once you make the required upgrades. The data network must be load and quality tested prior to cutover as well as part of the ongoing network management.
Bottom line: For VoIP implementation success, the IT/networking staff has to guarantee that the network is secure, scalable and reliable to a degree to which it has not been accustomed for data communications.
Table 1: Traditional Voice and Data Network Characteristics


Dive in — Design, Develop/Configure and Integrate
Each design step, without exception, requires cross-functional involvement and a commitment of the appropriate time and resources. Onsite design sessions with active participation from IT, Telecom, Operations (including call center and other business users) and vendors will contribute to a successful implementation. (Make sure consultative design sessions are included in the vendor statement of work, or SOW.) Also, trainers need to be involved in the design meetings so they can develop and deliver training prior to cutover. The following list details some of the topics to discuss in these meetings:
· Routing for virtualization
· Call-flow design
· IVR usage
· Role of CTI
· Desktop applications — call/phone control/unified desktop/screen pop
· Multimedia contact routing
One of your main responsibilities is to manually document call flows, work flows, switch configuration and IVR set up into flow charts and spreadsheets so the vendor’s design engineers can “translate” the design into the new solution. This is a demanding process and is the source of business value at cutover when changes are made to the existing configuration. The tradeoff is ease of design and translation if you keep everything the same versus achieving business value sooner when you approach the design as a “green field” opportunity for improvement.
Before the vendor can install the solution onsite, you must prepare the facilities. Many vendors offer a site survey as part of the design process. The vendor will detail necessary upgrades to racks, power, heating/cooling, ventilation, space and additional cable requirements. Work closely with your vendor to ensure that the implementation is not delayed due to unprepared facilities.
The vendor will then use the design session outcomes to configure your solution within their system. Include knowledge transfer and onsite time in your vendor SOW if you intend to manage your own system going forward.
The complexity of the integration process depends on the solution you have chosen. If you are implementing a suite solution with all components pre-integrated, the primary issue will be the overall integration with your legacy data sources and any additional adjunct applications. If your solution is a mix of components, the vendor may be providing the components and the integration. Otherwise, if the solution includes separate vendors, IT and the telecom staff (and potentially third-party integrators) will have a major integration effort to implement the total solution.

When You’re Nearly Ready to Launch — Test, Train, Pilot and Rollout
Once the project team has designed the solution and the vendor has installed and configured the system, the next step is to test the system. It is crucial as part of the planning and design to determine where and how a testing and a training environment will be set up. Both environments need to be “live” early enough to allow for ade­quate testing and training. The vendor will begin with system operability and will test that the solution “works” as designed, that all the components “talk” to each other, and that any integration for which they were responsible was successful.
Once the vendor has determined the solution is ready for user testing, you will test all call flows in detail including all IVR applications (self-service). Develop a test script that includes every call path for every call flow option and conduct all appropriate test types and scenarios. IT and telecom staff will need to test the network capacity and resiliency of the entire configuration. Vendor involvement in this testing varies but at the very least they should be standing by to solve problems discovered in testing and stand behind their design.
Representatives from training identify changes during the design session for supervisor, agent and administrative staff that will require training prior to cutover. Changes for the front-line staff may be significant — more than getting familiar with a new phone. There will most likely be a completely new desktop interface and functionality. The vendor will often be responsible for administrative training and train-the-trainer for supervisors and agents. Sometimes the vendor will deliver training materials and hold the initial training sessions for the frontline staff. Define the training approach in the vendor SOW.
It is difficult to schedule enough time during implementation for testing and training, so be careful these crucial steps do not get lost in the rush to meet milestones. Additionally, the training cannot be so early that the frontline staff forgets prior to going live.
If organizational structure, systems and time allow, cutover can be more successful in a phased approach where any problems can be identified prior to a complete rollout. It is ideal to start with a small pilot group that tests the solution in production, with real customers. Once the pilot is successful, it is time for rollout generally by site, group, or function (rather than the “big bang” approach). Mitigate risks by cutting over during off-peak or closed hours.
Complete the VoIP Implementation Process
With the system in production across groups and sites, the company should start to reap the business value from its new VoIP technology. However, as with any new technology and operational change, it may take a few months for things to settle in and for the teams to work out all the kinks. Then, support be­comes critical to optimize technology application to business needs.
VoIP is a different world that creates new issues and opportunities for IT, Telecom, and support functions in the contact center. We will address this issue in our final article in the series: best practices for supporting and effectively applying the new VoIP environment.

Key Steps in the VoIP Implementation Process



Achieve Business Value Out of the Gate
Achieving business value isn’t easy, especially right from the start. Sometimes it is tempting to implement “as is” to minimize the overall impact of change, with the goal to really apply the new system capabilities later. This approach is dangerous, as it is even harder to change after implementation, and companies often lose resources and momentum after cutover (and, therefore, never achieve the changes and optimal business value). Pursuing operational change after implementing new technology that replicates the old approach will require an ongoing commitment or a whole new project and team. Using a formal change management process can mitigate the impact of the overall change. Our recommended best practice is to embrace the change and maximize business value during initial implementation.