Hi all, sharing a demo I built with n8n + OpenAI for a dental front desk (sample data, fictional clinic).
What it does:
- Answers questions on hours, prices and treatments from the clinic’s own info
- Offers real free slots from a Data Table and books only after the patient confirms
- When someone cancels, offers the slot to the waitlist; first “YES” gets it
- Pain, swelling or emergencies: no medical advice, creates an urgent call-back for staff
- A simple staff board shows bookings, waitlist offers and urgent call-backs first
Nodes: AI Agent, OpenAI Chat Model, Window Buffer Memory, Data Table tools, Gmail tool, Webhook + Code for the board.
Biggest lesson: the system prompt rules matter more than the model. “Confirm before booking” and “never give medical advice” fixed most bad answers.
Demo video and screenshots: GitHub - ahmadjutt092008-ahma/dental-ai-receptionist: AI front desk agent for dental clinics (n8n + OpenAI): booking, WhatsApp waitlist, safe staff handover. Demo with sample data. · GitHub
Happy to answer questions or share how the tools are set up.
2 „Gefällt mir“
Nice write-up, and “confirm before booking” is a good rule. A few edge cases I’d test for the handover and missed-call side:
- Two people replying “YES” to the same waitlist offer at nearly the same moment. Make sure the slot is claimed atomically (re-check it’s still free right before writing the booking), otherwise you can double-book.
- A waitlist offer nobody answers. A short expiry, then moving to the next person, keeps the slot from sitting idle.
- Urgent call-backs with no staff acknowledgement. A reminder or escalation after X minutes would stop one from sitting unseen on the board.
- A patient who writes in again mid-conversation after the memory window has rolled over, or changes their mind after confirming.
- Callers who ring and hang up with no message: do they get an automatic text-back so they’re not lost?
(Drafted with AI help.)
Nice build. One thing to plan for: Window Buffer Memory only keeps the last N messages, so a patient’s details from earlier visits will drop off once the window rolls over.
For continuity, key the session to the patient’s normalized phone number (digits only, with country code) and use Postgres Chat Memory, so each patient gets one persistent thread across visits.
For long-term memory, I’d also keep a small patient profile: name, preferred dentist or time, last appointment and handover notes. Inject it into the system prompt on every run, so the agent starts informed instead of relying on chat history.
Also make sure the staff-handover context is saved back to that memory or profile. Otherwise the bot may re-ask questions the patient already answered once a human steps in and hands the chat back.
Disclosure: I work on MemorySync, a hosted memory layer for AI apps that handles per-user long-term memory if you’d rather not build that part.
Thanks both, really useful.
@getpeacecall good catch on the double YES. I will make the booking claim atomic (update only if the slot is still free, then check the result before confirming) and add a 30-minute expiry so an unanswered offer moves to the next person. An escalation for urgent call-backs that nobody acknowledges is a great idea too.
@memorysync agreed on keying the session to the normalised phone number. For the demo I kept Window Buffer Memory, but a small patient profile (name, preferred time, last visit, handover notes) injected into the system prompt is the next step, plus saving the staff handover back so the bot does not ask again.
Will post an update once these are in.
Thanks both, really useful.
@getpeacecall good catch on the double YES. I will make the booking claim atomic (update only if the slot is still free, then check the result before confirming) and add a 30-minute expiry so an unanswered offer moves to the next person. An escalation for urgent call-backs that nobody acknowledges is a great idea too.
@memorysync agreed on keying the session to the normalised phone number. For the demo I kept Window Buffer Memory, but a small patient profile (name, preferred time, last visit, handover notes) injected into the system prompt is the next step, plus saving the staff handover back so the bot does not ask again.
Will post an update once these are in.
The “first YES gets the slot” waitlist is the part most demos skip, nice. One race worth testing: two YES replies in the same second. If both executions read the slot as free before either writes, you double-book. Claim the slot with a single conditional update (status free → held, by slot ID) and send the second person a polite “just taken, you’re still first in line next time”.
Thanks @vishalrawat, agreed. That’s the fix I’m adding: one conditional update on the slot row (free → held, matched by slot ID), then check how many rows changed. Only the execution that actually changed the row confirms the booking; the other gets “just taken, you’re still first in line next time”. I’ll post the updated workflow once it’s tested.