The Word That Stopped Working
Consider two Australian businesses in 2016, both with fifteen staff, both of whom would have told you they were on VoIP.
| Business A | Business B | |
|---|---|---|
| Transport | SIP trunks — packets | SIP — packets |
| Where the call control runs | A box in the comms cupboard | A provider's platform |
| Adding a staff member | Book a technician, wait, pay an hourly rate | A field in a portal, ninety seconds |
| When the building loses power | Inbound calls stop | Calls keep arriving on mobiles and laptops |
| Concurrent call limit | A specific number somebody knows | Nobody knows, because nobody provisioned it |
| What happens in three years | The hardware leaves vendor support | Nothing |
| What both of them said | "We're on VoIP" — and both were correct | |
Every meaningful property of a phone system differs across that table, and the vocabulary in general use could not see any of it. That is not a pedantic complaint. It is a commercial one. Business A was routinely told it had modernised, believed it, and stopped planning for a failure mode that was still sitting in its cupboard on a single power supply.
A word that describes two things with opposite risk profiles is not a shorthand. It is a hiding place.
— the reason we bothered
Why Hosted PBX Was Not the Right Word Either
The obvious objection is that the industry already had a term for business B: hosted PBX. It was closer, and we considered it, and it was wrong for a specific reason worth explaining.
Hosted PBX describes a location change to an unchanged thing. It says: you know that private branch exchange you used to have in your cupboard? It is in somebody else's rack now. That framing was accurate for a lot of early products, which genuinely were traditional exchange software lifted into a data centre, one virtual instance per customer, with the same architecture and most of the same limitations.
But it undersold three changes that were not location changes at all.
Capacity stopped being provisioned
A hosted exchange still had a configured concurrent call limit. A genuinely multi-tenant elastic platform does not — capacity scales on demand, so the busiest hour of your year is not something you buy and hold all year.
The device stopped mattering
Not "you can also have a softphone" as an option bolted onto a desk-phone product, but an architecture where a laptop, a mobile, a browser and a desk phone are the same extension with equal standing. App-first rather than app-also.
Improvement stopped being a project
A hosted instance still had a version, and versions get upgraded in scheduled outages. A continuously deployed platform does not have a version you run, which is why nobody on one can tell you what release they are on.
So the phrase we needed had to name the delivery model — the whole arrangement of where the software lives, how it scales, how it is billed and how it improves — rather than either the protocol underneath it or the box it replaced. Hence Voice over Cloud, deliberately parallel in construction to Voice over IP so the contrast was audible, and deliberately different in what it pointed at.
How We Got Here: Copper
The word was needed because of a hundred and forty years of accumulated assumptions. It is worth walking the sequence, because most of those assumptions are still operating inside Australian businesses today.
From the 1880s to the 2000s, voice was an electrical signal on a pair of copper wires. The properties that mattered:
| Property | Consequence still visible today |
|---|---|
| One line carried exactly one call | Businesses learned that capacity is a physical thing you buy and own. Many still size for peak and pay all year. |
| Call control lived in the carrier's exchange | You ordered features from a list. The expectation that a phone system is something done to you rather than by you starts here. |
| Every feature was metered and billed separately | Call waiting, forwarding and voicemail as individual line items. The industry's instinct to unbundle and re-bill features was learned in this era and never fully unlearned. |
| The line was powered from the exchange | A corded phone worked in a blackout. This is the one genuine advantage no later generation replicates for free, and it deserves to be conceded rather than argued away. |
How We Got Here: Channels and the Box
From the late 1980s, digital services replaced lines with channels and the exchange moved into the building. This was real progress and it created the specific dependency that the cloud model later dissolved.
- Channels replaced lines. More efficient, more manageable — and still a fixed number, which mattered more than anyone realised at the time.
- Call control moved on-site. For the first time a business could design its own call flow instead of ordering features. Genuine autonomy, purchased with genuine responsibility for a physical asset.
- Capacity became a hard ceiling. On a ten-channel service, the eleventh call did not queue or degrade or cost extra. It failed. Businesses learned to provision for their worst hour and carry that cost every month of the year.
- Every change became a site visit. New starter, moved desk, changed hunt group, different after-hours greeting: a booking, a technician, an hourly rate, a wait. The cost of change rose high enough that businesses simply stopped changing things.
The assumption that outlived the technology
That last point did the most lasting damage, and it was cultural rather than technical. An entire generation of Australian businesses learned that the phone system is a fixed asset you do not touch. You still hear it in the way people describe their own call flows — apologetically, as something inherited. When a business tells us it cannot change how calls are routed, the constraint is almost never technical any more. It is a habit formed in an era that has ended.
How We Got Here: Packets, and the Half-Migration
From the 2000s, voice became data. SIP trunks replaced digital circuits, the bill usually fell, and — critically — the box very often stayed exactly where it was.
This is the half-migration, and it is where the vocabulary problem was born. A business that put SIP trunks into its existing exchange in 2014 changed its transport and nothing else. The single point of failure stayed in the cupboard. Changes still needed the one person who understood that box. Capacity moved from a channel count to a bandwidth constraint, which is more elastic without being elastic.
And one entirely new burden arrived that had existed in neither previous era.
Quality became the customer's problem
On copper and digital circuits, call quality was the carrier's job and effectively a solved problem — the network was built for voice and carried nothing else. Once voice became packets on a general-purpose internet service, quality became a function of your connection, your router, your local network and above all your upload headroom. When calls broke up, the carrier could truthfully report the service was within specification, because it was. That is the origin of every jitter and one-way-audio conversation in an Australian office since about 2008, and it is why upload capacity matters far more than the download figure businesses actually shop on.
What We Meant by a Delivery Model
"Delivery model" sounds like consultant vocabulary, so here is the concrete version. A transport answers one question. A delivery model answers seven.
| Question | VoIP answers it? | Voice over Cloud answers it |
|---|---|---|
| How does the voice travel? | Yes — as packets | As packets, same as VoIP |
| Where does the call control software run? | No | In the provider's platform. Nothing on site but endpoints. |
| What is the concurrent call limit? | No | Elastic — it is not a number you provision or pay for. |
| What counts as an extension? | No | Any device. Desk phone, laptop, mobile, browser — equal standing. |
| How is it billed? | No | Per user per month. Cost tracks headcount, not infrastructure. |
| How does it improve? | No | Continuously, without a scheduled outage or a version migration. |
| What happens when a site fails? | No | Calls reroute, because the number never lived at the site. |
Six of those seven questions are the ones a business actually cares about, and the transport protocol answers none of them. That asymmetry is the whole argument for having a second word.
The Definition, Stated Precisely
Voice over Cloud is a business phone system delivered entirely as a service. The call control software resides in the provider's data centre rather than on the customer's premises, and phones and applications connect to it over the internet. Capacity is elastic rather than provisioned. Any device can be an extension. Billing is per user, per month. Platform capability improves continuously without customer-side upgrade projects, and platform intelligence — transcription, summarisation, AI agents — is native rather than integrated, because the audio is already inside the platform.
Note what is not in that definition: any brand, any protocol version, any particular feature list. A definition tied to a feature list expires. This one is architectural, which is why it has held up for nearly a decade.
The Four-Question Test
Definitions are for arguments. Tests are for buying. Ask a supplier these four and count the answers.
1. Is there hardware on my site whose failure stops the phones?
The answer that means it: no, only endpoints — handsets and computers — and losing one costs you one extension. The answer that does not: anything involving a box, an appliance, a gateway that does call control, or a server. This single question resolves most cases.
2. How long does it take me to add a user, myself?
The answer that means it: minutes, in a portal, by you. The answer that does not: raise a ticket, book a technician, allow two business days, or "we do that for you" offered as a benefit rather than an option.
3. What is my concurrent call limit?
The answer that means it: there is not one you need to manage. The answer that does not: a specific number — which is a perfectly honest answer, and it tells you the capacity is provisioned rather than elastic.
4. Are transcripts, summaries and AI agents native, or a second vendor?
The answer that means it: native, in the platform, no separate contract or audio export. The answer that does not: an integration with a partner, which means your call audio leaves and a second data-handling question opens.
How to score it
Four good answers and the phrase is being used correctly. Two or three and you are looking at a hosted exchange, which may well be the right purchase — plenty of businesses are well served by one — but you should buy it knowing what it is. One or none and somebody has relabelled a SIP trunk. None of these questions requires technical knowledge to ask, and all four are hard to answer misleadingly without lying outright.
Three Ways the Term Gets Misused
A term that spreads gets stretched. These are the three stretches we see most, in ascending order of how much they cost the customer.
1. Applied to a SIP trunk
The customer's exchange is untouched; only the circuits changed. This is straightforwardly inaccurate and it is the version that hurts most, because the business stops planning for a single point of failure it still has.
2. Applied to a lifted-and-shifted instance
A traditional exchange running as one virtual machine per customer in a data centre. Genuinely off-premises, genuinely not elastic, with a version and a maintenance window. Closer to honest, still not the thing.
3. Applied to a resold platform with a logo on it
The hardest to detect and the most consequential when something goes wrong, because nobody in the chain you can reach actually operates anything. The test question is not about features — it is about who answers at 3am and what they can change.
That third case has become the important one, and it is why we say we own and operate our own network rather than reselling somebody else's. It is a claim about accountability, not about superiority: when the platform and the network belong to the same company, there is no gap between two suppliers for a fault to fall into and no argument for a customer to referee.
Elastic Capacity: The Part Nobody Believes Until It Happens
Of everything in the definition, elastic capacity is the one businesses discount hardest, because a hundred and forty years taught them that capacity is a thing you buy.
| Era | Concurrent calls | Cost of being ready for your worst hour |
|---|---|---|
| Copper | One per line | Permanent line rental for a peak that occurs twice a year |
| Digital channels | A fixed number | Channels billed monthly whether used or not |
| Packets into your own box | Bounded by upload bandwidth | Lower, but quality degrades before capacity does — which is worse, because it is invisible |
| Voice over Cloud | Elastic, on demand | Nothing. You are not provisioning it. |
For a business with genuinely spiky volume — a clinic at nine on Monday, a venue at five on Friday, an accountant in July, a retailer during a promotion — that single property is worth more than any feature in the platform. The busy hour stops being an event you survive and becomes an hour like any other. Businesses that have lived with a hard channel ceiling for a decade tend not to believe this until the first Monday it does not happen to them.
Why the AI Argument Is a Location Argument
The most common current question about cloud phone systems is about AI, and it is usually framed as a feature comparison. It is not. It is an architecture question, and the architecture decides it.
Transcription, call summaries, quality scoring and AI agents all require one thing: the call audio, in a place where software can work on it. A platform that already holds the audio can do those things as ordinary functions. A system on a customer's premises can only do them by sending the audio somewhere else — which means a second vendor, an integration to maintain, a data-handling question to answer, and one more supplier in the blame gap when it stops working.
The practical consequence
This is why AI capability arrived across cloud platforms roughly all at once and has arrived on premises-based systems slowly, unevenly and with an asterisk. It is not that cloud vendors are cleverer. It is that the audio was already in the right place. And it is also why the next question worth asking a cloud provider is not whether they have AI, but whose infrastructure their AI runs on and what happens to your call audio when it gets there — which is a different article and a more important one than the feature list.
What the Copper Retirement Forces
All of this would be academic if the earlier eras were stable. They are not. Australia's copper network is being progressively decommissioned and the services riding on it are retiring with it, which removes the option most businesses were quietly exercising: doing nothing.
Two paths remain, and the seat count largely decides.
| Path | What it is | Where it makes sense |
|---|---|---|
| Keep the box, change its circuits | SIP trunks into the existing exchange | A recent, supported, well-understood system with real life left, heavy customisation that works, or a business that genuinely cannot change anything this year |
| Skip a hardware generation | Move directly to a platform and retire the box | Almost everything else, and every case where remote work, elastic capacity or native AI matters |
Below roughly fifty seats, keeping an exchange alive on SIP trunks is an expensive way to defer the decision rather than a way to avoid it — the hardware, the support contract and the specialist knowledge all have to be funded across too few users. Above roughly one hundred seats, owning the platform can start to win again where there is genuine in-house expertise and stable requirements. Between the two it is a real judgement call that turns on capability rather than technology. Any provider who gives you an answer without asking your seat count is not doing the arithmetic.
Deciding, Without the Vocabulary Getting in the Way
The point of naming something is to make it easier to buy, not harder. So here is the short version to take into a supplier conversation.
- Establish which era you are actually in by asking whether a box failing would stop the phones. Do not accept the description you were given at signing — check.
- Separate the two decisions. Transport and delivery model are different questions. A supplier who conflates them is either confused or hoping you are.
- Run the four questions. Hardware on site, time to add a user, concurrent limit, native intelligence. Count the answers.
- Ask who operates the platform and the network. Not who brands them. This is the question that determines what happens on a bad night.
- Deal with the forgotten analogue services first. Lift phones, fire panel diallers, alarm diallers, EFTPOS backup lines. These are what actually catch businesses out at a copper cutover, not the desk phones.
The summary
We coined Voice over Cloud in 2017 because VoIP had stopped distinguishing anything useful and hosted PBX undersold what had changed. VoIP is how voice travels; Voice over Cloud is where the system lives, how it scales, how it is billed and how it improves. Four questions separate the real thing from a relabel, and the first one — is there hardware on site whose failure stops the phones — does most of the work. Copper retirement means the earlier eras are not a resting place. And if a supplier uses our phrase, that is fine by us: we would just rather they meant it.
Related reading: our earlier walk through the same evolution, what a cloud phone system is, hosted versus on-premises with the numbers, and why we operate our own network for the third misuse case in detail.
Frequently Asked Questions
Who came up with the term Voice over Cloud?
VOCPhone coined it in 2017, and it was a response to a genuine vocabulary problem rather than a branding exercise. By the middle of the 2010s the word VoIP had been in general use for more than a decade and had quietly stopped distinguishing anything useful, because it described two situations with almost nothing in common: a business that had replaced its digital circuits with SIP trunks while leaving its exchange in the comms cupboard, and a business whose entire call control ran in a provider's platform with nothing on site but handsets and laptops. Both could accurately say they were on VoIP. Only one of them could add a user in ninety seconds, keep answering calls when the building lost power, or hand the same extension to a mobile. Customers were buying the first while being told they had the second, and discovering the difference during outages. The phrase was built deliberately parallel to Voice over IP so the contrast would be audible, while pointing at something different — the delivery model rather than the transport protocol. Another Australian provider adopted the term in 2019, which moved it from one company's product language into wider industry use, and it is now used broadly enough that we spend more time explaining what we meant by it than defending having invented it.
What is the difference between Voice over Cloud and VoIP?
VoIP answers one question and Voice over Cloud answers seven, which is the whole reason a second term was necessary. VoIP tells you how the voice travels — as data packets across an IP network rather than as an electrical signal on copper or a channel on a digital circuit. It tells you nothing about where the call control software runs, what your concurrent call limit is, what counts as an extension, how you are billed, how the system improves over time, or what happens when your site fails. Voice over Cloud answers all of those: the software resides in the provider's data centre with nothing on site but endpoints; capacity is elastic rather than provisioned, so there is no number to buy and hold; any device is an extension with equal standing, whether desk phone, laptop, mobile or browser; billing is per user per month so cost tracks headcount rather than infrastructure; capability improves continuously without scheduled outages or version migrations; and calls reroute when a site fails because the number never lived at the site. Six of those seven questions are the ones a business actually cares about, and the transport protocol answers none of them. You can have VoIP without cloud — many Australian businesses do — and that configuration keeps its single point of failure in the cupboard.
Is hosted PBX the same as Voice over Cloud?
They overlap but they are not the same, and the difference is worth understanding before you buy either. Hosted PBX describes a location change to an unchanged thing: the private branch exchange that used to sit in your cupboard now sits in somebody else's rack. That description was accurate for a lot of early products, which really were traditional exchange software lifted into a data centre as one virtual instance per customer, carrying the same architecture and most of the same limitations. Three things it undersells are not location changes at all. First, a hosted exchange typically still has a configured concurrent call limit, while an elastic multi-tenant platform does not, so you are not buying capacity for your worst hour and carrying it all year. Second, a hosted product is often desk-phone-first with a softphone bolted on as an option, whereas an app-first architecture treats a laptop, a mobile, a browser and a desk phone as the same extension with equal standing. Third, a hosted instance still has a version, and versions get upgraded in scheduled maintenance windows, whereas a continuously deployed platform has no version you run. A hosted PBX can be exactly the right purchase for some businesses. You should just buy it knowing which of the two you are getting.
How can I test whether a provider really offers Voice over Cloud?
Ask four questions and count the answers — none of them requires technical knowledge and all four are hard to answer misleadingly without lying outright. First: is there hardware on my site whose failure would stop the phones? The answer that means it is no, only endpoints, so losing one costs you one extension; anything involving a box, appliance, gateway doing call control or server means the call control has not actually moved. Second: how long does it take me to add a user, myself? Minutes in a portal, done by you, is the answer that means it; raise a ticket, book a technician, allow two business days, or we do that for you offered as a benefit rather than an option, is the answer that does not. Third: what is my concurrent call limit? The answer that means it is that there is not one you need to manage; a specific number is a perfectly honest answer that tells you capacity is provisioned rather than elastic. Fourth: are transcripts, summaries and AI agents native, or a second vendor? Native with no separate contract or audio export is the answer that means it. Four good answers and the phrase is being used correctly. Two or three and you are looking at a hosted exchange. One or none and somebody has relabelled a SIP trunk.
Why did call quality become the customer's problem when voice moved to packets?
Because responsibility moved with the technology and nobody announced it. On copper and on digital circuits, call quality was the carrier's job and was effectively a solved problem: the network was purpose-built for voice and carried nothing else, so the path from one handset to another was engineered end to end for that single purpose. Once voice became packets travelling over a general-purpose internet connection, quality became a function of things the customer owns — your internet service, your router, your local network configuration, and above all your upload headroom. When calls break up, a carrier can truthfully report that the service is performing within specification, because it is; the problem lives in the gap between what the specification guarantees and what real-time voice actually needs. That is the origin of every jitter, latency and one-way-audio conversation that has happened in an Australian office since roughly 2008. The practical implication is that businesses shop on the wrong number: the download figure is largely decorative for voice, while upload determines what happens when several people are on calls and somebody starts a video meeting. It is also the strongest argument for taking the network and the platform from the same provider, since two separate suppliers can each correctly certify their own half while the fault sits between them.
Does moving to a cloud phone system mean I lose the ability to call during a power cut?
You lose the specific mechanism that copper provided and you gain a better outcome in most real failures, and both halves of that sentence deserve to be said. The old advantage was genuine: an analogue line was powered from the exchange, so a corded handset kept working when the building lost power, and no later generation replicates that for free. What a cloud platform offers instead is redundancy by different means. Your number does not live at your site, so when the building loses power or internet the calls do not arrive at a dead box — they reroute, to mobiles running the same extension, to another site, to a queue, to an AI agent that can take a message and send it as a text, or to whatever rule you set. In practice that covers more failure modes than exchange power ever did, because it also handles an internet outage, a flood in the comms room, a road closure that stops staff reaching the office and a site you have simply closed for the day. The honest caveat is that it depends on mobile coverage or another connection existing somewhere, so the right approach is to decide in advance what should happen when a site goes dark and configure it, rather than assuming a default will be sensible.
The copper network is being retired — what are my actual options?
Two, and your seat count largely decides between them. The first is to keep your existing exchange and replace its circuits with SIP trunks, which preserves the call flow, the handsets and the muscle memory, and makes sense where the system is recent, supported and well understood with real life left in it, where customisation would be expensive to reproduce, or where the business genuinely cannot absorb a change this year. What it does not remove is the single point of failure, the technician visit for every change, or the end-of-support clock, so you are buying time at a price and will face the same decision in about three years with an older asset. The second is to skip a hardware generation and move directly to a platform, retiring the box. Below roughly fifty seats the first path is an expensive way to defer the decision rather than avoid it, because the hardware, support contract and specialist knowledge have to be funded across too few users. Above roughly one hundred seats, owning the platform can start to win again where there is real in-house expertise and stable requirements. Between the two it is a genuine judgement call about capability, not technology. Whichever you choose, deal first with the forgotten analogue services — lift phones, fire panel and alarm diallers, EFTPOS backup lines — because those are what actually catch businesses out at a cutover.
