AI WhatsApp Bot in 15 days: real case, architecture and pricing (2026)

A dental clinic in Valencia with 4 chairs reached out with a clear problem: they lost 28% of appointments because when a patient called outside business hours nobody picked up, and when they called back the next day the patient had already booked elsewhere. Plus 6h/week of the receptionist answering the same 8 questions: hours, prices, emergencies, parking. The solution they asked for sounded magic: an AI WhatsApp bot that understood patients, booked the appointment in the calendar, and filtered real emergencies.

We delivered it in 15 days for €3,200 (not counting the fixed maintenance fee, €180/mo). This post explains exactly how we did it, what went wrong, and what we'd change today. The P&L at 3 months: -60% no-shows, +30% new patients captured, receptionist freed 5h/week for actual management, full ROI in 2.5 months.

Technical architecture (no fluff): official WhatsApp Business API via a BSP provider (360dialog, €25/mo + per-conversation cost when initiated by the clinic, ~€0.03 per outbound message) → webhook that receives incoming messages and passes them to a self-hosted n8n workflow on Hetzner (€5/mo VPS) → the workflow calls Claude (Haiku to classify intent, Sonnet for complex answers) → Claude queries the client's Google Calendar via API, replies and logs in Supabase (free plan up to 500MB) → if it detects a real emergency (fever, acute pain, trauma), it notifies the on-call dentist via Twilio SMS. The whole stack cost the client about €60-90/mo depending on volume, versus the €800/mo Aivo or Landbot would have charged for equivalent functionality.

Day 1-3 — Discovery and flow design: two sessions with the owner + receptionist. We mapped the 12 most frequent conversations: new appointment, reschedule, cancel, price of filling/cleaning/implant, hours, location, parking, emergencies, doubts about ongoing treatment, reminders, payment, invoice. From that came 4 main intents (appointment, info, emergency, other) and a simple decision tree. We documented prices and policies in a Notion that later became the RAG knowledge base.

Day 4-6 — WhatsApp Business API + n8n + Claude: number registration in 360dialog (24-48h Meta verification), n8n installation in Docker (one afternoon), connection of the WhatsApp inbound webhook to n8n, first "hello world" flow. Claude API connection: system prompt with the clinic's personality (warm but professional tone, no excessive emojis, route emergencies in fewer than 2 messages). We spent 1 day polishing the prompt — the secret was giving it real few-shot examples from the receptionist, not abstract instructions.

Day 7-9 — RAG with the knowledge base + calendar integration: we indexed the Notion in a simple vector DB (Supabase pgvector, more than enough for 80 documents) with Voyage embeddings. When a patient asks "how much is a filling?", Claude searches the base, finds the current price, replies in natural tone and adds the caveat that the final price depends on the review. Google Calendar integration via OAuth, function to create/cancel/find appointments. Here came the first scare: Claude invented a price for a treatment that wasn't documented. Fix: explicit instruction in the prompt "if you can't find the data in the base, DON'T invent, route to the clinic" + automatic post-response verification.

Day 10-12 — Emergency detection + human handoff: classifier with Haiku (cheaper and faster) that scores every inbound message 0-3: 0 informational, 1 appointment, 2 incident, 3 emergency. If score=3, the bot replies "I'll alert the on-call dentist" and fires SMS to the owner via Twilio. If the patient writes "I want to talk to a human" or the bot loses the thread twice in a row, immediate handoff. This is CRITICAL — without handoff, patients lose patience and the bot loses credibility.

Day 13-14 — Testing with real patients (silent mode) + adjustments: we routed the bot to 20 recurring patients who already knew the clinic. We collected the 14 complaints and fixed them: tone too formal, didn't understand "empaste" in Valencian, gave prices with VAT when local convention was without VAT, didn't know they closed during Fallas. Each fix = 30 min in the prompt or knowledge base.

Day 15 — Go-live + metrics dashboard: public activation, pinned message on Instagram and Google Business announcing the new channel. Simple Metabase dashboard for the owner: conversations/day, % auto-resolved, appointments created, emergencies escalated, average response time. First week: 47 conversations, 38 auto-resolved (80%), 9 escalated to human, 0 serious incidents.

What I'd change today if redoing it: I'd invest 2 more days in the prompt and the knowledge base — week 1 findings were all about missing context, not technical bugs. Also: start with n8n cloud (€20/mo) instead of self-hosted, so the client can maintain it alone if they leave the service. And add from day 1 a light fine-tuning of the classifier with their own data instead of generic Haiku — it would halve cost per conversation.

Indicative pricing for your sector (based on similar 2026 SprintMarkt projects): standard dental/medical/veterinary clinic (1 number, 1 calendar, ~30 intents): €2,500-3,500 setup + €150-220/mo. Legal practice / consultancy (more legal nodes, lawyer escalation): €3,500-4,500 + €200/mo. Restaurant with bookings and dynamic menu: €2,500-3,200 + €130/mo. Real estate with property catalog + lead screening: €4,000-5,500 + €250/mo. Pricing includes 15-day setup, 1 month of post-launch support and 2 prompt-tuning sessions in the first 3 months.