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.
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.
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.
There is a particular kind of silence that has now been officially explained. If you dial Triple Zero from a mobile and your own carrier's network is unavailable, your handset will try to place the call through another carrier's network instead. That process is called emergency camp-on, it is the reason emergency calls can be made with no credit, no active service and no SIM card at all, and it takes time. According to advice published today by the federal government and the mobile carriers, it can take up to sixty seconds — and during a Telstra outage earlier this year the maximum stretched to ninety. For the whole of that time there is generally nothing on the line. No ringing, no message, no reassurance. The advice being circulated is specific and slightly counter-intuitive: if the first attempt does not connect within about five seconds, hang up and immediately try again; on that second attempt, stay on the line for up to a minute. This article explains what camp-on actually is, what the screen indicators mean, where the advice came from and what it does not cover — and then does the part the news coverage does not, which is work out what an Australian business should actually change on the strength of it.
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.
Every conversation about AI and security in the last two years has been about AI as the threat, and that framing is not wrong. The Australian Signals Directorate has assessed that AI almost certainly enables malicious actors to execute attacks at greater scale and speed, and the numbers behind that assessment are not subtle: more than 84,700 cybercrime reports in a year, roughly one every six minutes, with the average cost per incident rising fifty per cent to $80,850. Convincing phishing used to require somebody who could write. Convincing voice impersonation used to require an impressionist. Neither is true now. What gets far less attention is that the same technology is unusually good at the defensive side of exactly this problem, and that some of the most valuable places to deploy it are on the layer businesses think about least — the phone. Voice is where the social engineering actually lands. It is where the authorisation gets given, where the invoice detail gets changed, where the urgent request from the boss arrives, and it is almost always the least monitored channel in the business. This article sets out eight specific gaps that AI closes on that layer, states plainly the four it does nothing for, and covers the governance you need before you switch any of it on — including the obligation that lands on 10 December 2026 and applies to more businesses than expect it.
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.
Ask an Australian business what kind of phone system they have and the answer is usually a brand name, occasionally a technology, and almost never a generation. That is a problem, because the generation is the part that determines what happens next. A business on analogue copper lines, a business running an ISDN PBX in a comms cupboard, a business that bolted SIP trunks onto that same PBX in 2016, and a business on a cloud platform are four genuinely different situations with four different sets of options, four different risk profiles and four different bills. They are also, awkwardly, four situations that can all be described as having a phone system that works. This article lays out the four eras of business telephony — analogue POTS, digital ISDN with an on-premises PBX, VoIP, and Voice over Cloud — and what actually changed at each transition. It spends time on the distinction most buyers get wrong, which is that VoIP describes how voice travels and Voice over Cloud describes where the system lives, meaning they are separate decisions that get sold as one. And it finishes with a diagnostic you can run in five minutes to work out which era you are in, plus the honest arithmetic on when moving is worth it and when it is not.