NDIS Providers Automation Assessment Checklist: Which Jobs for AI First?

An NDIS provider should score each admin job on four things (time spent, how repetitive it is, how fast a person can check the result, and how much harm a wrong result causes) and pilot the highest scorer first. For most small providers that is checking invoices against shift notes or tidying progress notes, not rostering or incident reports.

The score matters less than the discipline behind it. Providers who start with whatever feels most annoying often pick the job where mistakes are costly and hard to spot, such as drafting behaviour support content. A grid makes you separate "irritating" from "safe to hand to a tool", and it leaves a written reason for the choice that an auditor or a board member can read.

Follow me on Instagram@sagnikteaches

The four-question grid

List your admin jobs, then score each from 1 to 5 on these questions. The total out of 20 is your ranking.

Connect on LinkedInSagnik Bhattacharya

Harm is scored backwards on purpose: 5 means low harm, so a safe job earns a high total. A job that scores 1 on harm should not be piloted first however many hours it takes, whatever the total says. That is the one hard rule in the grid.

Subscribe on YouTube@sagnikteaches

How to score honestly

• Time: count it for a fortnight, not from memory. People undercount the notes they finish at home.
• Repetition: if you cannot write the steps in under ten lines, give it a 2 or less.
• Checkability: time the check. Ask a coordinator to verify five sample outputs and write down how long it takes.
• Harm: ask "if this were wrong and nobody noticed for a month, who would be affected?" If the answer includes a participant's safety, it is a 1.

A worked example: 14 staff and 22 participants

Illustrative figures. A small provider with 14 staff and 22 participants lists five jobs and times each for two weeks. Here are the weekly hours and scores.

Two jobs tie on 16, so this provider breaks the tie on checkability, because a first pilot exists to build the review habit. Claim checking scores 5: each flagged line is compared with one shift record in seconds. Notes score 4: the reviewer has to read the worker's rough words against the tidied draft. Claim checking scores only 2 on harm because one wrong rate repeats across many lines, but the pilot's output is a list of suspected mismatches that a person works through before anything is submitted, so nothing reaches the claim on the tool's word. Notes, with the highest hours (14 a week) and a harm score of 3 because a misleading note could affect later support, become the second pilot once the first has proved the habit.

Rostering scores lowest because every shift depends on a person's availability, a participant's preferences and qualifications, and a last-minute cancellation. Those are exactly the cases where a confident wrong answer is expensive. That does not mean no tool helps: rostering software with vacant-shift offers saves time without a language model improvising. It means rostering is a software question more than a prompt question; the cost tutorial on NDIS software per-user costs covers it.

What each job looks like when AI helps

These are the five jobs in the grid, each with the form AI takes, the check that must stay with a person, and an example.

Progress notes

The helpful form is dictation, then tidying: the support worker speaks or types rough words, and the tool turns them into a complete note with headings. The person stays the author. Take this illustrative rough note: "went shops with [participant], did own money at till, bit anxious in queue, used breathing, home 2.15". A tidied version could read: "Community access, 12:00 to 2:15. [Participant] paid at the till independently. They felt anxious in the queue and used a breathing technique. Returned home at 2:15." What to fix: the draft added a start time that the worker never gave, so the check is "every fact in the output appears in the input". The detailed routine is in the tutorial on writing progress notes with an audit checklist.

Invoicing and claims

Use AI or a spreadsheet to compare the claim lines with shift records: dates, durations, support categories and rates. The output is a list of mismatches, not a submission. Illustrative output: "Line 14: claimed 3.0 hours on 12 May; shift record shows 2.5 hours. Line 22: weekend rate used; shift started on a Friday." What to fix: the tool does not know your price list unless you give it, so paste the current rates in each time rather than trusting memory. Checking claims against shift notes shows the full method.

Enquiries

Drafting a first reply to a referrer, or answering "do you support people in shared housing?" A person sends the reply. Never let the tool promise availability, prices or a start date. A sample prompt for this job appears further down.

Audit preparation

Sorting evidence into folders by standard, and listing gaps: "no training record for two staff", "policy review date passed". The tool finds gaps; it does not write compliance claims. The folder method is in building the evidence folder.

Rostering

Leave to scheduling software, and use a chatbot only for messages, such as a draft text to offer an open shift. A person picks the worker.

The red-line list: jobs not to hand to AI first

Whatever the score, these stay human-led until you have months of safe experience, and some should stay that way:

• Writing or changing a behaviour support plan. See what the commission says about AI and behaviour support plans.
• Final wording on incident reports about harm or abuse.
• Any decision to refuse, reduce or end a participant's support.
• Submitting claims without a person reviewing them.
• Pasting identifiable participant details into a free consumer chatbot.

For the privacy side, the tutorial on what is safe under the privacy principles sets out what data to keep out of tools.

