Really Scary Telecoms Stuff? Nah – telephony's just an app
How to pick your hosted solutions
In 2009, I moved to Jersey to become the network and telecoms manager for a multinational company. It was tremendous fun, as I had a variety of kit to play with.
I tended to favour the Mitel 3300 ICP range (still do, actually) that supported about half of our offices, and I did the various engineer courses and exams for the Mitel platform. My two colleagues liked the Cisco Call Managers that ran most of the rest of the world, and were similarly trained and qualified for that platform.
Prior to that I’d been consulting for a much smaller travel company in the north of England – just the one site, initially with only a dozen staff but still only around 50 a few years on when I moved away. Its choice of platform was Inter-Tel (now part of Mitel, of course) because they needed its CTI functionality.
In both the large and small organisations we did the vast majority of configuration and maintenance work ourselves, but those platforms weren't trivial to maintain – particularly when it came to upgrade time. Nine times out of 10, an upgrade went swimmingly, but on that tenth attempt - something weird would happen. So in the interests of risk mitigation we got our support partner to do the more complex stuff: after all, they did several each month rather than our handful per year and so were better schooled in the pitfalls and rescue techniques.
Why do I need this tin on-site?
On top of the maintenance was the cost of keeping the systems alive and up-to-date. That meant support contracts on all the kit, SIP licences for the Mitel kit (silly Mitel - even Cisco didn't charge you an extra licence fee to run up a SIP trunk!), and capital investment in new tin every few years. My account manager at my core telco from back then is now a close friend. In those days, however, relations were strained because I kept banging on at him about how much I wanted a hosted PBX so I could forget about all the hassle of on-premise equipment. After all, they were the local telco. Even if they couldn't give me SIP trunks, they were my ISDN provider – so they could just land the ISDNs in their data centre instead of my office and run a fully managed PBX for me, right? I mean, how hard could it be?
Today the world is different: with SIP trunks growing in popularity you're not even tied down by where your ISDNs can land. The average phone system is no longer built using what those of a certain age would recognise as "telecoms technology": it's actually a computer running an application that just happens to modulate and demodulate the noises humans make while throwing ones and zeroes over an IP network. You can run up your own IP-based PBX with free software on a spare PC, and the most expensive component is the ISDN card you need to buy if you want to connect it to the phone network.
So you genuinely can now consider a hosted PBX, where someone else has the fun of supporting the kit and you simply hook into it.
Selecting a service
When you're picking a hosted PBX service, remember what I said earlier about telephony being just an application on top of computer kit. Therefore, the majority of the things to look for in a hosted PBX are the same as with a normal hosted IT provider.
Data centre security and availability
I wouldn't touch a provider that runs its service from a comms room in its office. Any provider that can afford to protect its in-house comms room adequately against natural and man-made disaster can, frankly, afford to host its services in a proper data centre. Not least because the latter may well be cheaper as the hosting provider benefits from economies of scale on power, cooling, fire suppression and security. If you come across a full-service provider that has a fully fledged data centre and whose hosted PBX service lives in that location then that can be a useful bonus, but it’s not an absolute must-have.
Should you consider a provider that hosts your services on the same box as others? Yes, absolutely you should! Plenty of us use cloud computing installations where our virtual servers run on physical hardware that's shared with dozens or hundreds of other customers, and we don't bat an eyelid. If you have a particularly large installation, then by all means look at suppliers who offer dedicated servers, or perhaps dedicated virtual servers with guaranteed CPU and RAM allocations, but don't just shun a provider because they're using a sensible virtualised platform.
I care about resilience as much as I care about the core hosting provision. Of course, many SMEs will be happy to accept a single, properly hosted installation in return for a cost saving relative to the price of a resilient service. Don't automatically choose a resilient service because you want the gold-star service – but make sure you consider it.
Back when I ran my in-house installation I defined three types of office and then attached minimum service levels to each type for my network and telecoms services. So “major” offices would have dual ISDN (diversely provided if possible) plus dual phone systems running in active/passive mode; they'd also have dual links into the global WAN. “Medium” offices would also have dual phone systems (the hardware was cheap for my Mitel installations – the cost was in the licences, and you didn't have to double up on licences), and single ISDN links because failures were generally in the PBX, not the line.
“Small” offices would have single everything. Consider what you need, and if continuity of service is a big deal, ensure you pick a provider that can provide it, preferably from diverse sites – noting that failover needs to be seamless within the native PBX service (so they need to use multi-geography load balancing). Also verify that in the event of a complete service failure there’s a fallback option to divert calls elsewhere (primarily to mobiles, as that’s the most convenient option in the absence of your primary service).
I remember my first PBX purchase as an IT manager: part of my company had been acquired and was being shifted off into a new office, which I had to equip. As a newbie I diligently sat with the business types and documented their requirements. Collating the results, I ended up with the most boring list in the world.
The features they'd asked for were simply the features they used on the existing phone system. There was no concept of: “It would be really cool if we could ...” I'm not blaming them for it, as I should have pushed them to think of stuff they'd like to do in an ideal world and to step outside the confines of history.
At the risk of banging on again about telephony being an application, that's exactly what it is. It's a program running on an IP network. So let your imagination run wild regarding what other apps and services you can make it talk to, whether you can link it with (say) your corporate Active Directory, and the like. Yes, you'll want a lot of dull old stuff as well, but don't be boring with the feature wish-list.
Alongside the features you want to have and the systems you want the PBX to talk to, you need to understand how the PBX talks to those systems. You're probably moving from an internal PBX that sits on the same LAN as the things it communicates with, but now you're shifting the PBX outside the network and accessing it remotely. In many cases this will be via the internet; if the hosted PBX provider is also an internet provider they may be able to provide a service with Quality of Service (QoS) guarantees to ensure call quality over the voice component of the traffic flowing through the link. Or you might have some kind of point-to-point link if the hosted PBX provider is sufficiently local.
Connecting to on-premise systems is no longer trivial – so you need to figure out how you're going to do it. Maybe you'll move some of them out of your LAN to a cloud presentation. Maybe you'll pick a provider that offers VPN connectivity or a private APN for linking between its world and your in-house systems. Whatever the case, list those integration requirements and be meticulous about confirming for each one whether: (a) you can integrate with it; or (b) you're happy not to have the integration any more.
Phone numbers and the PSTN
And perhaps one of the hardest features you'll ask for is connectivity with the public phone network. Ever signed up for a normal phone number on Skype, for instance? Easy, isn't it? Except that you probably can't get a phone number in your own dialling code. I live in Jersey but my Skype phone number is actually a Nottingham one; in my case it doesn't matter (and I picked Notty only because I was born just down the road!), but proper businesses will usually care more than me.
If you’re UK-based and you have existing DDI numbers on the phone lines into your in-house PBX, though, there’s some good news. If you were shifting to another provider or even moving office whilst staying with the same provider, you couldn’t be sure to be able to take your numbers with you: Ofcom hasn’t obliged the providers to guarantee this because it’s sometimes hard to do in a traditional telco world. If you’re moving from a traditional telco service onto a SIP-based service for a hosted PBX, though, then your provider has to let you port your numbers to the new service – so as long as your new provider supports inward number porting, you can keep your numbers.
Oh, and remember that phone numbers cost money, though unless you’re going for thousands it’s unlikely to break the bank. If you’re still in the old school of having calls come to your main number and be forwarded by a receptionist, get yourself into the 21st century and be sure to go for direct-dial (DDI) numbers for every user: telephony is entirely mobile these days so you can’t rely on central numbers.
And while you're at it, understand the charging model of the hosted PBX provider. The general model these days is to go with “bundles” that include call quotas by location, with overage charges for going over the limit. This is nothing you’re not already used to with the average mobile package, of course, so although it’s perhaps a little unfamiliar in a landline setup, it’s no longer an alien concept in general.
You need to monitor the performance and cost of your hosted PBX service, so be sure to list your requirements regarding what you want to be able to see. You should be able to dip in at will and get cost summaries, performance information, call itemisations, audit logs of changes, and so on. When you have a hosted PBX you'll find the dashboard invaluable for the first few months as it'll show you how it's behaving, what people are using it for, and where you can (for instance) provide users with information or training to make their lives easier and improve productivity.
Cliché alert. Although it's just an app, people expect a dial tone when they pick up the handset. Okay, these days the concept of a dial-tone is largely a thing of the past (you don't have them on mobiles, after all) but they still expect telephony to work when they want to make a call. So consider whether you need support outside the provider's normal working hours (which might simply mean nothing more complex than having staff a few time zones away) and if you do, go for a provider that offers this. I've come across SaaS service providers – general ones, not particularly hosted PBX providers – who provide a supposedly “24x7” support service but don't answer the phone after 6pm (their 24x7 functions only react to alerts generated by their monitoring systems).
Hosted PBXs: get in there and do it
As I said, I've been banging on about wanting hosted PBXs for years, so it's no surprise that I think they're a great idea. This doesn't mean that choosing and implementing one is a doddle, though, as there's loads to think about.
But the task is different today with hosted PBXs when compared with the same exercise for on-premise phone systems. The old world had a moderate number of considerations which were primarily concerned with Really Scary Telecoms Stuff running on Dead Complicated Telephony Platforms, which made the process of choosing, installing and maintaining an in-house PBX a relatively complicated job. Today you've got a lot more things to consider, but they're all actually pretty easy – and are understood by someone who knows about computers and networks but hasn't spent a fortnight in a training room configuring DASS2 and Q.931 trunks.
They're easy, they're as robust as you choose them to be, and the sky's the limit feature-wise. And you can probably try before you buy if you talk nicely to the vendor. So go and try one out.