The Tuesday Phone Call
Tuesday, 10:40am. A participant rings because Thursday’s support has to move to the morning — a specialist appointment came through.
Reception answers, cannot see the roster, takes a message. The coordinator rings back at 12:15 and asks them to run through it again. She opens the rostering system to find a worker, opens the plan in a second system to check the support is funded that way, updates the roster, and intends to write a note in the client record after lunch. The Thursday worker learns by text. Nobody tells the participant’s mother, who had arranged her whole day around the original time.
Four systems. Two staff. Two explanations from the participant. One note that may or may not get written. And not a single person in that chain did anything wrong — they were being the integration layer between four pieces of software that have never been introduced.
The connected version of the same ten minutes: the call arrives, the participant’s record opens on screen before anyone says hello, reception can see the roster and the plan, the booking moves, the worker is notified automatically, an SMS confirmation goes to the participant and their nominated contact, and the call summary writes itself into the file. Ninety seconds, one person, no repetition, and the coordinator never has to touch it.
What Fragmentation Feels Like From Outside
Providers usually describe this as an efficiency problem. That framing is comfortable and it is wrong, because it locates the cost in the back office where nobody has to feel it.
4×
Times a participant may re-explain their circumstances in a single month
Hours
Per coordinator per week spent moving data between systems by hand
1 typo
Is all it takes for a support to be missed when times live in two places
0
Of that is visible to the participant as a systems problem — they just see the service
For people who have spent years explaining themselves to institutions, being asked again is not a minor friction. It reads as a service that does not hold them in mind. And that judgement travels — to their planner, their family, and whoever asks them next for a recommendation.
The market already moved on this
Through 2025 and into 2026, NDIS platforms have consolidated into integrated systems covering compliance, workforce coordination, financial oversight and outcome tracking — and interoperability emerged as the competitive differentiator. Providers now select on native integrations and open APIs into accounting, payroll, CRM and reporting, because the alternative is manual workarounds, and manual workarounds are where the errors and the lost hours live.
The Six Systems, and Which One Is Truth
Whatever the brand names, almost every provider runs these six.
| System | Holds | Symptom when isolated |
|---|---|---|
| Client management / CRM | Participants, goals, plans, agreements, progress notes, consents. | Meant to be the single source of truth. Usually is not, because three other systems also hold contact details. |
| Rostering and scheduling | Who works where, when, with what skills and travel. | Every mismatch is a real person waiting at home. |
| Claims and billing | Service bookings, claims, budgets, plan utilisation. | Rejected claims discovered weeks later, and cash flow surprises. |
| Incidents, complaints, quality | Registers, investigations, corrective actions, audit evidence. | Trends invisible until they become a pattern somebody else notices first. |
| Communications — phone, SMS, email | Every actual conversation with participants, families, workers and health services. | The least connected and the highest context. Nobody misses it until they need to know what was said. |
| Workforce — HR, payroll, training | Screening checks, qualifications, training currency, availability. | Somebody rostered who is not currently cleared to work. |
You do not need one platform that does all six — that promise has sold a great deal of software and delivered a great deal of disappointment, usually as three weak modules bundled with two good ones. What you need is six systems that exchange data reliably, and one of them explicitly nominated as the source of truth for participant identity and contact details. Everything else reads from it. Skipping that single decision is the most common reason integration projects produce conflicting records rather than one good one.
Everything You Learn Arrives as a Conversation
Ask where new information actually enters your organisation and the answer is almost always the same: somebody rang.
A prospective participant enquires. A mother raises a concern about a worker. A support worker calls in about something that happened on shift. A plan manager queries a claim. A hospital discharge coordinator rings at 4pm on a Friday about someone coming home tomorrow. In every case the conversation holds the information first, and most completely — and then it either gets transcribed into a system or it evaporates.
Screen pop
The caller’s record opens automatically before you answer — plan, supports, this week’s roster, last three contacts. Ends the “can I take your details?” opening.
Click to call
Dial from inside the participant record. The call logs itself to the right person, so logging stops depending on someone choosing to do it.
Notes that write themselves
Transcript, summary and agreed actions land in the file, timestamped. The compliance backbone described in NDIS record keeping.
SMS from the roster
Reminders and change confirmations sent from the business number, two-way, with replies landing in the record instead of on a worker’s personal mobile.
Routing that knows who is calling
Known participants to their coordinator, new numbers to intake, after hours to the on-call rota. People reach someone who knows them, first time.
Calls that trigger workflow
A call to the complaints line opens a register entry. An after-hours incident call starts the notification clock in a system rather than in somebody’s intention.
The Four Ways Systems Connect
“We integrate with that” can mean four very different things, at four very different prices.
| Pattern | What it is | Best for | Watch out for |
|---|---|---|---|
| Native integration | The two vendors built and maintain the connection. Switch it on, authenticate, done. | Anything on the shelf. Always check for this first. | Only does what the vendors decided it does. |
| Webhooks | One system fires an event — call ended, SMS received — and another reacts in real time. | Simple triggers, and more use cases than people expect. | Needs somewhere to receive the event and something to do with it. |
| Automation / iPaaS | A middleware layer wires systems together with rules instead of code. | The sweet spot for most small and mid-sized providers. | Another subscription, and rules that need an owner. |
| Open API | Your developer or IT partner builds precisely what you need. | Genuinely unusual workflows nothing else covers. | Most capable, most expensive, needs long-term ownership. |
Work down that list in order. Providers who start at the API end routinely pay for something they could have configured in an afternoon. The full landscape is set out in integrations and open APIs, and the platforms Australian organisations actually use are catalogued in the Australian SaaS integration directory.
Moment by Moment Through a Participant Journey
| Moment | Disconnected | Connected |
|---|---|---|
| First enquiry | Details taken on paper or in a notes app, retyped later, sometimes lost between the call and the CRM. | Intake number routes straight to the right person, record created from the call, follow-up scheduled before hanging up. |
| Onboarding | The same information collected three times by three teams. | Collected once, visible to everyone who needs it, with consents recorded against the record. |
| Routine contact | “Can I get your name and date of birth?” | “Hi Marcus — is this about Thursday?” |
| Changing a support | Message, callback, roster check, funding check, confirmation optional. | Handled on the call, worker notified, SMS to participant and nominated contact. |
| New worker attends | Arrives with a name and an address; learns what matters by getting it wrong first. | Arrives briefed on preferences, communication needs and what happened last visit. |
| Raising a concern | Told to someone kind; whether it reaches the register depends on that person’s day. | Captured, classified, timestamped, routed, closed out, and the person told what happened. |
| After hours | A manager’s mobile, answered or not, with no context and no log. | A rostered on-call service with escalation, full logging and the record on screen. |
| Plan review | Evidence assembled from memory in the fortnight before. | A complete searchable history of contact, supports and outcomes, produced in minutes. |
Nothing in the right-hand column is futuristic. It is systems handing each other information that already exists, so that a human being does not have to carry it.
Giving Coordinators Their Week Back
The binding constraint in this sector is not funding rules or software licences. It is finding and keeping people who are good at this work. Integration turns out to be a retention strategy.
Support coordinators did not join the sector to do data entry, and the ones who resign rarely name the participants as the reason. When the administrative tax drops, the same headcount supports more people, and supports them better — which under current pricing is close to the only scaling available to most providers.
Enter it once
One fact, one place, read by everything else. Not the same phone number typed into three systems by three people, two of whom will get it slightly wrong.
Context outlives people
When a four-year veteran resigns on a Friday, what they knew is in the record on Monday instead of gone.
Private numbers stay private
Workers get a business identity on their own device. No personal mobile handed to families, no permanent on-call by default.
New starters are useful sooner
When context lives in systems rather than in colleagues’ heads, week one is productive instead of purely observational.
The after-hours point deserves emphasis. A worker whose personal mobile is the de facto emergency line has no way to be genuinely off duty, which is both a wellbeing failure and a legal one — see the right to disconnect and your phone system. A rostered on-call number with real escalation fixes both at once.
Four Risks, and How to Manage Them
Connecting systems that hold information about vulnerable people is not risk-free, and it should not be sold as though it were.
| Risk | Management |
|---|---|
| A bigger privacy surface | Every connection is another system holding participant data and another credential to protect. Map exactly what each integration transfers, apply least privilege, record it in your privacy register, and know which country each platform stores data in — see who owns the network your calls run on. |
| Errors that now propagate | A wrong number used to be wrong in one place; now it syncs everywhere in seconds. Designate one source of truth per data type and make the rest read-only against it. |
| Over-automation | Automate the movement of information, not judgement. An AI summary is a draft for a human to confirm, never the record itself. Put that boundary in policy, in writing. |
| Lock-in against a fifteen-year obligation | Records for a participant under 18 must be kept until they turn 25. Test the export during the trial, in an open format, before you integrate deeply. |
The consent conversation people skip
If call transcripts begin flowing into participant records, what is held about a person and who can see it has changed. That belongs in the service agreement conversation, in plain language, at sign-up — not discovered by a family member later. Informed consent is also the only kind that is defensible.
Start With One Connection
The classic failure is the eighteen-month platform migration that ends with a large invoice and a team quietly still using the old spreadsheet. Do the opposite: one connection, visible benefit, then the next.
| Stage | Action | Why here |
|---|---|---|
| 1 | Walk one real request end to end — a support change, an intake, a complaint. Write down every system touched and every point a human retypes something. | The retyping points are your integration backlog, and there are fewer than you fear. |
| 2 | Nominate the source of truth for participant identity and contact details. | Everything downstream depends on this one decision. |
| 3 | Connect the phone to the client record: screen pop plus automatic call logging. | Highest context, least connected, benefit visible on day one — which buys goodwill for the rest. |
| 4 | Drive SMS reminders and change confirmations from the roster. | Missed supports drop immediately, and that is a number your board understands. |
| 5 | Wire the complaints and on-call lines into their registers and workflows. | Compliance becomes a default rather than a discipline. |
| 6 | Review every quarter: what is still being retyped, what broke silently, what did the last complaint reveal. | Integrations rot quietly. Find it yourself, not at audit. |
Six Questions for Any Vendor
| Ask | What a good answer looks like |
|---|---|
| “Show me it working with our platform.” | A live demonstration against the system you actually run, doing the thing you actually need — not a partner logo page. |
| “Where is the API documentation?” | Public and readable. “Available on request under NDA” usually means thin. |
| “What does the integration cost?” | A clear answer. Integration priced as a premium tier changes the business case entirely. |
| “Which country stores the data?” | Named, immediately, without checking. For participant information this is a Privacy Act question. |
| “How do we export everything?” | A sample export file during the trial, in an open format. Your obligations outlast your contracts. |
| “Who fixes it when it breaks?” | One named owner. Two vendors pointing at each other is the default failure mode and it is worth pre-empting. |
Get this right and you do not end up with impressive technology. You end up with something better: a participant who rings and is greeted by name, by someone who already knows roughly what the call is about, and who can resolve it before saying goodbye.
Frequently Asked Questions
Why does system integration matter for participants rather than just for admin?
Because participants experience disconnected systems directly, even though they never see them. When rostering, records and the phone do not talk, the person calling is asked to explain their circumstances again, the callback takes an hour, the support worker arrives without knowing what matters to them, and nobody confirms the change to the family member who rearranged their day. For people who have spent years explaining themselves to institutions, being asked again is not a small friction - it reads as a service that does not hold them in mind. The connected version of the same interaction is unremarkable in the best way: the record opens before anyone answers, the booking is moved on the call, the worker is notified, and an SMS confirmation goes to the participant and their nominated contact. Same staff, same software budget, entirely different experience. That difference is what gets described to a planner or a friend when someone is asked whether the provider is any good.
Do we need a single platform that does everything?
No. The all-in-one platform that does client management, rostering, claims, quality, communications and payroll equally well does not really exist, and buying one usually means accepting three weak modules in order to get two strong ones. A better model is best-of-breed systems that exchange data reliably, with one platform explicitly nominated as the source of truth for participant identity and contact details so the others read from it rather than each maintaining their own version. Skipping that nomination is the single most common reason integration work produces conflicting records instead of one good one. The modular approach also protects you commercially, because you can replace one component without replacing everything - which matters a great deal when record retention obligations run for seven years, and up to fifteen for participants who were children when supported.
What can a phone system actually connect to in a disability service?
Six connections cover most of the value. Screen pop opens the caller's record automatically before you answer, showing their plan, supports and roster. Click to call lets you dial from inside the record so the call logs itself against the right participant. Automatic notes push a transcript, summary and agreed actions into the file with a timestamp. SMS driven from the roster sends reminders and change confirmations from the business number, two-way, so replies land in the record rather than on a worker's personal mobile. Intelligent routing sends known participants to their coordinator, unknown numbers to intake, and after-hours calls to the on-call rota. And workflow triggers let a call to the complaints line raise a register entry automatically, or an after-hours incident call start the notification process. None of those require custom development in most cases - they are native integrations or simple automation rules.
What is the difference between a native integration, a webhook and an API?
A native integration is built and maintained by the two vendors, so you switch it on and authenticate - cheapest and most reliable, but it only does what those vendors decided it does. A webhook is an event: one system announces that something happened, such as a call ending or an SMS arriving, and another system reacts in real time, which is simple and covers more situations than people expect. An automation or iPaaS platform sits in the middle and wires systems together with rules rather than code, which is usually the right answer for small and mid-sized providers because it is fast to build and easy to change. An open API means your developer or IT partner builds exactly what you want, which is the most capable and most expensive option and needs someone to own it long-term. Work down that list in order. Providers who begin at the API end routinely pay for something they could have configured in an afternoon.
What are the main risks of connecting our systems?
Four. The privacy surface grows, because every connection is another system holding participant information and another credential to protect, so map what each integration actually transfers, apply least privilege, and know the country each platform stores data in. Errors propagate faster, because a wrong contact detail that used to be wrong in one place now syncs everywhere within seconds, which is why a single source of truth per data type matters so much. Over-automation is a genuine hazard in a sector supporting vulnerable people: automate the movement of information, keep judgement with humans, and never allow an AI summary to become the official record without confirmation. And deep integration creates lock-in, which is uncomfortable against retention obligations that can run fifteen years, so test the data export during the trial rather than after you have committed. There is also a consent step people skip - if call transcripts begin flowing into records, participants should be told at service agreement stage.
How long does this take, and where should we start?
Start with one connection and a visible win rather than a platform migration. First, walk a single real request end to end - a support change, an intake or a complaint - noting every system touched and every point where somebody retypes something; those points are your backlog and there are usually fewer than expected. Second, nominate which system owns participant identity. Third, connect the phone to the client record with screen pop and automatic call logging, because it is the highest-context and least-connected system and the benefit shows on day one. Fourth, drive SMS reminders from the roster, which reduces missed supports immediately. Fifth, wire the complaints and on-call lines into their registers. Then review quarterly. Each of those stages is days rather than months, because there is no hardware and nothing to install on a server - it is configuration, authentication and a short period of people getting used to a new habit.
Will connecting systems mean we need fewer staff?
That is not what happens, and it is worth saying plainly. The constraint in disability services is not surplus staff, it is insufficient coordinator and support worker capacity for the demand that already exists, in a workforce that is hard to recruit and harder to retain. What integration removes is the administrative tax on people who did not enter this field to do data entry: the hours each week spent carrying information between systems, retyping the same fact and reconciling records that disagree with each other. The same team then supports more people, and supports them better, which under current pricing arrangements is realistically the only scaling available to most providers. There is a retention effect as well, in both directions - a coordinator who spends the week with participants rather than spreadsheets tends to stay, and a worker whose personal mobile is no longer the unofficial emergency line gets to genuinely finish work at the end of a shift.