A four-week pilot for the top-scoring job

Here is a plan for the claim-checking pilot, written so a coordinator can run it alongside normal work.

1. Week 0, set the baseline. Time how long checking takes by hand for one fortnight of claims, and count errors found. Say 5 hours and 11 errors.
2. Week 1, build and test on old data. Run last month's claims through the tool, with participant names replaced by codes, and compare its list with the errors you already know about. Count the ones it misses and the ones it invents.
3. Week 2, run it alongside. Check by hand as usual, and compare. Write each disagreement down.
4. Week 3, tool first. A coordinator works from the tool's list and then spot-checks 20 per cent of lines by hand.
5. Week 4, decide. Count hours saved and errors missed, then choose: adopt, adjust or stop.

Stop rules, written before you start

• Stop if the tool misses an error that would have caused an incorrect claim and the hand check also missed it.
• Stop if any participant name or number is found in a place it should not be.
• Stop if the checking now takes longer than the old method, once the setup is done.
• Adopt only if the tool catches at least 90 per cent of known errors in the week 1 test and saves at least 1 hour a week once review time is counted.

The 90 per cent and 1 hour are examples; set your own, but set them in writing before you see results. Otherwise any result will seem good enough.

Sample sign-off sheet for the pilot

A one-page record makes the pilot an auditable decision. Here is a filled-in version (illustrative):

Job piloted: checking claim lines against shift records
Owner: operations manager
Tool and plan: [tool name], paid business plan
Data used: shift date, hours, support category, rate, participant code (no names)
Who reviews output: coordinator, every claim run
Baseline: 5 hours a fortnight, 11 errors found by hand
Result (week 4): 2 hours a fortnight, 10 of 11 known errors caught, 1 false alarm
Decision: adopt, with a hand check of 20% of lines each run
Reviewed again on: [date, 3 months later]
Signed: [name, role, date]

Keep this in your evidence folder with the pilot's test data. It shows that you assessed the risk, set limits and reviewed the result, which is what an auditor would want to see about any new way of working. Update the policy that covers technology use to match, naming the job, the tool, the data it may see and who reviews it.

A second provider, a different result

The grid does not give every provider the same answer. Consider an illustrative support coordination business with 4 staff and 60 participants. Its staff do little rostering and no shift-based invoicing, so those jobs score low on time. The hours go on three things: writing plan-review summaries (8 hours a week), answering emails from participants and providers (9 hours), and chasing documents (3 hours).

Here the inbox wins, and the plan-review summaries come last despite taking almost as many hours, because a summary that misstates a participant's goals can steer a plan meeting the wrong way and is slow to check. Same grid, different business, a different first pilot.

A sample prompt and output for the enquiry job

If your first pilot is replies, give the tool the rules as well as the message. Here is an illustrative prompt with the sensitive parts removed.

You draft first replies for a small disability support provider.
Rules: plain English, under 120 words, warm and direct. Never
promise availability, a start date, a price or a worker. Never
ask for health details by email. End by offering a phone call
with the coordinator. Leave [name] and [phone] as placeholders.

Enquiry: "Hi, my brother has just got his plan and needs help
with community access two afternoons a week. Do you do that?"

A plausible result (illustrative): "Hello [first name], thank you for getting in touch. We do provide community access support, and I would be glad to talk through what your brother is looking for. The quickest way is a short call with our coordinator, [name], on [phone], when we can talk about days, times and goals. If you prefer, reply with a good time to call. Kind regards, [your name]". What you would fix: the reply says "we do provide" which is fine here, but if the provider does not cover the area or has no capacity, a person must change it before sending. The check is a person reading every reply for the three promises banned in the prompt.

Five scoring mistakes and how they show up

• Scoring by annoyance. The job people hate gets a 5 on time although the log shows 40 minutes a week. Fix: time it.
• Treating "AI drafts it" as checkable. If the checker must reread the whole source to verify, the check takes as long as the job. Fix: score checkability on the real time it took.
• Ignoring who the output reaches. A note that stays inside the file is lower risk than a message sent to a participant's family. Fix: take one point off the harm score for anything that leaves the organisation.
• Counting the tool's saving but not the review. Saving 6 hours but spending 4 reviewing is a 2-hour gain. Fix: count net hours in the week 4 decision.
• Letting the keenest person choose alone. One enthusiast scores everything high. Fix: have a second person, ideally someone who does the job, score separately, and discuss any gap of two or more points.

Briefing the team before the pilot starts

A pilot works only if the people involved know the rules. A ten-minute briefing with a one-page handout is enough. Cover these points in order:

1. Which one job is being piloted and for how long (four weeks).
2. What the tool may see: for example, shift details with participant codes, never full names, diagnoses or addresses.
3. What the tool must never do: send anything, change a record or decide something about a participant.
4. Who reviews the output and how they record a mistake.
5. Where to raise a concern, with a named person.

