What does Cliniko handle well on its own?
Appointments, patient records, clinical notes, invoicing and reminders — the core of running a practice. For most clinics, the system is not the bottleneck.
It also has one property that matters a great deal if you ever want to extend it: a public, well-documented API with a broad third-party ecosystem. In practice that means new tools tend to support Cliniko first, and bespoke work is straightforward rather than a reverse-engineering exercise.
So where does the manual work usually sit?
In the space between Cliniko and everything else — the phone, the inbox, the referral pile, the waitlist and whatever spreadsheet has quietly become load-bearing.
The patterns we see most often in Australian allied health clinics:
- Referrals arriving as email, PDF or fax that someone retypes into Cliniko, usually twice a day, usually late.
- Cancelled appointments that nobody has time to backfill from the waitlist.
- Funding plans quietly expiring because nothing watches session counts against a plan's end date.
- Patients who stopped coming and were never followed up, because reactivation is nobody's specific job.
- Reporting that gets assembled by hand at month end from several places at once.
None of these are Cliniko's failings. They are the seams between systems, and seams are where the manual work collects.
What does building on Cliniko actually involve?
Reading and writing through its API, with a person approving anything that touches a patient — and scoping the work to one process rather than all of them.
We start by sitting with your team and following how the work actually moves, pick the single most expensive manual process, and build only that. Patient information stays in Cliniko; we do not build a second copy of your database. Every automated action has someone who approves it and a record of who did.
Will this break when Cliniko updates?
A documented public API is precisely what makes that unlikely, which is part of why we prefer building on systems that have one.
Anything we build gets monitored, and support is part of the arrangement rather than an afterthought. If something does break, it should be us noticing rather than your front desk.