No Jitter is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

The Cloud: Front End Alignment

In a recent post, Who Moves To the Cloud?, I identified three traits that I found attractive in finding a hosted voice services provider.

These three traits:

* Make it easy to do business
* Provide an interface that's easy to use and understand
* Ongoing customer engagement

These are what enticed me to consider and then move some of our voice services to the cloud. While we haven't gone live by porting our numbers, we are using active numbers in a live system. Fortunately, I've been given free rein with some boundaries to test, evaluate and demonstrate these services.

My ultimate goal is to move Voice Mail/Automated Attendant (VM/AA) components to the cloud. There are two methodologies in accomplishing this task. First is the front-end task of placing the Automated Attendant (AA) function in the cloud. The back-end task of Voice Mail (VM) is the other.

My reasoning for doing this started with our internal energy efficiency efforts. We can reduce our monthly electric usage by 48 Kilowatt-Hours. In turn, this reduces rack space and cooling. Our ultimate goal is to install an alternative energy power plant in hopes of becoming energy neutral, or producing the same amount of energy that we consume.

This was the fancy of striving for energy efficiency. But there are also key benefits for moving VM/AA components to the cloud, and good reasons to do it. I am only going to address what we have tested and proven between cloud services and premise-based services.

Key Benefits
Traffic Efficiency--Businesses that front-end their telephone system with the AA in lieu of live operators can use a key metric to quickly decide whether moving the AA to the cloud is worth it for them. Abandoned calls is that key metric.

Callers landing on an AA and then disconnecting have used your line, trunk or link (bandwidth) and utilized those system resources with premise-based solutions. Once they land and then disconnect for whatever reason, your resources have been used. It is not uncommon to find a 30-50% call abandonment rate. This is a significant indicator of wasted resources. Those same callers may have caused peak traffic conditions for other customers, such as busies or long queue times. Getting too many customer complaints can drive companies to install more lines and infrastructure to handle more calls. Moving the AA to the cloud keeps those same abandonments in the cloud and not my local resources (lines, trunks, link bandwidth) and PBX resources.

Improved Management--Changing call flows on the fly to put calls where we want them to go, and doing so via a web interface from any location. We need not call the provider; we simply drag and drop the changes we want, using the web interface from any location.

Reduced Risk--The key component of a VM/AA system is the conventional hard drive, and these drives will fail. PBXs with in-skin VM/AA that utilize a single hard drive also risk failure. Some systems have RAID configurations for redundancy and/or recovery. Others virtualize. Still, the onsite hard drive remains a key single point of failure.

I think the odds favor the hosted solution by using their redundancy and infrastructure. You could argue that this is a perceived risk, but when it comes to restoration of services or disaster recovery, I don't think premise solutions have the same vitality as the hosted.

In the above screen shot, our AA is configured using an off premise extension 300: a SIP phone. This extension is a Panasonic KX-UT670. Callers that want to discuss hosted services press 1 and are routed to extension 300, and if the user at extension 300 doesn't answer, calls then forward to voice mail (VM) on the hosted provider system.

Other features include simultaneous ringing of other numbers, call forwarding or overflow to other extensions, different routing based on time/day/holiday. Callers that want to leave a message press 2 and are routed to a mailbox. Then, callers that want to reach Telecomworx dial 3 and are routed to the SIP trunks connected to our PBX and they ring on a ring group.

Again, other features are available. The last option we set up was to create a conference room that allows callers to conference with us; again what starts in the cloud, stays in the cloud. We aren't using up our local resources.

Now, the really cool feature is the integration of the two dial plans. The hosted solution routes 1xx and 2xx calls over the SIP trunks to our PBX as Intercom or extension-to-extension dialing. We mapped out 3xx for off-premise extensions so when any of our PBX users dial 3xx their calls route over the SIP trunks to the hosted PBX and ring the appropriate station.

Why Move AA to the cloud?
Earlier I stated there are good reasons.

We have customers on legacy systems as old as 20 years. AA failures aren't always easily restored and done cost effectively.

Customers that want to upgrade can easily leverage a hosted solution like this and do so economically and easily while preserving their existing investment.

Consolidation is a huge reason for multi-sites to reduce their local resources and costs and leverage cloud services. Let the cloud do the aggregation of services and then manage the call flow to each location.

Follow Matt Brunk on Twitter and Google+!
@telecomworx
Matt Brunk on Google+