WhatsApp AI Reception Operator
Pre-launch
A customer messages a business’s WhatsApp number the way they already do. The assistant answers in whatever language they wrote in, checks the real calendar, and books, moves, or cancels the appointment. When it cannot cope, it stops and hands the conversation to a person, with everything the customer said already on screen.
The thing being built is not a chatbot. It is the front desk answering after hours and during the rush, without the owner hiring for it.
The problem
Small appointment businesses in Malaysia already take bookings over WhatsApp, informally. Salons, barbers, physiotherapy practices, pet groomers, tuition centres. The person who answers messages is usually also serving a customer, so messages wait. A missed message is not a slow reply, it is a lost booking.
Most of these businesses keep a plain Google Calendar rather than a practice management system. That is deliberate as a starting point, not a limitation to work around later.
How it works
A message arrives on the business’s WhatsApp number and is routed by the number it came in on. The assistant reads the business’s own configuration: services, durations, prices, buffers, and per-weekday opening hours. It checks the real calendar, offers only genuinely free slots inside opening hours, and writes the booking.
Customers are recognised by phone number, so rescheduling and cancelling need no reference codes. The assistant learns a customer’s name once at first booking and never asks again.
The decisions that shaped it
Postgres owns the bookings; the calendar is a mirror. A booking is a database row. The calendar event exists so the business sees it where they already look. Moving an event by hand in Google does not corrupt anything, and the product can later support businesses whose calendar is not Google.
Every external service sits behind an interface. Nothing outside the LLM module knows which model is running, nothing outside the calendar module knows it is Google, nothing outside the messaging module talks to the WhatsApp provider. Swapping any of the three is a contained change rather than a rewrite. That is what makes “we can move you off Google Calendar later” an honest thing to say to a customer.
The assistant sees a bounded slice of the conversation, not all of it. Feeding back the whole transcript taught the model to imitate its own failures. That was a real production incident, where it began escalating instead of booking because its recent history was full of escalations. It now sees a capped, recent window with canned holding messages excluded.
Storage and memory are different things. The full transcript is kept for the owner. What the model reads is deliberately much smaller. Durable memory is the bookings table, queried on demand, rather than a summary of old chat.
A human’s words are never fed back as the assistant’s own. When a person takes over and hands back, their messages reach the model as a labelled block: a colleague promised this, do not contradict it, do not copy their style.
Delivery is confirmed, not assumed. The provider returning HTTP 200 means accepted, not delivered. Drops are reported afterwards on a separate webhook. The transcript says delivered only when a phone actually has the message. This was found by a message that vanished silently in testing.
What it deliberately does not do
Stated plainly, because overclaiming here creates support tickets on day one.
- No payments or deposits. It books; it does not take money.
- No staff selection. A customer cannot request a specific person.
- No product or stock questions. It knows services, durations, prices, and hours. Nothing else.
- No outbound marketing. It answers; it does not broadcast.
- No reminders yet.
- No voice. Text only. Images, audio, and location messages are acknowledged, not understood.
- No reply after 24 hours of silence. Meta forbids free-form business messages outside a 24-hour window from the customer’s last message, so past that a person has to phone instead.
Status
Pre-launch. The architecture is built and exercised against production: real bookings created and verified against both the database and the calendar, a full human handover cycle including hand-back, and delivery confirmed from Meta’s own receipt. The test suite runs against a real Postgres branch rather than mocks.
What it is waiting on is external. A production WhatsApp Business Account requires Meta business verification and display-name review, both on someone else’s timeline, and neither shortened by anything on our side.