Availability and recalls
A cancellation becomes an offer sent to an approved list, and the administrative recall for a next visit goes out on the practitioner decision.
Cliniko
Cliniko documents booking, updating and cancelling. Access rights are those of the account that opens it — and until it is open, the request is written into Zenvox.
7 days, 20 answered calls, no card
Where your request lands
The request is written into Zenvox: patient, discipline, appointment type, expected duration and workable time ranges. While no access is open, nothing is written into Cliniko and your software keeps the truth of the schedule. The route does exist and it is written down: booking, updating and cancelling are documented by the vendor. What is missing is an authenticated trial from a real account.
Access uses a key attached to one user, against an endpoint tied to the shard hosting your account. One consequence, rarely spelled out: key rights equal the rights of the user who creates it — a key taken from a practitioner account gives that practitioner view. It is created from your account and revoked whenever you want; until it exists, the receptionist works in native mode.
Cliniko is clinic management software used by osteopaths, massage therapists, physiotherapists and by clinics running several disciplines through shared rooms. Its technical documentation is public, which is rare: it describes a model of patients, practitioners and businesses, and behaviour on a scheduling conflict.
Read, create, update, cancel
The status below comes from vendor documentation re-read at checking time, and from the fact that no authenticated trial has yet been recorded from Zenvox.
| Action | Status | What that means |
|---|---|---|
| Read | To qualify | Patients, practitioners and businesses are described by a documented interface. Finding a patient and reading practitioner availability is a written route; it has to run with a real key, against the right hosting shard, before being announced. |
| Create | To qualify | Creating an individual appointment is documented, including refusal on conflict. Repeated sends of the same message, duration per session type and room constraints still have to be proven; none of that follows from a schema. |
| Update | To qualify | Updating an existing appointment is described. Two simultaneous requests on one slot, though, have to be tested: without that test, the receptionist moves nothing and prepares the request for your team. |
| Cancel | To qualify | Cancelling is documented. Sync strategy and the reminder events your software already sends remain to be checked, to avoid the classic defect: one patient receiving two reminders, one from the clinic and one from Zenvox. |
What is included, what needs an add-on
Answering during a treatment, qualifying, telling a first consultation from a follow-up, noting a practitioner preference and handing you the request belong to your healthcare base. A connection removes re-keying; it adds no capability. Waitlists and coordination across a multi-session, multi-room or multi-practitioner pathway are named add-ons.
The authorisation, and what holds the truth
A key is created, limited and revoked. These points are the condition of a clean install, and they get decided before the first connection.
- The key is created from your account, on the user whose rights you want — Zenvox asks for no password
- Key rights equal that user rights: a restricted key gives a restricted integration, and that is a decision, not a side effect
- A system of record is set per object — patient, appointment, practitioner — so one piece of data has one truth
- You revoke the key whenever you want: the receptionist returns to Zenvox native mode and service carries on
- Reminders your software already sends are inventoried before install, so each patient gets one
A known patient calls back for a follow-up. Reading is being qualified, writing too: the receptionist prepares, she does not enter.
PatientHi, I would like another appointment with the same osteopath I saw last time.
ReceptionistHappy to help. Let me confirm your name and date of birth first, then I note that you want continuity with the same practitioner.
ReceptionistWhich time ranges suit you best? I am passing your request to the clinic; they confirm the slot, I do not book it myself.
The request reaches the clinic with the patient identified, the practitioner requested, the session type and two workable time ranges. The clinic enters it, then confirms. On the day creation is proven against a real account, that same conversation ends with a written appointment — and you change nothing.
When the connection is not there
A missing key blocks nothing. The receptionist works in native mode and you pick the request up where you already work.
- The request is created inside Zenvox with the same fields and the same qualification
- You find it in the app, with transcript and reason for calling
- Your clinic online booking link is texted out when one exists
- No capability in your base depends on third-party software
- The day an operation becomes qualified, it is added without redoing your setup
Questions about this connection
Does Cliniko let Zenvox book?
The route is documented by the vendor — booking, updating and cancelling are all described — and what is missing is the authenticated trial from a real account. Until it has run, the receptionist prepares the request and the clinic enters it.
What rights does the key carry?
Exactly those of the user who creates it: a key taken from a practitioner account gives that practitioner view. That is a decision to make before install, not a side effect, and the key is revoked whenever you want.
Will my patients get two reminders?
Reminders your software already sends are inventoried before install, so each patient gets one. Sync strategy and the reminder events your software sends remain to be checked, and that is the classic defect being kept out.
What if two people ask for the same slot?
Refusal on conflict is documented, but two simultaneous requests on one slot have to be tested. Without that test, the receptionist moves nothing and prepares the request for your team.
What works while the key does not exist?
Everything about reception: answering during a treatment, telling a first consultation from a follow-up, noting a practitioner preference, texting out your online booking link, and handing you the request with the transcript and the reason for calling.
Where to next
See the practice concerned, or the full list of software studied.
Cliniko