The Search for a Cloud-Based Telephony System - Part 1
I’ve recently been working with a client on the Gulf Coast – Hurricane Alley, as we like to call it – that is interested in replacing its traditional IP PBX system with a cloud-based telephony system. The company feels this would allow it to be more flexible in times of major and minor disasters, some of which it has recently experienced – hurricane, flood, and even an ice storm!
For those enterprise readers who might be watching the cloud communications space from the sidelines, trying to determine if this path is right for your business, I thought it could be helpful to share some of the lessons learned from this client’s migration journey. In part one of this two-part series, I’ll walk you through each step of the process and the issues and experiences we encountered along the way. Should your enterprise dare to walk this direction in the future, you’ll be armed with a little know-how.
Step 1 – Evaluate Your Needs
Pretty typical, right? Basically, step one in any technology migration process involves getting a list on paper of what your enterprise needs and wants. This is pretty straightforward for many, although I still see many clients skipping this step and going right to step six – to look at the “cool, shiny stuff” (presentations/demos). Of course, this is a mistake because what you want/need will become unclear as you are dazzled with the new technologies. You must put your requirements on paper to keep your efforts focused and your vendors on task. This also ensures getting an apples-to-apples pricing comparison (or as close to that as possible). In the case of my client, during the evaluation process we also discovered that the company needed to bolster its infrastructure, as it was lacking the redundancy needed.
Step 2 – Decide on Cloud vs. Premises Telephony System
This is a new step in the process for many organizations, as the cloud has changed the game a bit. If you don’t make this cloud vs. prem technology decision early, you’ll be pulling your hair out later, going back and forth between the two approaches as you also try to figure out which vendor to move forward with. The key decision factors for my client included total cost of ownership (TCO), Infrastructure, disaster recovery needs, and simple system administration.
TCO is often one of the key considerations in cloud vs. premises decisions. Some factors are easy to quantify, such as one-time costs and monthly recurring costs as well as purchase, maintenance, and moves, adds, and changes (which are typically included in the cost of cloud-based solutions). Also, the impact of infrastructure costs is measurable. Other soft costs are more subjective, like the value of speedy deployments and labor savings.
In my client’s case, it did not currently operate a data center and all of the sites were in the same local area. So for the on-premises solution, we had to add the cost of the data center, an MPLS connection, the redundant voice/SIP service, and Internet service. In addition, we needed local broadband Internet and VPN/routers for failover. Altogether, this meant a more expensive deployment option. For the cloud solution, on the other hand, we had to add redundant local broadband Internet, SD-WAN for failover and voice quality, and firewall/security. We were also able to include savings on the cloud side of the equation for voice/SIP services that were no longer needed at the business’s main location. Ultimately, the cloud approach made more sense.
Step 3 – Agree on Your Decision Criteria
For this project, the client ranked its decision criteria as follows:
- Reliability & Call Quality
- Provider Customer Service
- System Simplicity
The rationale was this. If the system doesn’t work or the calls have call quality issues, then nothing else matters. So reliability has to be first priority, as does call quality. Regarding customer service, cloud solutions aren’t like in the premises-based world where if you are not satisfied with one VAR, you can switch to another VAR. This means that with cloud-based telephony, the provider’s customer service reputation has to be stellar. With regard to feature/functionality, once we had reliability, call quality, and customer service in order, then we could look at the various features and functionality that we needed to have in a system. Having come from a complex, disparate premises-based system, this client wanted simplified administration -- a simple user interface, a simple agent interface, and a simple supervisor interface.
Step 4 – Narrow Down Providers
Once the client decided to go the cloud-based route, we agreed to narrow the list of potential vendors to three or four qualified cloud telephony providers.
Cut to last week’s Enterprise Connect Orlando, which gathered more than 200 enterprise communications technology providers all in one spot. It’s always interesting to me to look at the list of event sponsors and exhibitors (sponsors shown below).
Of course, not all of these companies are cloud-based telephony providers, but there certainly are many cloud options to consider here. And clearly, you can’t select vendors for deployment in your enterprise based on their EC19 sponsorship level alone.
So, how did we narrow our client’s list? Well, there are certainly Gartner’s Magic Quadrant reports for UCaaS and CCaaS to reference, as well as various analyst reports, online user ratings, and all kinds of data available on the Internet. But those don’t necessarily tell us which option is the best fit according to factors like the size of the client, the type of industry it’s in, the specific needs of this client, and the decision criteria of this client. But of course, we were able to use some of this data, along with personal experience and additional feedback from my consulting colleagues. With that, we were able to get the list down to about 10 vendors, then after a review with the client, down to four cloud-based telephony vendors.
Step 5 – Issue an RFQ
Once you have your list of potential providers, a good next step is to issue a request for quotation (RFQ), specifying technology products and services needed by the business and requesting pricing information from those vendors in return. This will allow your enterprise to move on to the next step and do as close to an apples-to-apples comparison as possible between your top providers, as I mentioned earlier.
In the case of my client, we decided to keep the RFQ process somewhat informal, but we did issue specifications for pricing and design purposes as well as a questionnaire to clarify features/functionality.
Stay tuned for part two, in which I’ll outline the differences in findings between features and pricing, as well as share the experiences I and my client had in the buying process.