Wazzy: hundreds of appointments a month and none ever booked twice
Wazzy is our appointment assistant on WhatsApp. It works in dental, physiotherapy and aesthetics clinics, it handles health data every day and it is the system where we try things first before building them for a client.
What this page covers
01 · What it is
Wazzy answers the clinic’s WhatsApp at any hour
A small clinic loses bookings for a fairly untechnical reason. The person on the desk is with somebody in front of them, and whoever writes in asking for an appointment gets no reply. Wazzy answers that message at eleven at night or in the middle of a consultation.
It books, changes and cancels appointments over WhatsApp. It leaves the calendar and the patient record up to date without anyone typing anything in the morning. It is in production in dental, physiotherapy and aesthetics clinics, and it handles hundreds of appointments a month.
A conversation like that fits in four messages. Somebody writes at half past ten at night saying they need an appointment for a cleaning, afternoon if possible. Wazzy offers two specific slots, the person picks one and the appointment is in the clinic’s calendar before anybody unlocks the door.
When the message is not a booking, the work looks more like a receptionist’s. An hour has to be moved, and “next week is not great after all” has to be understood as a cancellation. And sometimes you have to notice that whoever is writing has a pain that will not wait until Thursday. That last one the assistant does not resolve, it escalates to a person.
02 · Why we trust it
What can be checked from outside
The first version of Wazzy was an agent with tools at its disposal and we left it behind. The one in production today splits the work differently, with much more weight on the code side and considerably less on the model side. How it is put together inside is not something we are going to spell out here, among other reasons because it is not information we owe the competition. What we can show is what that decision produces.
No appointment has ever been booked twice in the whole history of the product. Not one. It is a failure you cannot fix with an apology, because when it happens there are two people at the door at the same time and one of them has to go home.
Nothing reaches production without first passing a battery of real cases with their correct answers written down. That includes what the clinic itself edits from its own panel, which does not change what the assistant answers until the battery approves it. And we pin the model version, so a provider update does not turn up on its own in production on a Tuesday morning.
On the running system there are 103 checks watching, tied to 91 named rules the system has to satisfy. And once a week a test walks the whole system end to end, booking an appointment the way a person would.
03 · Health data
An appointment at a clinic is health data
That changes the rules before a line is written. European rules set health data apart in Article 9, among the categories that cannot be processed without a listed reason. The one that covers a clinic is 9.2.h, the healthcare one.
Yes, we do store personal data. Saying otherwise would be more comfortable and it would be false. What we do is store it encrypted field by field rather than encrypting the whole store in one piece, so what gets decrypted is the field needed at that moment.
The law sets how long a medical record has to be kept, but that duty belongs to the clinic and not to us. Wazzy deletes on request everything that has no legal period over it. What does have one is kept for as long as that period lasts.
And the model does not talk to the database. The two things an assistant can get wrong here, inventing a fact or pulling somebody else’s, do not depend on the model behaving well.
04 · The scar
The emoji that closed a confirmation
No system in production is free of having done something silly. This is ours, and we tell it because a rule came out of it that we have used ever since in everything we build.
The assistant had asked somebody to confirm they were coming to an appointment, and that question stayed open for twenty-four hours. Two and a half hours later, the person replied with two emojis. The assistant read them for what they were, something that was not about the appointment, but in marking them that way it treated the confirmation as closed.
A minute later that same person wrote to say they were coming. There was nothing open left to confirm. The appointment stayed as pending, the clinic never knew they were coming and they came.
The confirmation had twenty-one hours of life ahead of it. It did not expire, an emoji killed it. Out of that came a one-line rule that now goes into everything we build. A message not being about something does not mean that something has finished. Only an action closes an action.
And we measure it, because an anecdote without a number is no use for deciding anything. Across the life of the product there are 287 confirmations that went the right way, 105 that expired with no reply and 10 that burned like that one.
05 · What you take from it
What we learn here ends up in your project
Wazzy is the only system of ours where we are the ones who pay when something goes wrong. That is why it is where we try things first. Almost everything we know about what breaks in a conversational assistant, we know because of it. That learning arrives at client projects already done.
A client does not buy Wazzy. Wazzy belongs to a clinic and to its appointments. What we build for another company is built for that company’s problem. What carries over from here is the method, which is the tests in front of every change and the discipline of not leaving a model a decision the code can make.
Do you want one like this for your company?
Tell us your challenge and we reply within one business day. If we don’t see a return, we’ll tell you.