Ask for one volunteer from the team doing the job to review outputs with the coordinator. In practice the volunteer notices things the manager misses, such as a support category name that staff use differently from the price list.

Where the grid stops helping

The grid ranks tasks you already do. It does not tell you whether a product is safe, or whether your provider's contract and privacy obligations allow a particular use. Before any real participant information goes into a tool, read the vendor's data terms, check where data is stored and whether it is used for training, and ask a qualified adviser about your obligations. If you are buying software, the questions in the per-user cost comparison linked above help, because some rostering and notes products now include AI note features in their lowest tier; ShiftCare, for one, lists AI progress notes and voice transcription on its Basic plan.

Putting a dollar figure on the pilot

A quick sum helps decide whether a job is worth the effort of a pilot at all. Take the 14-staff provider's claim checking. Illustrative figures: 5 hours a fortnight by hand is 2.5 hours a week. If the tool brings that to 1 hour including the review, the saving is 1.5 hours a week, or about 78 hours a year at 52 weeks. At a loaded cost of $40 an hour for an administrator, that is $3,120 a year. Against that, count the tool subscription (say $30 a month, or $360 a year) and the setup time (say 6 hours, or $240). The first-year net is $3,120 minus $600, which is $2,520.

Now run the same sum for the notes pilot. Fourteen hours a week of note writing across the team is a bigger prize, but if tidying saves only 20 per cent, that is 2.8 hours a week, and the review time a coordinator spends can take most of it back. This is why a high Time score alone is not enough: a sum like this exposes jobs where the saving is real but small once checking is counted. If the sum shows less than about 1 hour a week saved after review, the job is not worth a pilot yet; move down the list.

One more honest column belongs in the sum: errors avoided. If the claim check finds two wrong lines a month and each would have cost an hour to correct plus a delayed payment, the benefit is bigger than the hours alone. Record the errors it catches in the pilot log, because that is usually the argument that convinces a sceptical board.

Repeating the grid every quarter

Scores change. A job that had low checkability becomes easier once your forms are structured; a job that scored high becomes riskier if your caseload changes. Every quarter:

• Re-time the top three jobs for a fortnight.
• Re-score checkability with a fresh sample of five outputs.
• Add any new job that has grown (for example, referrals after you open a waiting list).
• Remove a job from the list once it has been automated, and note the hours saved.

If you would rather score your own jobs with someone else in the room, that is what my AI implementation consultation is for. Otherwise, take the grid, time your jobs for a fortnight, and have your first pilot decided by the end of the month.

Questions before you start an automation pilot

Should an NDIS provider automate invoicing first?

Often the checking of invoices, not the submitting. Matching claims to shift records is repetitive and easy to verify, so it scores well. Letting a tool submit claims without a person reviewing them scores badly, because one wrong rate can repeat across dozens of lines before anyone notices.

Can AI write progress notes for participants?

It can tidy and complete notes a support worker has written or dictated. It should not invent what happened. Keep the worker as the author, keep the original wording, and have a coordinator spot-check a sample each week during a pilot.

How many jobs should we pilot at once?

One. Two pilots at once make it impossible to tell which change caused a problem, and a small team cannot review two sets of outputs properly. Finish the four weeks, decide, then start the next job.

What if staff worry AI will replace them?

Say plainly which job is being changed, what stays with people, and that the aim is less evening paperwork. Ask workers to help choose the pilot job, because the people doing the task know where it goes wrong.

Further reads

• NDIS Plan Manager Invoices: Checking Claims Against Budgets With AI — Budget and invoice checks if you also manage plans.
• NDIS Incident Report Template: Can AI Draft It? What a Manager Checks — See what a manager checks when AI drafts an incident report.
• NDIS Provider Website: Plain-English and Easy-Read Pages Using AI — Plain-English pages once enquiry replies are in hand.
• NDIS Occupational Therapy Report Template: A First Draft With AI — A report job scored the same way, with its checks.
• AI Accounting for NDIS Providers: Categorising Income and Claims — Categorising income and claims once invoices flow.
• NDIS Service Agreement Template: Plain-English Drafting With AI — Plain-English agreements for new participants.
• How to Get Clients as an NDIS Provider: AI for Enquiries, Referrers — Enquiry and referrer replies if that job scores highest.
• NDIS Provider Policies and Procedures: Tailoring Templates With AI — Update your technology-use policy after the pilot.
• AI for Disability Services: Service Agreements and Incident Logs — Draft service agreements from your own template and structure incident logs with AI, while keeping participant details out of the prompt.
• AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.

Sources: ShiftCare pricing page and feature table (read 4 November 2026) for the vacant-shift and AI note features mentioned; the scoring grid, worked figures and sample outputs are illustrative.