AI Receptionist for Splose NDIS Clinics

On an NDIS allied health line running Splose, the appointment is the easy part. The hard part is everything wrapped around it: which participant, whose plan pays, whether the funding is self-managed, plan-managed or agency-managed, whether there is allocation left, and what claim detail the session needs so it can actually be paid. A booking made without those is a session the provider may never get paid for, and a generic voice agent knows none of them.

We build the Splose connection, and this is about the part around the appointment: the funding, the manager and the claim, captured on the call so the booking is one that gets paid.

The failures on an NDIS line are rarely about the calendar. They are about a session booked past a participant's remaining funding, an invoice sent to the wrong plan manager, or a claim missing the detail it needs to be paid. 2care captures what the payment actually depends on, from what the caller says, before it writes the booking.

The caller	What 2care captures	What it means for the booking
A plan-managed participant	The plan manager to invoice	Booked, the invoice routed to the manager
A self-managed participant	The participant's own claim details	Booked, the participant claims it back
An agency-managed participant	The support item the funding covers	Booked within the agency's rules
A support coordinator ringing	The participant they act for	Booked to the participant, coordinator noted
A participant near their limit	The allocation left in the plan	Booked only within funding, otherwise flagged

The last row is the one that protects the provider. Where the remaining funding will not cover the session the caller is asking for, the agent does not quietly book it and leave the shortfall to be discovered at invoicing; it flags the gap and routes the call, so a conversation about funding happens before the appointment, not after an unpaid one.

How a booking reaches Splose, and how fast

Underneath, the mechanism is one connection. 2care reaches Splose through its API, authorised with a scoped credential set during onboarding, with nothing installed at the clinic. Availability is read live per practitioner and support type, so an offered slot genuinely exists, and the booking is written against the resolved participant and validated by Splose against its own rules, so a slot taken during the call fails cleanly rather than being assumed free.

The timing is what keeps a support coordinator on the line rather than on hold. A reply comes back in about 480 milliseconds, ninety-fifth percentile below 700, on our own voice stack rather than a chain of third-party services, so checking Splose availability and reading funding never becomes an awkward silence. The line runs at 99.9 per cent uptime and carries a thousand or more calls at once, and every booking write is idempotent, so a retried request after a network hiccup records one session, not two. Turn-taking holds for a complete sentence, so a coordinator reading out a participant number and a plan reference is not cut off partway through it.

Booking within the funding, not past it

The point of reading funding on the call is not bureaucratic caution; it is the difference between a provider that gets paid and one that writes sessions off. Where Splose holds a participant's allocation, 2care books within it: a single session that fits is booked and claimed cleanly, and a plan of supports is booked whole at the set cadence only as far as the funding reaches, with the rest flagged for a coordinator to sort rather than silently overbooked.

That discipline matters most on the plans that are nearly spent, which are exactly the ones a rushed front desk overbooks, because the funding position is not visible while answering a call. Reading it live means the agent knows what a human at the desk often does not until the claim bounces, and it turns a category of unpaid work into a conversation held at the right time.

It also protects the participant, not just the provider. A participant booked past their funding is a participant who either gets an unexpected bill or has a session cancelled later, both of which undermine the trust a plan is meant to build. Flagging the shortfall on the call, before the appointment is made, means the participant and their coordinator can decide how to use what remains rather than discovering the problem at the worst moment. Reading funding live is as much a duty of care as it is a commercial safeguard.

The detail a claim needs to be paid

A booked session and a paid session are not the same thing on an NDIS line, and the gap between them is claim detail. A session that cannot be claimed, because the support item is wrong, the date falls outside the plan period, or the manager's reference is missing, is unpaid work however good the appointment was.

2care captures what a claim depends on at the point of booking: the support item the session sits under, the plan period it falls in, and the manager or claim reference it will be billed against. Because that detail is structured in Splose from the start rather than reconstructed at invoicing, the claim goes out clean the first time, and the provider spends less of the month chasing rejections that a captured field would have prevented. On a business where cash flow depends on claims clearing, that is not an administrative nicety; it is the difference between getting paid this fortnight and the next.

The coordinator's call and the participant's

Not every caller is the participant. A support coordinator books for several participants, a parent books for a child, a plan manager rings to query an invoice. The identity being funded is not always the identity on the phone, and a system that assumes otherwise attaches a session to the wrong plan.

