Mar 10 2017 5 Tips To Make Your Next Avaya Upgrade Go Smoothly
Over the past five years, the enterprise voice market, traditionally monopolized by industry giants such as Avaya and Cisco, has changed. Now we’re seeing migrations to platforms dominated by communications and collaboration tools.
As a direct result, many of my own customers have recently undertaken major initiatives to either replace or upgrade their telephony infrastructure with more modern solutions that embrace the new technologies and offer the redundancy, reliability and flexibility required by today’s enterprise landscape.
For customers on those more traditional Avaya platforms, such an upgrade usually involves establishing a geo-separated environment where the switching infrastructure operates as a single telephone switch across multiple sites. Avaya’s standard upgrade of this nature involves creating a multinode switching environment consisting of an Avaya Aura platform and a Session Initiation Protocol (SIP) backbone.
Unfortunately, many of these same customers I’ve seen embark on this type of upgrade have found the standard Avaya upgrade falls short of an ideal plan. Why? Avaya best practices are focused on the optimal configuration of the telephone switch and not necessarily on the optimal operation of the call center.
If you’re in a similar situation, don’t worry. All hope isn’t lost. Through our experience with our clients, here are five “frontline-tested” tips to ensure that your next Avaya call center upgrade goes smoothly.
Tip 1: Develop a Comprehensive Acceptance Test Plan
With any major upgrade, there should always be a comprehensive acceptance test plan that can be used to establish a benchmark on how the solution should operate once the upgrade is complete. In the case of Avaya, the typical verification test is to simply ensure that dial tone is present once the upgrade is complete. For redundant configurations, Avaya will also typically test failover of the new switching infrastructure.
For call center environments, however, the tests should be much more comprehensive, focusing on the call flow the user will experience once the call center is operational. So, if a caller would normally be answered by an Interactive Voice Response (IVR) system and then routed to a call center agent, the test plan should confirm that a call is successful from beginning to end to truly verify successful operation of the call center.
Tip 2: Use Call Center Agents to Test the Call Flows
In theory, you could have anyone sit in to test your call flows. But why be arbitrary when the best people in the organization to run the tests are your call center agents? They have the hands-on experience with how callers expect to be handled. Moreover, they are often able to identify smaller issues experienced during the test that may not be apparent to IT personnel, who are a few steps removed from the process.
And in my own experience, I’ve found call center personnel are better at articulating the problems they experience in a new system, and also have better credibility with the vendor when flaws are found.
Tip 3: Support Your Call Flow, Not the Manufacturer’s Best Practices
To be blunt, we’ve noticed that best practices suggested by the manufacturer are not necessarily in the best interest of the customer’s environment.
Take, for example, Avaya’s suggested deployment of the IVR in the new Avaya Aura configuration. As part of the Avaya best practices, Avaya recommends that the IVR be placed in front of the switch rather than behind the switch. The IVR and the Avaya Communications Manager are connected behind an Avaya Session Manager that routes calls to either the IVR or the telephone switch.
Since the call reporting engine is a component of the Avaya Communications Manager, it is impossible to get comprehensive reports showing the entire call flow using Avaya’s recommended configuration. So, while Avaya’s “best practice” for deploying the IVR may save switch licenses, it makes Computer Telephony Integration (CTI) screen pops and comprehensive reporting impossible.
Tip 4: Establish a Backup plan
Often a vendor like Avaya will start an upgrade or migration of the telephone switching system without considering the fact that the upgrade may fail or not pass your acceptance test plan. If you have a scheduled down time for the switch while the upgrade is being performed, at some point, you may need to back out the upgrade if the tests prove unsuccessful.
So if you want to be able to recover in case of a troubled upgrade, have a back-out plan in place with a schedule that can be executed at a particular time to ensure you have a functional switch (old or new) at the end of your upgrade period.
Remember that it takes time to rollback changes, so you’ll need to have sufficient time built into your schedule to back-out the upgrade if something goes wrong.
Tip 5: Develop an Operations Manual
As part of your upgrade project, it is always a good idea to produce an operations manual for your new system.
Yes, the vendor will provide you with standard manufacturer documentation on the system, but these typically deal with how to configure the system, not on how to operate the system. Since your solution will be configured a specific way based upon your requirements, you’ll need an operations manual that describes how your system is configured, as well as the approved way to manage the system.
More importantly, if you have failover plans, the operations manual should describe how to transition to the failover configuration and return back to normal operations after the issue has been corrected.
Final Thought
Look, we get it. Avaya upgrades for call centers can be challenging, complicated and, worst of all, time consuming, and the tips I’ve shared today require your commitment. But trust me when I say you don’t want to rely on shortcuts or manufacturers to do the heavy-lifting for you. Yes, you may save time and avoid headaches in the short-term by skimping on testing or operations manual creation, but you’ll be setting yourself up for potential failures in on the road ahead.