It reads the period's case notes, plan and service logs, drafts the report under the headings the NDIA expects, and cites the source for every line so the coordinator can check it fast.
Where this works well
The problem this makes visible is a quiet one: support coordinators routinely spend more time accounting for their work than doing it. A mid-plan progress report means reading months of case notes across different staff and channels, cross-checking provider service logs, and retyping it all into the shape the NDIA expects — goals, supports delivered, budget utilisation, anything to flag for the next review. The drudgery hides the actual coordinator skill, and it eats evenings.
This earns its keep when a coordinator has a real volume of notes and logs for the period and a report due. It reads the period's case notes, the participant's plan PDF and the provider service logs, and drafts the report under the expected headings — with the source note cited behind every claim and weak evidence flagged rather than papered over. The coordinator who benefits most is the one carrying a full caseload of PACE-reportable plans, where the report-writing tax is heaviest and the time recaptured goes straight back into participant-facing work.
Where it works badly
If the underlying notes are thin, this can't invent substance. Where a coordinator has logged "attended appointment" with no detail on what changed against a goal, the draft will surface that as low-confidence — which is honest, but it means a report built on sparse notes is mostly a list of gaps. That's a signal to fix note capture, not a reason to trust a confident-looking draft.
It will also read a stale picture without knowing it. If the plan was varied recently and you feed it last quarter's plan PDF, or a provider's hours for the last fortnight aren't in the service log yet, the budget utilisation and "supports engaged" will be wrong — quietly, plausibly wrong. The honest test: if you can't point to the current plan and reconciled service logs for this exact period, the draft will mislead you faster than a blank page would. And for anything with a compliance edge — a reportable incident, a safeguarding concern — the draft can note that one was logged, but it is not an incident-management system and must not be treated as one.
What it doesn't do — and shouldn't
It drafts; it does not decide and it does not submit. It surfaces what the notes say about each goal, what hours and spend the logs show, and a suggested recommendation tied to that evidence. Whether a goal is genuinely progressing, whether a support should change, what to actually recommend at plan review, and whether the report is fit to lodge — those stay with the coordinator, who reviews, corrects and signs.
That boundary is deliberate, and in this vertical it matters more than most. The report shapes a participant's funding and supports, it carries the coordinator's name into the my NDIS provider portal, and reportable-incident obligations to the NDIS Quality and Safeguards Commission are a registered-provider duty on a 24-hour clock — not something a drafting tool discharges. The tool exists to give the coordinator back the hours so they can spend them on the judgement only they can make.
What your data has to look like for this to work
The draft is only as good as four things, named specifically. Case notes that distinguish a goal from an observation — "Aisha cooked an unassisted meal, working toward the daily-living-skills goal" is usable; "good session" is not. The participant's current NDIS plan, with the funded goals and category budgets the report maps against. Provider service logs with hours and spend reconciled for the reporting period, by funding category — Core Supports, and the Capacity Building lines like Support Coordination and Improved Daily Living. And a consistent participant identifier (the NDIS number) so notes, plan and logs join up to the right person.
Most coordination teams have some of this in good shape and some of it scattered across email, spreadsheets and a CRM that nobody fills in the same way twice. Getting notes to consistently separate goal-progress from general observation, and getting service logs reconciled and current, is usually the real first job — and it's a matter of how information is captured day to day, not a tool you buy. That capture work is what we help with, and it's typically larger and more valuable than the drafting layer that sits on top of it.
Could this draft a recommendation that's wrong for the participant — say, push to cut a support that's actually working?
It drafts recommendations as suggestions tied to the evidence it found, not decisions. A line like "review Core funding at plan review" is flagged for you to weigh, and any claim with thin or missing notes behind it is called out rather than smoothed over. You stay the author: nothing is submitted until you've read every cited note and signed.
Our case notes are a mess — free text, different staff, some half-finished. Will it still work?
Partly, and it will show you where it's guessing. It reads what's there and cites the note behind each claim, so a vague or contradictory note surfaces as low-confidence rather than as a confident fabrication. But if a goal was never written down distinctly from a general observation, the draft can't manufacture progress against it — that gap is exactly what the tool makes visible, and it's usually the first thing worth fixing.
Does this replace the support coordinator?
No. It replaces the hours spent hunting through months of notes and retyping them into a report shell. The judgement — whether a goal is genuinely progressing, whether a support should change, what to recommend at plan review — stays with the coordinator, who reviews, corrects and signs. We accelerate the assembly, not the decision.
How current does the data have to be? Plans and spend change.
It only knows what's in the notes, the plan PDF and the service logs you give it for that period. If a plan was varied last week or a provider hasn't entered last fortnight's hours, the draft will reflect the old picture — so the budget figures and 'supports engaged' are only as current as your logs. The fix is feeding it the current plan and reconciled logs, then checking the cited sources before you sign.
Where does the participant's data go — is it sent off to a public AI service?
No. It runs against your own document store, not a public chatbot, and the participant's notes and plan stay inside your environment. Given this is sensitive disability and health information, the data boundary is part of the build, not an afterthought — we scope where the documents sit and who can see them before anything is wired up.
Who's accountable if the submitted report is wrong?
You are — the coordinator who signs it. That's deliberate. The tool produces a draft with every claim traceable to a source note so you can verify quickly, but the report that reaches the NDIA carries your name and your judgement, exactly as it does today.
Estimated build: 4 weeks. Most of it is template work we've already done.
Fixed scope, fixed price, fixed dates.
The cost band reflects the engagement shape, not a per-feature line item. We work on fixed scope, fixed price, fixed dates — see the services catalogue for what falls inside each band.
Considering this for your org?
The honest place to start is a bite-sized first piece — one contained change, low risk. Tell us where it hurts; we’ll play it back, scope it, and show you what’s possible.