2care resolves the participant being booked, not just the caller, and records who is acting for them, so a coordinator booking three participants in one call ends with three correctly attributed sessions rather than three attached to the coordinator. Where the relationship is unclear, it asks rather than guessing, because a session funded against the wrong plan is a payment problem that surfaces weeks later. On a provider with a large plan-managed caseload, that attribution accuracy is the quiet difference between a clean claims run and a fortnight of reconciliations, and it is exactly the kind of detail a busy phone gets wrong under pressure, because the person answering cannot hold three participants' funding in their head while the line keeps ringing.

What 2care changes for a Splose clinic

A Splose clinic is not short of a system that can track funding and invoices. It is short of a phone that captures the funding, the manager and the claim correctly while it books, without a coordinator keying it in afterward. 2care answers every call, resolves the participant, reads the funding, books within it, and writes the session and its claim detail into Splose, in one native pipeline rather than a chain of tools passing a participant along.

What a clinic feels is not a faster booking on the calls it already answered. It is the sessions that used to be written off because a plan was already spent now caught before they are booked, the invoices that reach the right manager the first time, and the after-hours coordinator calls that used to hit voicemail now handled. 2care keeps the funding side of a booking as clean as the clinical side, which on an NDIS line is where the money actually is.

The record, and the rules that apply

Identity is settled before any funding is read or slot is held. A returning participant is found on their existing Splose file and confirmed with a date of birth; where two files could both be them, a person takes over instead of the agent choosing one, following patient matching. Manager, claim and support details land as structured fields rather than a note someone retypes, so the booking already carries what invoicing will need, and the same capture powers patient intake on every channel a participant might use.

A booking here is not a message flowing past. It builds a transcript, ties it to a participant, and writes a session and its claim detail into Splose, which is processing personal and health information, not merely carrying it.

Under HHS guidance for US work, and the equivalent obligations under Australian and UK law, that makes the vendor a data processor and business associate. So the arrangement carries a signed agreement before any live call, data stays in region, encryption protects it end to end, no model behind the conversation trains on it, and each write can be reversed. The compliance page lays out which framework applies where.

Where this is right for Splose, and getting live

This is right for a clinic whose bookings depend on funding, that keeps its participants, supports and allocations current in Splose, and that has a coordinator to take the calls where funding or identity needs a human. Given those, the benefit lands from the first day the line goes live, and the write-off sessions it prevents are often worth more than the time it saves.

Getting there is three moves over weeks. The connection is authorised to read availability and funding and to write bookings through the Splose API. The clinic's setup is mapped: practitioners and support types, the plans and allocations, invoicing rules per management type, and the route for a call needing a coordinator. Then the line is tested against a sandbox with the team listening before it is switched across, and the funding and identity handling is tuned over the first days against real calls, each change backed by the trigger every escalation records.

Frequently asked questions

Does it check a participant's funding before booking?

Yes, where Splose holds the allocation. A session that fits the remaining funding is booked and its claim detail captured; where the funding will not cover it, the agent flags the gap and routes the call rather than booking a session that cannot be paid and would only be written off later.

Can a support coordinator book for several participants?

Yes. The agent resolves each participant being booked rather than attaching everything to the caller, and records who is acting for them, so a coordinator ringing about three participants ends with three correctly attributed sessions in Splose.

How does it get the invoice to the right plan manager?

By capturing the management type and manager on the call, as structured fields, so a plan-managed session is routed to the right manager, a self-managed one carries the participant's claim details, and an agency-managed one is booked within the agency's rules.

Will it create duplicate records in Splose?

No. The agent finds the participant's existing Splose file first and checks it against a date of birth, and if two files could both be the caller it hands the call to a person instead of picking one, so a participant's history and funding never split across a duplicate.

Is participant data ever used to train models?

No. Nothing a participant shares becomes training data for a model in the pipeline. It is encrypted end to end, stored in region, retained only for as long as the record needs, and governed by the agreement covering every Splose call the agent takes.

Hear it book within a participant's funding

The call worth judging on a Splose line is a coordinator booking a plan of supports for a participant whose funding is running low, with the allocation checked, the manager captured and the overrun flagged rather than quietly booked.

See how the same connection runs on other systems across integrations, or hear a funded session booked cleanly on a live call when you book a demo.