Melissa Swartz | No Jitter | January 16, 2018
Your cloud solution may have more components than you thought; be sure that you understand all that’s involved.
I’ve recently worked on a couple of projects that involved migration of my clients’ UC environments to cloud solutions. Both projects involved contact center and business user requirements, which the clients discussed at length with their selected cloud vendors.
In both cases, the clients ended up with solutions that were somewhat different than they thought they were buying. Here are some things the providers glossed over during the sales process:
1. The actual carriers for the PSTN traffic. Each provider portrayed its offering as a “one throat to choke” solution. But when it came down to it, there were other players on the field. In one case, the UCaaS solution required separate carriers for the direct-inward-dial (DID) and toll-free traffic. In the other case, the cloud provider relies on one carrier for the client’s MPLS network and another for DID/toll-free numbers. While the clients do each have one place to call for all issues, they’re now hearing the familiar blame-game excuses about problems being due to the carriers and out of the cloud providers’ control. In both cases, the carriers included as part of the solution weren’t the clients’ preferred choices.
2. Integration capability. This is often a challenge and one of the biggest areas for potential problems. Realizing this, one client had done a lot of upfront investigation into integration between the cloud solution and an in-house CRM system. The client talked with both providers, receiving assurance that they could make the solution work. This proved to be one of the biggest issues in the implementation; as the providers dived into the details, they discovered unanticipated difficulties. The new system went live without the integration.
3. The learning curve. Each client was told it would have an implementation team that would guide it through the process. This was true. Both implementation teams included competent people who cared about the success of their projects. But both teams were remote; neither provider had an onsite expert available to answer questions or participate in spontaneous discussions. Emails and scheduled calls took the place of real-time conversations, and the burden fell on the clients’ IT teams to figure a lot of things out on their own. Lack of real-time onsite expertise caused some frustration; by the time the client’s team was able to talk with the vendor’s team, some of the context was lost. In other cases, the back and forth (“try this and let me know what happens”) just took too long. While both clients were able to resolve their issues and both teams learned a lot, neither had counted on the frustration involved.
4. Contact center separation. While both clients knew that the contact center capabilities were provided separately from the administrative call handling, they still expected a cohesive solution where the two components worked well together. Instead, they both have issues with calls from one system being treated differently from calls that originated in the other system. For example, if an agent is on a call that came through the contact center system, the contact center software sees the agent “active” and so doesn’t route another call to that agent. But if a call comes in to an agent from the administrative side, the contact center doesn’t “see” that call and will route a call to the agent even though the agent is already on a call. Each system lacked a simple, direct method for allowing callers to reach agents with whom they were having an ongoing discussion. Workarounds made it possible, primarily by routing calls to the agents through the administrative side of the system. This impacted reporting and call recording because they only tracked or recorded calls coming through the contact center side of the system. The reports don’t provide a full picture of agent activity because they exclude calls from the administrative side, and the time that agents spent handling them. Furthermore, these customer-facing calls weren’t recorded, resulting in a loss of documentation and customer data.
5. Call recording. One client was told that it must have equipment on its premises to handle the storage for call recordings, so the traffic wouldn’t overload the link to the provider’s data center. Because the hardware was on the customer’s premises, the client would be responsible for maintenance, patching, updates, etc. on the hardware. Since one of its primary goals in moving to a cloud solution was to reduce the amount of hardware it was supporting, this wasn’t welcome news. Eventually the provider concluded that as long as the client only used call recording for a few agents, on-premises hardware wouldn’t be required. However, if the client’s need for call recordings increases over time it’ll have to revisit this issue.
This client’s call recording capability is provided by yet another third party. Although the cloud provider had recommended this call recording solution, during implementation the engineers assigned to the project turned out to be unfamiliar with it. They spent a lot of time just getting the settings and the configuration correct, and the client heard a lot of comments from both sides to the effect of “I know my product, but not the other one we are working with.”
The other client also had challenges with call recording. It had compliance requirements for storing recordings beyond the threshold offered by the cloud provider, which told the client it could move the older recordings to another (client-provided) location and create its own tool to search and access those files. Eventually the provider did find a way to lengthen the storage period, but at an additional — unanticipated — cost to the client.
This client needed to record workers who weren’t otherwise part of the contact center environment. Its options were:
- Pay for a much more expensive contact center license for these users.
- Get a less expensive license that resides on the administrative side of the system and store the calls in a separate repository from the contact center recordings.
Eventually the client was able to negotiate a reduced license fee and used the contact center licenses for these users. Again, this was an unanticipated increase to its monthly costs.
It’s simply not possible to anticipate all of the potential challenges when working with complex technology implementations. However, understanding all of the components included in potential solutions will help you evaluate their complexity and at least give you an idea of what to expect.
Before you implement SIP trunking, be sure you familiarize yourself with common challenges and gotchas.
Nevertheless, the inconvenience today may well yield better results at the end of the process.
The point of technology is to improve the business. It is important for IT to measure outcomes in business terms rather than SLAs.
Advice from the trenches on moving communications systems to the cloud.