The Problem Nobody Named
AI did not arrive as a platform. It arrived as a feature, application by application, shipped in whatever release each vendor happened to have scheduled. The result is a pattern that looks like progress and behaves like fragmentation.
| System | What its AI can see | What it cannot see |
|---|---|---|
| CRM | Contacts, deals, emails, notes somebody typed. | That the customer rang three times this week, or what was said. |
| Job or project management | Jobs, schedules, site notes, materials. | Who the customer is commercially, and whether they are already unhappy. |
| Accounting | Invoices, payments, aged debtors. | That the disputed invoice was explained on a call last Tuesday. |
| Help desk | Tickets raised in writing. | Everything raised by phone, which in most Australian SMEs is the majority. |
| Calendar | Appointments. | Why the appointment exists or whether the customer has tried to move it twice. |
Now take an ordinary sentence: "I ordered a part on Thursday, the invoice looks wrong, and nobody has rung me back." Answering it needs the order, the invoice, the call history and the person who promised the callback. Four systems, none of which can see the other three, and an AI inside any one of them can answer at most a quarter of the question while sounding confident about the whole thing.
That gap is measurable at industry scale. Roughly 88% of contact centres report using AI in some form, while only about a quarter say it is properly integrated. The three quarters in between are not failing because their AI is weak. They are failing because it was bolted to the side of systems that do not talk to each other, and no amount of model improvement fixes an architecture problem.
The distinguishing feature of a business that has got value out of AI is not which model it uses. It is whether anything in its stack holds a complete view of a customer at the moment that customer is being dealt with. Everything else in this article follows from that one sentence, including the awkward conclusion that the layer best placed to hold that view is the one most businesses have historically treated as a utility.
The Integration Arithmetic
This part is not a matter of opinion. Connect systems to each other directly and the number of connections grows with the square of the number of systems. Connect them through a hub and it grows in a straight line.
| Systems | Point to point connections | Through a hub | Difference |
|---|---|---|---|
| 4 | 6 | 4 | Manageable either way. This is why nobody notices the problem early. |
| 6 | 15 | 6 | The point where "we will just connect these two" stops being a sensible default. |
| 9 | 36 | 9 | Where most growing businesses actually sit, usually without having counted. |
| 12 | 66 | 12 | Nobody builds sixty-six. They build eleven, and the other fifty-five are people copying things between screens. |
The numbers understate it, because each connection is not a one-off build. It is a relationship that has to survive both vendors changing their APIs, both parties changing their data models, and staff turnover at both ends. A business with nine systems and eleven ad hoc integrations is carrying eleven ongoing maintenance obligations that nobody has written down, and it will discover them one at a time, always on a Friday.
The alternative is not fewer systems. It is one system in the middle that everything connects to once. Every application then has exactly one integration to maintain, and the hub carries the mapping between them. This is not a new idea, it is how enterprise integration has worked for thirty years. What is new is the question of which layer should be the hub in a business too small to run an integration team, and the answer for most has changed.
Why the Communications Layer
Four properties qualify it, and no other system in a typical stack has all four.
Intent arrives here first
Customers do not update your CRM. They ring, text or message, and they say what they want in a sentence. The communications layer sees the intent at the moment it is formed, before any record exists to describe it. Every other system finds out later, if somebody types it in.
It runs in real time
A CRM sync runs every fifteen minutes and that is fine for a CRM. A call lasts ninety seconds. Only a layer that operates inside the conversation can look something up and change the outcome of the conversation, which is the difference between intelligence and a report.
It holds a durable identity
The phone number is the most stable identifier most businesses have. Email addresses change, account numbers are forgotten, website sessions are anonymous. The number is the same on voice, SMS and messaging, and it is presented automatically without anybody being asked to identify themselves.
It carries obligations
A communications platform is a carriage service with regulatory duties around emergency calling, recording, sender identity and outbound contact. That is a burden, and it is also the reason it is the layer that can be trusted with the customer-facing edge of an automation.
There is a fifth, softer reason. In most Australian businesses under two hundred people, the majority of customer interaction still happens by voice, and almost none of it makes it into any system of record beyond a line in a call log. That is the single largest body of unstructured information about your own customers that you currently own and cannot use. A hub that sits on the conversation turns it into structured records automatically, which improves every system downstream without anybody changing how they work.
The Architecture, in Plain Terms
Three tiers. Channels in, orchestration in the middle, systems of record around the outside. Nothing gets replaced.
| Tier | What sits there | What it is responsible for |
|---|---|---|
| Channels in | Inbound and outbound voice, SMS, WhatsApp and other messaging, web chat, web forms, email where it is customer facing. | Getting the conversation into the system regardless of how the customer chose to start it, and keeping it identified as one conversation if they switch. |
| Orchestration, the brain | Identity resolution, context assembly, AI agents, routing rules, queues, automations, transcription and summarisation, and the event log. | Working out who this is, gathering what is known about them, deciding what happens, doing what can be done, and recording all of it. |
| Systems of record | CRM, job or project management, calendar, help desk, accounting, payments, rostering, inventory. | Remaining the authoritative source for their own data. The hub reads from them and writes to them. It does not become a second copy of them. |
The last point in that table is the one that keeps this architecture healthy and it is the one most easily lost. The hub is not a database of customers. Your CRM is the customer database. The hub resolves an identity, fetches what it needs at the moment it needs it, acts, and writes the outcome back. The moment it starts keeping its own authoritative copy of customer data you have created a synchronisation problem, and synchronisation problems are how integration projects turn into permanent employment.
The orchestration layer needs five capabilities, and most phone systems have two
Identity resolution, so an inbound number becomes a known customer. Context assembly, so what is known is gathered before the conversation starts rather than after. Execution, so an agent or automation can actually change something in another system. Routing, which every phone system already has. And an event log with a per-event record, so any automated action can be traced afterwards. A platform that can only do routing and recording is a phone system. A platform that can do all five is a hub.
Four Flows, Step by Step
These are the four that deliver most of the value in the first quarter for a typical business. None of them requires changing any existing system.
Flow one: an inbound call that answers itself. The call arrives and the number is matched against the CRM. The hub pulls the customer, any open jobs, the last three interactions and the account status, and passes them to the AI agent as context. The agent greets the caller by name, hears "where is my part", reads the job record, answers with the actual status, offers an SMS confirmation and sends it. It writes a note to the CRM record, closes the loop on the follow-up task that was overdue, and logs everything. If at any point the caller asks for a person, the call routes into the normal queue and the person who answers sees the transcript so far. Total elapsed time about forty seconds, and nothing in your CRM had to change.
Flow two: a missed call that recovers itself. A call goes unanswered at 4.55pm. The hub detects an unanswered inbound from a mobile, sends an SMS within thirty seconds saying who it is and offering a time or a callback, creates a task on the customer record, and adds the contact to a morning callback list ordered by how long they have been waiting. If the customer replies to the SMS, the reply lands in the same queue as calls rather than in a phone somebody has to remember to check. This flow alone recovers more revenue than most AI projects, and it is an automation rather than an agent.
Flow three: a WhatsApp enquiry that is treated as a real enquiry. A message arrives on the business WhatsApp number. The hub resolves the sender against the CRM using the same number key it uses for voice, assigns it to the same queue as calls and SMS, and an agent handles the common questions or hands over to whoever is on that queue. The exchange is written to the customer record as one conversation. The significance is not the channel, it is that the customer's choice of channel stops determining whether they are visible.
Flow four: an outbound sequence triggered by a system of record. A quote moves to "sent" in the CRM. Four days later, with no reply logged, the hub sends a message on the channel the customer last used, and if there is still no response it puts a task in front of the right person with the full history attached. The trigger lives in the CRM, the execution lives in the hub, and the record of what happened goes back to the CRM. Outbound contact of this kind sits inside the Do Not Call and telemarketing rules, which is exactly why it belongs in the layer that already has to comply with them. We covered that in the outbound calling rules guide.
Why Not the CRM, the AI Vendor or an iPaaS
These are the three serious alternatives and each has a genuine case. Here is where each one runs out.
| Candidate | The case for it | Where it stops |
|---|---|---|
| The CRM as hub | It already holds the customer, most vendors have an app marketplace, and your sales team lives in it. | It is a system of record, not a real time layer. It cannot carry voice, it does not hold telco identity, it cannot route a call, and it is not a carrier, so every customer-facing action still has to be executed somewhere else. It is the right place for the customer, and the wrong place for the conversation. |
| The AI vendor as hub | The agent is the clever part, and the vendor will happily connect to everything for you. | No numbers, no carriage, no emergency calling obligations, and a commercial incentive to own the middle so that leaving is hard. It is also the layer most likely to change hands or change pricing, and rebuilding your integration topology because your AI vendor was acquired is an avoidable experience. |
| An integration platform | Genuinely good at moving data between systems on triggers, and often the cheapest way to build flow four. | It is asynchronous by design and has no presence in the conversation. It is an excellent complement to a hub and a poor substitute for one. Use it for the plumbing between back office systems, not for the moment a customer is on the line. |
The honest position is that a mature stack uses all of these. The CRM stays the customer record. The AI vendor may well provide part of the model layer. An integration platform handles the back office plumbing. What the communications platform provides is the thing none of them can: a presence in the live conversation, with identity, context and the ability to act, at the moment it matters.
One Identity, One Queue, One Record
Three unifications, in the order they pay off.
One identity. The same customer resolved the same way whether they ring, text, message or fill in a form. The phone number does most of the work here and it does it without asking anybody for anything. The practical benefit is that your reporting stops treating one customer as four, which is the reason most businesses have no idea how much contact their customers actually make.
One queue. Calls, SMS replies, WhatsApp messages and web chat waiting in the same place with the same priority rules, handled by the same people. Two queues means the quiet channel gets neglected and customers learn which channel gets a response, which is a lesson you do not want them learning. Our piece on UCaaS versus CCaaS sets out when a business genuinely needs queue software and when it does not.
One record. Every interaction on the customer's record in the system that is authoritative for customers, written automatically rather than by somebody remembering. This is the one that changes what your business knows about itself, because it makes the largest body of information you own, what customers actually say, available to every other decision you make.
The Interoperability Layer
A hub that only connects to a curated list of partners is a walled garden with a friendly name. Three things make the difference.
APIs in both directions. Not just the ability to fetch data out, but the ability for your systems to instruct the platform: place a call, send a message, change a routing decision, look up an event. A read-only API is a report.
Webhooks on every meaningful event. Call started, call ended, call missed, message received, agent escalated, recording available, transcript ready. Events are what let you build something the vendor never anticipated, which is the entire point of owning the middle.
A standard way for agents to reach tools. Since it emerged, the Model Context Protocol has become the common interface between AI agents and the tools and data they use, supported across the major AI ecosystems and now under independent stewardship, with related work on agent-to-agent communication following behind it. You do not need to care about the specification. You need to ask whether your platform can expose your systems to an agent through an open standard, so that a change of AI vendor is a change of vendor rather than a rebuild. That question is the single best predictor of whether you will still be happy with this decision in three years. Our guide to open APIs for voice and SMS goes through what to ask for.
What to Demand of the Platform
| Requirement | Why it matters |
|---|---|
| 1. Documented public API, both directions | Without it you are not building a hub, you are renting a feature list. |
| 2. Webhooks on every event, configurable | The mechanism by which you build what the vendor did not think of. |
| 3. Integrations included, not charged per connection | Per-connection pricing quietly caps how far you can take this and turns every good idea into a business case. |
| 4. You own the numbers | Your numbers are your customer identity keys. If you cannot port them out, everything above is built on somebody else's asset. |
| 5. A per-event log you can read and export | Required for improving automations, for auditing them, and for answering the first complaint about one. |
| 6. Australian hosting, stated plainly | Data residency for call recordings and transcripts is a live question in most regulated sectors, and "in the cloud" is not an answer. |
| 7. AI on the call path, not forwarded to a third party | A forwarding hop adds latency, adds a second provider to your compliance surface, and loses the context that made the agent worth having. |
| 8. Identity resolution against your CRM as standard | If matching a caller to a record is a professional services engagement, the platform was not designed for this. |
| 9. Write-back to systems of record | Reading saves the customer time. Writing saves your team's, and it is where the compounding value lives. |
| 10. One queue across channels | Otherwise you have bought several disconnected products with one invoice. |
| 11. Exportable configuration | What happens to what you built if you leave. If the answer is complicated, the answer is no. |
| 12. A support relationship with people who can see your setup | Hubs fail at the joins, and joins are diagnosed by someone who can look at both sides. |
Compliance in a Connected Stack
Automation does not change your obligations, it changes how quickly you can breach them at scale. Five things need to be right before the first flow goes live.
| Obligation | What it means for an automated flow |
|---|---|
| Recording and monitoring | Notification and consent requirements apply to recorded calls, including calls an AI handles. Transcripts are recordings for this purpose. Set the notification at the platform, not per flow. |
| Sender identity for SMS | Australian sender ID rules mean the identity your automated messages present is a registered matter, not a free text field. Get this right before an automation starts sending at volume. |
| Outbound contact rules | Do Not Call obligations and telemarketing rules apply to automated outbound just as they do to a person with a list. An automation makes it possible to breach a thousand times before anyone notices. |
| Messaging platform rules | Business messaging channels impose their own template and session rules on top of Australian law. Build flows that respect the session window rather than discovering it through failed sends. |
| Automated decisions | From 10 December 2026, privacy policies must disclose the kinds of personal information used in substantially automated decisions and the kinds of decisions made. A routing decision based on customer attributes may well qualify. See the automated decisions guide. |
There is a structural point underneath all five. Each of those obligations is easier to satisfy once, at the hub, than repeatedly in every application that might send a message or make a decision. Centralising the customer-facing edge is a compliance simplification as much as an architectural one, and that argument tends to land with boards in a way that integration diagrams do not.
A Ninety Day Build Order
| Phase | What to build | Why in this order |
|---|---|---|
| Weeks 1 to 2 | Identity. Match inbound numbers to the CRM and display the customer to whoever answers. Nothing automated yet. | Immediately useful to people, proves the connection works, and surfaces your data quality problems while they are still cheap to fix. |
| Weeks 3 to 5 | Write-back. Every call produces a note and a task on the right record automatically. | This is the highest value per hour of work in the entire sequence, and it improves every report and handover downstream from the day it goes live. |
| Weeks 6 to 8 | The missed call recovery flow. Detect, message, task, callback list. | An automation rather than an agent, so it is low risk, and it typically pays for the whole project on its own. |
| Weeks 9 to 12 | One queue across voice, SMS and messaging, then an AI agent on one narrow job, usually after hours. | The agent goes last deliberately. It is far more useful once identity, context and write-back already exist, and it is far easier to evaluate against a baseline you now have. |
The ordering is the advice. Most businesses start with the agent because it is the exciting part, and an agent without identity, context or write-back is a stranger answering your phone with no notes. Build the plumbing first and the clever part becomes straightforward. Our AI agent deployment guide covers weeks nine to twelve in detail.
Six Signs You Do Not Have a Hub
| Sign | What it actually indicates |
|---|---|
| Somebody retypes the same information into two systems daily | A missing integration that has been priced at a person's time instead of a connection. |
| Your CRM shows no record of phone calls | The majority of your customer interaction is invisible to every decision you make. |
| A customer who texts gets a slower response than one who rings | Two queues, and your customers have already worked out which one gets answered. |
| Nobody can say how many times a customer contacted you last month | No unified identity. One customer is being counted as three or four. |
| Adding a new system means a quote for an integration | Per-connection economics, which caps your architecture at whatever you can justify individually. |
| Your AI features are impressive in isolation and change nothing | The classic symptom. Narrow intelligence, no middle, which is where roughly three quarters of AI-using contact centres currently sit. |
How We Are Built for This
Uniden Voice over Cloud was designed as the middle layer rather than as an endpoint, and that shows up in specific places. The AI runs on the call path inside the platform, so there is no forwarding hop, no second provider in the audio and no lost context. Identity resolution against your CRM is standard rather than a professional services engagement. The API works in both directions and the webhooks fire on every meaningful event, so your systems can instruct the platform rather than only reading from it. Integrations are part of the platform rather than a per-connection line item, which means the tenth one costs the same as the first, and that changes which ideas are worth having.
Voice, SMS, messaging and the AI layer all sit in one platform with one queue, one customer identity and one event log, on infrastructure that is Australian owned, Australian hosted and Australian supported. You keep your numbers, your configuration is exportable, and the systems of record stay authoritative for their own data, because a hub that quietly becomes a second CRM has created a problem rather than solved one.
The practical version of all this is unglamorous and it works: start with identity, add write-back, automate the missed call, unify the queue, then put an agent on one narrow job. Ninety days, nothing replaced, and at the end of it every AI feature you already own works better because something in the middle finally knows who is calling.