Recalls and continuity
The periodic recall decided by the clinic, rebooking and the waitlist: the owner reply is received, and exceptions go up to a person.
Provet
Provet documents clients, patients and consultations. The request is written into Zenvox, and the exact create operation still has to be confirmed against the real schema.
7 days, 20 answered calls, no card
Where your request lands
The request is written into Zenvox: owner, animal, reason, urgency under the clinic protocol, workable time ranges. Provet keeps the truth of the record. Booking examples appear in its documentation, but a feature catalogue is not proof that every act can run from outside: the exact create and cancel operation still has to be confirmed against the real schema.
On access, documentation describes a partner request then a sandbox, and also allows a clinic to ask for its own access. Until that access is obtained there is nothing to install, and no key is asked of you. The clinic keeps its software as the single truth, and the receptionist works in native mode.
Provet separates the client, the patient and the consultation — the same owner and animal split that stops two cats from one household being mixed up; clinical questions go to the team instead of being handled on the phone.
Read, create, update, cancel
The status below comes from documentation re-read at checking time, and from what has not yet run against a real account.
| Action | Status | What that means |
|---|---|---|
| Read | To qualify | Clients, patients and consultations are exposed by a described interface. Finding an owner and their animal is the first operation to qualify, because everything else depends on it. |
| Create | To qualify | Booking examples appear in the documentation, but the precise operation has to be confirmed against the schema: authorised service, resource, duration and permissions. Without that, the receptionist prepares and the clinic enters. |
| Update | To qualify | Outbound events are documented for additions and changes; their triggers and actual delivery remain to be confirmed. An update driven with no delivery guarantee creates two truths, and that is exactly what gets refused here. |
| Cancel | To qualify | Cancelling carries the same condition, with retry behaviour to verify. Meanwhile it is taken, time-stamped, passed on, and it feeds your recalls with no automatic write. |
What is included, what needs an add-on
Answering, separating owner from animal, applying the clinic emergency rule, routing a refill for approval and sending the summary sit in your veterinary base. Follow-up recalls and coordinating a referral between teams are named add-ons.
The authorisation, and what holds the truth
Two paths lead to access, and the shorter one differs depending on whether you are one clinic or a group.
- A clinic can request its own vendor access; Zenvox asks for no password and does not sign in on your behalf
- The partner path goes through a request then a sandbox, where each operation runs before being announced here
- Your software stays the system of record for the animal file: a request passed on is not an open consultation
- The veterinarian keeps the clinical decision and the explanation of care; the receptionist records, she does not advise
- You withdraw access whenever you want; service carries on in Zenvox native mode
Lunch hour, one person on the front desk and already on a call. The second call is taken by Zenvox; nothing is written into the software.
OwnerHi, I am down to two servings of my cat prescription food. Can I reorder?
ReceptionistLet me take your name, a callback number, and your cat name. Which product exactly, and how long has she been on it?
ReceptionistI am routing this to the veterinarian for approval. I cannot confirm a refill myself; the clinic gets back to you with the answer.
The request lands filed in the approval queue, with owner, animal, product and reported time on it. The front desk was not interrupted, and nothing was promised to the owner that the veterinarian had not approved.
When the connection is not there
The clinic keeps its software as the single truth and the receptionist works in Zenvox native mode.
- The request is created inside Zenvox, owner and animal kept apart as they are on file
- Emergencies follow your protocol and raise the alert, connected or not
- Refills are captured and filed into the veterinarian approval queue
- Referrals keep their documents attached, ready for the receiving team
- The day an operation becomes qualified, it is added without redoing your setup
Questions about this connection
Booking examples exist — is that enough?
No. A feature catalogue is not proof that every act can run from outside: the exact create and cancel operation still has to be confirmed against the real schema, with authorised service, resource, duration and permissions.
Can the clinic request its own access?
Yes, the documentation allows it, alongside the partner path that goes through a request then a sandbox. Zenvox asks for no password and does not sign in on your behalf.
Why not drive updates right away?
Because the triggers of the outbound events and their actual delivery remain to be confirmed. An update driven with no delivery guarantee creates two truths, and that is exactly what gets refused here.
Does the receptionist answer clinical questions?
No, she records, she does not advise. The veterinarian keeps the clinical decision and the explanation of care, and clinical questions go to the team instead of being handled on the phone.
What does a referral gain with no connection?
Its documents stay attached, ready for the receiving team. Sending and accepting are two different things: a referral holds when documents are collected and the receiving team confirms it has taken over.
Where to next
See the practice concerned, or the full list of software studied.
Provet