Every provider has its own paperwork. A progress note shaped the way your clinical lead wants it, a handover the day team will actually read, a checklist one funder asks for and nobody else does. Most of it lives as a document emailed around, filled in inconsistently, and re-typed later by someone else.
BondiByte includes a report and form builder. You build the form in the browser, preview it, publish it, and it appears where your team already records work: on a participant, a worker, a site or a shift.
For observations recorded repeatedly over time for one participant, Client Charts add participant assignment, effective-dated configuration, an entry register and period PDFs.
Short demonstrations in the real product, using made-up data. Choose a part to watch it here.
Watch the full series on YouTube (opens YouTube in a new tab)
The Reports register: every report typed, dated and attached to the record it concerns (demo data).
Build the form the way your team reads it.
Grouped so the right one is easy to find.
A question that only appears when it is relevant.
Pick a real person, not a typed name.
The palette is deliberately short. Fourteen field types cover the paperwork providers actually run, including a repeating Table field for structured rows.
A new template starts as a draft. Nobody sees it, nothing can be written on it, and you can rebuild it as many times as you like. Preview shows exactly what your team will see. Publishing is the moment it becomes available to fill in.
A published version is fixed. When you improve the form, you edit a new draft and publish it as the next version, and every report already written keeps rendering on the version it was written on. A question you removed last month does not vanish from last month's reports.
Unpublishing takes a template out of circulation without touching anything written on it, and archiving retires it for good, with a restore if you change your mind.
Every report is written against the participant, worker, site or shift it concerns, so it is found by opening that record rather than by remembering where the file went.
The record most reports belong to.
The staff record, for the things that belong on it.
Operational records that belong to the location.
What happened on the day, tied to rostered work.
A sample of what ships with every organisation.
You do not have to build from a blank page. BondiByte ships a library of report templates covering the records providers keep most often, and they are available to every organisation from the first day.
Preview any of them to see the real form. When one is close but not quite yours, duplicate it and customise it: the copy arrives in the builder with all of its sections and fields already in place, ready to edit, rename and publish as your own.
Every template carries a category: progress note, incident, assessment, review, handover, or other. The category is not a label. It decides where the form lives.
Set a template's category to incident and it moves out of the ordinary report picker and into the Incidents area, along with every record already written on it. Staff reach it where they would look for it, and incident records stay together rather than scattered through general reports.
Because a change of category moves existing records, BondiByte asks you to confirm before it reclassifies a template, so it is never a surprise.
Building and publishing templates is restricted to the people you give permission to manage them. Everyone else simply sees the published forms in their picker: on a participant, a worker or a site record, on a shift, in the Reports register, and in Incidents.
What comes back is structured rather than a wall of free text, attached to the right record, and available when you are pulling together evidence in the Audit Centre.
Completed reports can also be downloaded as a clean PDF that keeps the report's own structure and sections, from the relevant Reports surfaces according to your permissions. Chart PDFs remain a separate download for a chosen date range of Chart entries; see Client Charts.
Incidents written up in an email drift: nobody is certain which are still open, who agreed to follow one up, or whether it happened. One register, with an owner and a due date on every follow-up, removes the reconstruction entirely.
Each incident carries its own reference, type and severity, when it occurred, the participant, the site or another location, the shift it relates to, the staff involved, what happened and the immediate action taken.
Severity levels and statuses come from your organisation's catalogues rather than a fixed vocabulary, so the register reads the way your team already speaks.
Follow-up is assigned to a person, not to a team, with the date it is due held on the record where reminders can act on it.
With incident escalation switched on, follow-ups raise reminders before they fall due, incidents left open escalate by email, and high or critical incidents notify the people you nominate straight away.
Record a complaint with who it came from and when it was received, acknowledge it, then resolve it with a written resolution. Prompt acknowledgement and resolution show up in your readiness checks.
Preparing an audit generates an incident register from these records: number, date, status, severity, summary, site, participant, follow-up detail and closure. No assembling it by hand.
No. The register captures what happened, its severity, its status and its follow-up, and produces the evidence. Whether an incident is reportable to the NDIS Quality and Safeguards Commission is a decision your organisation makes under its own policy.
Every follow-up has a named owner and a due date on the incident itself. With incident escalation switched on, reminders go out before the date, and incidents left open and unresolved escalate by email to the person who can act.
Nothing. Each completed report is held against the version of the form it was written on, so publishing a new version only affects reports written from then on.
A template typed as an incident is routed into Incidents: it opens where incidents are raised and its completed records live in the incident register. Every other type lives in Reports. Changing a template between the two moves it and its records, so it asks you to confirm.
No. There is a built-in library covering progress notes, shift reports, incident reports, assessments, behaviour support, medication, family communication, risk observations, goal progress and staff notes. Duplicate the closest one and adjust it.
Yes. Choose the shift it happened on, or record the date and time yourself where the incident falls outside a rostered shift. The participant, site or other location and the staff involved are recorded the same way.
Yes. A completed report downloads as a clean PDF that keeps the report's own sections and structure, from the relevant Reports surfaces according to your permissions. Plain notes are not report PDFs; a Report or Incident record built from a published form is what downloads this way.
Each of these has its own page: why it exists, how it works, and the controls that stay with managers.
Start your free trial, or book a demo to see the report and form builder, the built-in template library, and reports landing on the records they belong to.
Hi, I can help with BondiByte features, pricing, setup and more.
Please don’t include sensitive participant or personal information.