The short version
A cloud phone system is only as good as the network it runs across. The platform is somebody else’s problem to keep running; the path between the handset and the internet is yours.
Checking these before cutover costs little. Discovering them afterwards means diagnosing a live phone system while staff are trying to use it.
| Check | What good looks like |
|---|---|
| Upload capacity | Headroom for peak concurrent calls plus normal business traffic |
| Consistency | Low jitter and negligible packet loss under load |
| Prioritisation | Voice marked and queued ahead of bulk traffic |
| Gateway | Business device, predictable session handling, no SIP rewriting |
| Handset connectivity | Cabled where possible, PoE available |
| Wireless | Designed for voice where softphones are used |
| Resilience | A plan for what happens when the connection fails |
Upload is the number that matters
Business connections are sold on download speed, but every person speaking is sending audio out. On a service where upload is much smaller than download, the upstream path fills long before anyone notices a download problem.
Work out realistic peak concurrent calls — not headcount, and not licence count, but how many conversations genuinely happen at once. Then add the video meetings, cloud backups and file uploads that share the connection.
If the answer is tight, the connection is the first thing to fix, and it has lead time. How much business internet do you actually need covers sizing, and NBN business fibre vs Enterprise Ethernet vs 5G covers the options.
Consistency beats speed
Voice tolerates a small, steady stream far better than a large, erratic one. The measurements that predict call quality are jitter, latency and packet loss, not megabits.
A connection that speed-tests well but suffers loss under load will produce choppy audio at exactly the times the business is busiest. Test during business hours, under real load, rather than at 7am when the office is empty.
Prioritise voice, and separate it
If voice shares the connection with everything else and nothing distinguishes it, it will lose whenever the link is busy.
Two changes address this. Quality of service marks voice so the gateway sends it ahead of bulk traffic — most congestion happens in your own upload queue, so local prioritisation alone helps considerably. And placing voice on its own VLAN keeps it away from guest devices and backup jobs, while making the traffic easy to identify when something needs diagnosing.
The gateway is a common failure point
Consumer routers cause a disproportionate share of cloud voice problems. The specific culprit is usually a SIP handling or ALG feature that rewrites voice traffic in ways the platform does not expect, producing one-way audio or calls that drop after a predictable interval.
A business gateway should handle call sessions predictably, keep them open for the length of a call, support prioritisation, and be documented so its configuration is known. If the site is also getting failover, the gateway needs to switch paths automatically rather than requiring someone to intervene — covered in business internet failover and redundancy.
Cable the handsets
Desk phones should be cabled. It removes roaming, interference and airtime contention from a service that depends on consistency.
That has implications worth checking before go-live: is there a cable to each desk that will have a handset, does it test, and is there a switch port available. Where new runs are needed, that is cabling work with its own lead time, and in Australia fixed cabling must be installed by an ACMA registered cabler.
Handsets drawing PoE also add to the switch power budget, alongside access points and cameras. A switch comfortably powering today’s devices may not accommodate thirty handsets as well.
Wireless still matters
Even with cabled desk phones, softphones on laptops and mobile apps will use Wi-Fi. If those are part of the deployment, the wireless design needs to support voice: overlapping coverage without excessive co-channel interference, sensible transmit power so devices roam rather than clinging to a distant access point, and separation from guest and bulk traffic.
If the wireless network is already a source of complaints, resolve that before adding voice to it. Why is our office Wi-Fi slow works through the diagnosis.
Plan for the connection failing
Once phones are cloud-based, the internet service is the phone line. A single connection with no backup means an outage takes voice with it.
Decide before go-live what should happen: a second connection with automatic failover, or platform-side redirection of inbound calls to mobiles when the site is unreachable. Most platforms can do the latter, but it must be configured in advance, not during the outage.
A pre-cutover checklist
- Measure upload capacity against realistic peak concurrent calls
- Test jitter and loss during business hours, under load
- Confirm voice can be prioritised on the gateway
- Replace or reconfigure any gateway performing SIP rewriting
- Verify a tested cable and switch port for every handset position
- Check PoE budget across handsets, access points and cameras
- Confirm the wireless network is fit for softphones
- Decide and configure the failure plan
- Verify the registered service address for emergency calling
Helpful starting points
If the connection is the weak point, start with business internet. If the local network needs work first, Wi-Fi and network solutions covers switching, VLANs and coverage. For the rollout as a whole, see what happens during an 8x8 implementation.