Challenges of Moving from Cisco UCCX to Webex Contact Center
Estimated Reading Time: 5 minutes
We recently converted a client from the Cisco Unified Contact Center Express solution over to Cisco Webex Contact Center, a cloud-based contact center platform.
Most contact centers are the hub of an organization's contact with their customers. As a result, if the contact center is unavailable to take calls, it’s usually a significant impact to the company regardless of the size.
In this case, our client had peak usage topping out at 5000 calls per day.
This client wanted to move to Webex Contact Center (WxCC) for several reasons, including:
Flexibility for hybrid agents (on site or remote)
Better reporting options
Faster scalability during peak seasons
More resiliency with less dependency on private data centers
No more periodic patching and upgrading
There are many potential obstacles with a conversion of this size. In this article we'll explore some of them so others can learn from our experience.
During the planning phase of the transition, it was decided to keep the existing call flow design and simplify it as much as possible. Completely changing the call flow and moving to a new system would be too much to do at one time. There were many unknown data points that would be better known in the new system, given more advanced reporting functionality. Our client didn’t want to make changes to the call flow without this information. We agreed with this thought process.
The next major design consideration was the existing SIP trunking that was providing inbound calls. Our client was in a long-term SIP trunk contract, so we chose to maintain this existing SIP trunk, rerouting all those calls back to the WxCC cloud for processing using their existing Cisco CUBE Voice Gateway. This creates a hairpin in the call flow. Calls come into the existing data center, route back out to the WxCC cloud, and are then sent back to agents wherever they may exist (on customer premise or elsewhere).
With the call flow documented, it was time to build out the design in the WxCC cloud environment. We tested each call flow to make sure everything worked as expected, and then training of the agents and supervisors began.
In this case, we had training scheduled for over 100 agents. We noticed that actual attendance around 50%. Training was recorded, but some problems were reported on the day of cutover due to agents not knowing what to expect. These could have been avoided with better attendance and accountability during training sessions. From a vendor perspective, there's only so much that can be done to ensure everyone is trained without holding up the cutover date. One option clients can take is to decide not to cutover until at least a certain percentage of agents have been trained. Another option is to allow only those users who have attended training to log in and take calls on the new system.
When the time for the cutover came, the system had been thoroughly tested, including using testing tools that simulate large call volumes. The system was ready to take calls. When it was time to cut, the primary phone numbers were redirected to the WxCC cloud. This also created an easy fall-back plan. If there were any major issues, we could repoint the phone numbers back to the old system and agents could still revert back to the UCCX Finesse client to take calls. This is the best way to handle a transition like this because it's quick and doesn't require any rebuilding, restoring, etc. It’s almost as simple as flipping a switch, and completely within the clients control since it's configured with on-premise voice gateways.
Once the cutover was complete, calls were routing into the WxCC cloud and agents were taking calls. The next step was to closely monitor the call volume and typical agent stats:
Were all agents getting logged in?
Were calls being answered?
How long were calls sitting in queue?
How many agents were available?
Were calls being sent to agents but not getting answered, thus requiring a re-queue?
Were queue callbacks working as expected?
Unexpected issues will always crop up in a transition like this one. These are complex deployments with many interlocking components, vendors, and equipment. What you don’t want are problems that could have been resolved before cutover.
In this case, there were two main issues that took significant effort to get resolved. The first was caused by use of existing softphones. Our client had been using Cisco Jabber softphones with some agents on their previous UCCX deployment. On the new platform, there was enough delay created on the call leg that it was triggering ReRoute On No Answer (RONA). This means the system didn’t think the agent was answering so it returns the call to the queue, usually trying to reroute to the next available agent. After some troubleshooting and tweaking of the system, we were able to introduce a longer timer to avoid this timeout. Not a big deal in the scheme of things, but it caused a headache during the initial cutover because some of the available agents weren’t able to take calls, causing wait times to go way up.
The second area of frustration was carrier related. One specific carrier had a SIP loop occurring in their network when handing off calls to the WxCC cloud, which introduced a 10+ second delay of silence when the call setup was completed and the media path was started. This made the caller think nothing was happening, so they would hang up. If they waited long enough, eventually the RTP media stream would complete and it would work from there, but most callers aren’t that patient. It took a while to determine the specific cause of this issue, and then work with the carrier to get it resolved. Again, this was with one specific carrier, as calls were still coming in from many other carriers.
With these issues resolved, we were able to get more value out of the reports and advise the client on ways to improve their operational performance and enhance customer experience.
One last thing that is interesting to note—this entire transition was completed remotely with no on site engineering resources. Our team was willing to be on site, but in this case, the client didn’t see a need for it.
The Webex Contact Center platform offers features and functionality far ahead of its on-premise counterpart, UCCX. Transitioning can take anywhere from three to six months, depending on the number of scripts that need to be converted and the size of your existing environment. We highly recommend to our clients that they begin planning for this move as soon as possible. It's worth the effort.
This post was contributed by Lance Reid, our CEO. Lance has worked in the technology industry for over 25 years. He became a Cisco Certified Internetworking Expert (CCIE) in Collaboration in 2005 and has been serving on Cisco's SMB Advisory Board since 2013.
You may also like:
