The most common business phone arrangement in Australia is a mobile in a pocket, and the second most common is a business number diverted to that same mobile. Both work, in the narrow sense that calls arrive. Both also produce the same four problems, and the problems are so familiar that most people have stopped noticing they are problems at all. Your personal number goes out on every call you make, so customers store it and ring it directly — at 6am on a Sunday, forever, and there is no way to take it back. You cannot tell a work call from a personal one before you answer, so you either answer everything in work voice or answer a customer the way you would answer your brother. Nobody else can help: if your phone is flat or in the ute or already on a call, that enquiry is simply gone, and you will never know it existed. And there is no record of anything — no missed call log, no note of what was agreed, nothing to look at when you wonder why the phone feels quieter this month. All four are fixable in about twenty minutes, and the fix is not a new phone. It is putting a proper business number on the phone you already carry, in a way that keeps the business identity separate from the personal one and gives the call somewhere to go when you cannot take it. This is the whole setup: the four available methods and which to choose, the settings that actually matter, what to do about after-hours, what happens when a staff member leaves, and the six things that break when this is done casually.
Every supplier will answer "how much does a business phone system cost?" with a per-user-per-month figure, and every one of those figures is true and almost none of them are useful. They are true because that is genuinely the headline rate. They are not useful because the headline rate is only one of nine things on your invoice, and because two quotes with identical per-user rates routinely produce monthly bills thirty or forty per cent apart. The reasons are dull and completely knowable: one quote assumed every person needs a full seat when a third of your team only ever uses a mobile app; one included AI in the seat price while the other charges it per minute, which is fine until an outage or a campaign doubles your inbound calls; one bundled recording storage at thirty days and the other at twenty-four months; one absorbed porting and integration and the other quoted them as professional services after you signed. None of that is deception. It is the ordinary consequence of a market where the headline number is the thing being compared, so the headline number is the thing that gets optimised. This article does not give you a price list — we publish one of those separately and it is linked below. It gives you a worksheet: nine lines, filled in with your own facts, producing a monthly figure and a five-year total you can put in front of any supplier and ask them to check. Then three worked examples at four, twelve and forty users so you can see what the arithmetic looks like when it is done properly, and the eight places where invoices diverge from the quotes they came from.
Two years ago, "AI" on a business phone quote meant something, because only a handful of providers had it. In 2026 it means almost nothing, because all of them do — or say they do, which from the outside is indistinguishable. Put four Australian cloud phone quotes side by side today and all four will offer an AI receptionist, AI transcription, AI summaries and AI call scoring, in roughly the same words, at roughly the same price. The feature lists have converged. What has not converged is what happens on the call. One of those systems will handle a caller who interrupts halfway through a sentence; another will keep talking over them. One will transcribe "Kariong" and "Ngunnawal" and "MYOB" correctly; another will produce something unrecognisable and then summarise the unrecognisable version as fact. One knows it does not know, and says so, and puts the caller through; another invents an answer with complete confidence. None of that is visible in a feature list, a demo or a pricing table, and all of it is visible within about two hours of structured testing. This article is about that testing. It is not a ranked list of providers — we publish one of those separately and it is linked below. It is the layer underneath a ranked list: the four layers behind any AI phone feature, the nine tests that separate a real capability from a bolted-on one, the questions about data residency and retention that most buyers only ask after signing, and a scorecard you can fill in during a trial. Run it against us as well as everyone else. That is rather the point.
The email is always reassuring and usually accurate. Your service is moving to a new platform as part of an exciting transition, your plan and pricing are unchanged, and no action is required from you. Sometimes that is completely true and the right response is to file it. Sometimes it is the first notice of a migration that will change your call quality, your support path, your admin interface and, at renewal, your price — and the moment to do something about it is now rather than in eleven months. The difficulty is that four genuinely different events produce almost identical emails. A corporate acquisition, where somebody bought your provider and the service itself does not change. A platform migration, where the technology under your service is being replaced. A product retirement, where what you are on is being switched off on published dates. And a licensing or commercial change, where nothing technical happens but the terms do. Australia has had a great deal of all four in 2026: an energy retailer's telco base absorbed by a listed broadband provider with migrations running through the middle of the year, enterprise fibre and wholesale assets changing hands between major carriers, takeover activity among the mid-tier, a small-business voice platform being rebuilt on a partner's technology, and a list of legacy products with published end dates. This article separates the four, sets out what survives a change of ownership and what does not, and gives you a ninety-day checklist worth running whichever one you have received.
PBX stands for private branch exchange, and the original problem it solved is easy to picture: a business with twenty staff could not afford twenty telephone lines, so it bought a cabinet that let twenty internal telephones share four external ones, and let those twenty people ring each other without using a line at all. Everything else — extension numbers, transfers, hold, hunt groups, a receptionist's console — grew out of that one idea. A century later the cabinet has usually disappeared into a data centre, but the vocabulary has not, which is why a 2026 quote still talks about extensions, trunks and concurrent calls. The difficulty is that the word now covers at least five genuinely different architectures. A traditional PBX and a multi-tenant cloud platform have almost nothing in common except the function they perform, and yet both are sold as "a PBX", and the middle categories — IP PBX, hosted PBX, virtual PBX, cloud PBX — are used interchangeably by vendors who mean different things by each. That matters commercially, because the five models differ in who owns the equipment, who is responsible when it breaks, what happens to your calls when your internet drops, how you are charged, and what you can take with you when you leave. This article defines each one plainly, sets out what you are actually buying, and gives you the questions that reveal which architecture is hiding behind a quote.
Ask a business that dislikes its phone system what is wrong with it and you will rarely hear about the platform. You will hear that calls go to the wrong person, that nobody knows how to transfer, that the after-hours message still has last year's opening hours, that half the team never installed the app, that the second office was never really finished, and that the reports do not match what anyone believes is happening. None of that is a product fault. All of it is a setup fault — and specifically, a sequencing fault. Somebody ordered before deciding, ported before designing, went live before testing, and then trained people afterwards, if at all. The uncomfortable part is that a badly cut-over system stays badly cut over for years, because once a business is limping along on a phone system nobody wants to touch it again. So the setup is not a formality that happens between signing and using; it is the part that determines what you actually own for the next five years. This is the whole runbook, in order, for a business that already has numbers and staff and habits: the six decisions that must be settled before anything is ordered, the porting plan that is almost always the critical path, the call flow drawn on paper before anybody opens a console, the network check nearly everyone skips, the test script, cutover day itself with a defined point of no return, the first week, and the thirty-day review that turns an installation into a working system.
Two things happen in a real estate office on the same Tuesday. At 11:20am a buyer rings about a property they saw on a portal twenty minutes ago; nobody picks up, the call rolls to a mailbox, and by the time it is returned at 2:45pm they have booked an inspection with another agency and stopped answering unknown numbers. At 6:40pm a tenant rings about water coming through a ceiling; the office closed at 5:30pm, the recorded message gives a mobile number for emergencies, that mobile is on silent because its owner is at their child's concert, and the tenant — reasonably — arranges a plumber themselves. Those two failures look like the same problem, which is why agencies keep trying to solve them with the same fix. They are not. The first is a speed problem in a competitive market where the enquiry is worth thousands and the window is minutes. The second is a compliance and liability problem, because tenancy legislation across the states requires a landlord or agent to arrange urgent repairs quickly — commonly within twenty-four hours of being notified, with tighter timeframes for essential services in some jurisdictions — and generally allows a tenant who cannot reach the agent to arrange the repair and recover the cost. One is about winning work. The other is about what a tribunal will make of your evidence. This article treats them separately, because designing an agency phone system as one undifferentiated flow is the reason both keep happening.
Here is a sentence that tells you nothing: "our platform is powered by AI." It is now true of almost every business communications product on the market, and it is compatible with at least five completely different architectures, five different accountability structures and five very different answers to the only questions that matter. At one end sits a company that operates its own network, its own platform and its own infrastructure, and can tell you where a particular call was processed on a particular Tuesday. At the other sits a product built in a few months on a public model API, where the entire technical estate is somebody else's and the company you are contracting with cannot change a thing about how your data is handled — because it does not control the thing handling it. Both companies can pass a feature comparison. Both can run an impressive demonstration, because the demonstration is of the model, and the model is very good. The difference only surfaces in three situations: when a data residency review asks where your customer conversations were processed, when something goes wrong and you need it fixed rather than escalated, and when a regulator asks you — not your supplier — to account for an automated decision. This article sets out the five kinds of company, the layers your call audio actually passes through, and ten questions that separate them in about fifteen minutes.
Almost nobody designs a multi-site phone estate. It grows. The second location opens and somebody local arranges a phone line because that is the urgent thing that week. The fourth location inherits whatever the previous tenant had. The seventh is acquired and comes with its own system, its own numbers and its own contract with eighteen months to run. By the eleventh, the organisation is paying eleven separate bills, running three or four different platforms, holding numbers registered to at least two entities and possibly to a former franchisee, and cannot answer the two questions that matter most: how many calls did the network miss last month, and which sites are missing them. Meanwhile the operational absurdities pile up. A queue in Perth overflows at 4pm while two staff in Adelaide sit idle, and there is no path between them. A customer rings the Newcastle branch, gets no answer, and never learns that the Maitland branch would have taken the booking. Head office publishes a standard for how calls are answered and has no way to know whether it happens. None of this is a technology problem — one platform across many sites has been ordinary for a decade. It is a design problem and, in a franchise network, a governance problem: which decisions belong to the centre and which belong to the site. This article covers both.
A business rings a customer back about a quote. The customer never sees the call, because their carrier dropped it at the network edge for presenting a caller ID the business does not hold rights of use to. Another business rings the same customer an hour later and does reach the handset — where it displays under a red warning banner suggesting the call may be a scam, and goes unanswered. Neither business did anything wrong on purpose, neither was told what happened, and both concluded that outbound calling "does not work any more". It does work. What has changed is that two independent systems now sit between your dialler and the person you are calling: a network-level blocking regime under Australia's registered scam-reduction code, which is a rules-based system you can comply with precisely, and a reputation-labelling layer applied by carrier screening, handset software and third-party call-identification apps, which is a statistical system nobody publishes the internals of. They have different causes, different symptoms and different remedies, and treating them as one problem is why so many attempted fixes achieve nothing. This article separates them, sets out the six configuration and behaviour patterns that actually cause failed calls, gives you a diagnostic you can run in an afternoon with your own numbers and two handsets, and orders the remedies by how much difference each one makes.