5 Realities of UCaaS Implementation
So many myths swirl around the move to cloud-based unified communications from either on-premises UC or traditional phone systems. We have found that many times customers underestimate the amount of work necessary to properly migrate to a unified communications as a service (UCaaS) solution. Below we lay out some of the realities and provide insight into how to prepare for your own successful UCaaS implementation.
Reality #1: UC providers don’t automatically know how your system operates from the main number through to desktop phones or cell phone/device forwarding.
Unfortunately, there is no single button that UC providers can hit to obtain all the details of what happens when a customer calls your main number to be able to instantly map that to the new system. UC providers need your help in creating documentation that outlines call flow throughout the organization. We will want access to experts at the main site as well as in the field who can help chart that critical information and then update it as necessary. Call flow is an incredibly detailed and important process so be prepared to discuss call requirements for all aspects of your business.
Reality #2: UC providers can’t work alone without your input.
UCaaS is not a “sign a contract and go” experience. To get the most from your UC solution, providers and customers must act as partners. From the outset, the provider will need assistance from the customer on discovery and other upfront tasks. As example, if you have 50 locations and 50 lead numbers, we will need to know how to treat each location. For instance, should a number go to a shared pickup line for a department or directly into an employee’s voice mail? What are the business hours for the main line? What are the mapping options for the automated attendant?
Reality #3: You will need a number inventory.
Porting numbers over to UCaaS is a challenging process. The more we as a UCaaS provider know about your existing carriers, the block of numbers you own from each carrier, and amount of numbers actually in use, the faster we can execute your deployment. Having an incomplete or inaccurate representation of your DID inventory can introduce delays and create service problems. Reviewing your number inventory could save you considerable money. For instance, why pay for a block of 500 numbers when you have downsized to 20 users at a site? (Trust us, this level of over provisioning happens.)
Reality #4: You will have involvement in circuit/network access orders.
From contacting your circuit delivery provider to increase/decrease access to having someone at the ready for initial surveys or installments, customers must be involved at the network access level. Customers often work directly with their network access provider to extend their existing MPLS network into West. This will entail providing circuit related information to West to ensure cross connects are completed in a timely manner. Oftentimes, customers can get faster delivery times by purchasing circuits directly through the access provider. However, if you don’t assign an internal contact available to take the access provider’s call for an initial survey or actual implementation, then you can significantly impact delivery timeframes. And while we accommodate issues we cannot control in an SLA, failing to have an internal point of contact for circuit delivery would not be considered one of those issues. Also, the contact should know the specifications for circuit installation to avoid any order or installation mishaps.
Reality #5: The scope of UCaaS projects can change and evolve as deployment gets underway.
Scope creep is inevitable in IT and networking projects. Sales teams – as hard as they try – can’t uncover every issue that will be encountered as we set out to deploy your UCaaS solution. For instance, there might be a few more locations that need UC access than anticipated. Or you might need another circuit brought into a remote site to handle the increased volume of traffic. You might also decide to add on feature sets or integration tools once you’ve had time to pilot them. Customers must understand that scope creep affects costs and schedules, and might, if complex enough, require contract adjustments. Communication throughout the process helps to mitigate scope creep and keep deployments on time and on budget.
The bottom line is that customers do need to be involved when it comes to UCaaS. Though we will do much of the heavy lifting, a prepared, knowledgeable, and engaged team on the customer side makes implementations smoother and more cost effective.
What to Read Next