Lessons Learned from the Trenches of UCaaS Implementations

I have worked on several projects recently that involved UCaaS solutions where the end user organization had a need to support both regular business users and a contact center environment. One of the solutions had evolved, starting as a contact center solution first, with support for the regular business user capabilities added later. A second solution I worked with had the opposite evolution -- it was originally designed as a solution for business users and contact center capabilities and support were added after that.

 

Both solutions offered a fairly complete solution as far as their primary development was concerned. But both had some significant shortcomings on the capabilities that were added afterwards. In both cases, they were capabilities that, in my opinion, should be available in every system out there.

 

In both cases, requirements were defined in advance and covered with the selected UCaaS provider in detail. Even so, there were unexpected challenges along the way.

 

Here are some of the issues that we ran into:

 

DNIS reports -- Both systems had, inherently, focused reporting on the number the caller was calling from (Caller ID or ANI) and were lacking in information about the number that the caller dialed (DNIS). Both organizations I worked with needed the DNIS information for call routing and reporting. Since it’s quite common for organizations to run marketing campaigns and track the response by giving out different toll-free numbers for each campaign, it’s very difficult to understand how this information is not readily available in the data associated with the call for call routing and reporting.

 

Shared lines -- Many organizations have extensions that appear on more than one phone; often a number is shared by several people who are all responsible for answering it. While hunt groups and queues are more automated ways to offer this capability, some users don’t want to have to log in and deal with the extra steps required. While the majority of users don’t need shared lines, they are important to those who do use them. There are specific use cases that demand shared lines; for example, executive assistants need to be able to monitor and answer the executive’s calls. Inability to support this capability forces these users to change how they work in order to accommodate the technology, rather than the technology accommodating them and making them more productive.

 

Separate systems for contact center and business users -- One solution had two totally separate applications for the contact center and business users, with separate management tools for each “side.” Capabilities and user set up were different based on where the user was configured. While this is true any time the contact center is served by a separate solution than business users, the part that frustrated the client was that the capabilities were sold as one cohesive solution. Under the hood it was not cohesive, but separate.

 

Call recording -- Both the contact center and business side recorded calls, but one did it mainly for training and short-term documentation of conversations. The other had compliance regulations that required calls to be stored for years. The solution they were using only offered storage for 400 days. After that time, calls had to be moved elsewhere for longer term storage. In addition, once the calls were moved away from the UCaaS provider, the tools for searching and locating recordings were lost. The provider suggested that the customer create its own tool to allow its users to search archived recordings. Eventually the UCaaS provider found a way to offer longer storage, but at an additional (unplanned) expense to the client.

 

Furthermore, in this same solution, the repository for call recordings was different for regular business users and contact center agents. The client needed to record some business user calls and faced the issue of dealing with two separate repositories and separate tools for searching. In order to keep all of the recordings together in one repository, the other option was to pay for the more expensive contact center licenses for those users, and require them to log in and behave like contact center agents.

 

Full admin rights -- In one of the solutions, full administrator rights were required for contact center supervisors who needed to access historical or real-time reports. It was not possible to restrict these rights to reporting only. In addition, admin rights on the business user side were a prerequisite for contact center admin rights. This meant that far too many people had the ability to access every part of the system. The potential for problems -- malicious or innocent -- is disturbing.

 

Every project has its share of unexpected challenges, and there’s simply no way to ensure that ALL requirements and expectations are covered in advance of an implementation. With UCaaS solutions in particular, be aware that these solutions are relatively new and do not always have the breadth of features that older premise systems offered. Organizations with call coverage requirements beyond calls going straight to voice mail should be sure to define these requirements in detail to ensure that they can be accommodated.

 

Contact centers are always complex and care must be taken to ensure that all capabilities required -- from call routing to reporting, recording, and integrations -- will be met.