Cloud PBX & VoIP

Most Mauritian offices still run a physical PBX: a box in a cupboard, wired to a fixed number of lines, configured by whoever installed it and rarely touched since. It works until you need to change something. Adding an extension means a site visit. Moving office means re-cabling. When the person who knew the system leaves, the configuration becomes folklore.

A cloud PBX moves that box into software. Extensions, transfers, voicemail, IVR menus and call queues all still exist — but they are configuration rather than hardware, which means they can be changed the same day rather than scheduled around an engineer's availability. Staff keep their extension whether they are at a desk, at home, or on a mobile.

The practical difference is not the feature list. Both systems can route a call. The difference is what happens when the business changes shape — a new branch, ten seasonal staff, a department that suddenly needs a queue — and how long the answer takes.

Voice over IP is unforgiving in a way that email is not. A web page that loads 200 milliseconds late is invisible. A voice packet that arrives 200 milliseconds late is audible, and a caller hears it as the other person breaking up.

This is where cloud PBX deployments actually fail, and it is almost never the phone system's fault. It is a network that treats a voice call and a large file upload as equally urgent. Someone starts a backup, or a video call, and every conversation in the building degrades at once.

We configure Quality of Service so voice traffic is prioritised over ordinary data on your network. That is a configuration job on your switches and router, not something the PBX vendor can do from their end — which is why buying a cloud PBX as a pure subscription, with nobody looking at the network it runs over, so often disappoints.

This is the fair objection to cloud telephony, and it deserves a straight answer rather than a reassurance. If your only internet connection fails, an internet-based phone system fails with it. Anyone who tells you otherwise is selling.

The answer is not to pretend the risk away, it is to design around it. Calls can fail over to mobile numbers so the business stays reachable while the line is down. A second connection removes the single point of failure entirely. Which of those is worth doing depends on what an hour of unreachable phones actually costs you — a question worth answering before the outage rather than during it.

It is the same reasoning we apply to backup and disaster recovery: decide what downtime costs, then buy the amount of resilience that matches. Not more, and not less.

We start by looking at what you have — how many extensions are really in use, how calls currently get routed, and what the network underneath looks like. That review usually turns up extensions nobody has answered in a year and a routing rule that has been quietly sending calls to a desk that no longer exists.

Then we design the call flow before touching anything: who answers first, what happens when they do not, where a call goes after hours. Most bad phone systems are not badly built, they are badly decided — the technology faithfully implements a routing plan nobody ever agreed.

Deployment is staged rather than flipped overnight, so a problem affects one department instead of the whole company. Afterwards, changes are ours to make and yours to request: you talk to the engineer who configured it, not a call centre.