The case for moving business telephony to IP is usually made on cost, and the cost case is real. But it is not the most interesting part, and leading with it sets up a disappointment when the first month’s invoice is lower than expected but the call quality is worse.
Here is what actually changes, including the parts that get harder.
What gets cheaper
- Line rental. Channels are provisioned in software rather than as physical lines, so you stop paying for capacity you keep for peak.
- Internal calls. Calls between sites traverse your own network. A Cairo to Alexandria internal call stops being a call at all.
- Moves and changes. Adding an extension is a configuration change, not an engineer visit and a patch panel change.
- Hardware refresh. No proprietary PBX chassis to replace at end of life.
What gets better
The feature set is where the day-to-day difference shows up. Voicemail arriving as email, call recording without a separate appliance, hunt groups and IVR menus that a manager can adjust without raising a ticket, presence and softphone clients so a person is reachable on one number wherever they are, and call reporting that tells you how many calls were abandoned and when.
For a business with staff who move between offices or work partly from home, the last two change how the phone system is used, not just what it costs.
What gets harder — and this is the part to plan for
Voice over IP is unforgiving of a network that was designed only for data. Three things matter:
- Quality of service. Voice packets must be prioritised over file transfers and backups. Without QoS the symptom is choppy audio during the working day and perfect audio when you test it at 7pm.
- Jitter and latency, not bandwidth. A voice call needs very little bandwidth. What it needs is consistent delivery. A link with plenty of headroom but variable latency will sound worse than a slower, steadier one.
- Power. Desk phones draw power over Ethernet. If the switch loses power, so does every phone in the building. A traditional PBX with analogue handsets often survived a short outage; an IP system needs the switches and the internet link on UPS to do the same.
Do the network survey first
We will not deploy IP telephony onto a network we have not surveyed, because the failure mode is reputational rather than technical — the calls are bad, and the phone system gets the blame even when the cause is a saturated uplink. The survey establishes whether QoS can be applied end to end, whether the switching supports PoE with enough budget, and what the real latency and jitter look like across the working day.
If the network is not ready, the honest answer is to fix the network first and move the phones second. That is a longer project and a better outcome.
Numbers and continuity
Two practical points that catch people out. Number portability takes time and paperwork, and it is the item most likely to delay a cutover — start it early. And decide in advance what happens to inbound calls if the internet link fails: divert to mobiles, a secondary link, or a recorded message. Choose deliberately, because the default is usually silence.
We survey the network first, then design the telephony to run on it. VoIP →
