WhatsApp-Buchungs-Bot fuer Friseur im Sueden
Erstes Friseur-Projekt — Greenfield-Aufbau eines AI-Agent-gestuetzten Buchungssystems via WhatsApp. Cal.com als Backend, Cal.com-MCP als wiederverwendbare Branchen-Komponente, Meta WhatsApp Cloud API als Transport, Claude Sonnet als Agent-Hirn.
Status 2026-05-13: Kauf-Zusage von Arne liegt vor. Konditionen + Service-Katalog werden im Setup-Call finalisiert. Bau-Phase startet erst nach Auftragsbestaetigung.
Ziel
- Telefon-Entlastung: Termin-Annahme, Stornierung, Auskunft komplett ueber WhatsApp, ohne Mitarbeiter zu unterbrechen
- No-Show-Reduktion: Automatische Termin-Erinnerung 24h vorher via WhatsApp Utility-Template
- 24/7-Erreichbarkeit: Buchung auch nach Ladenschluss moeglich
- Wiederverwendbare Branchen-Komponente: Cal.com-MCP wird Asset fuer alle weiteren Salon-/Termin-Dienstleister
Phasen
| Phase | Inhalt | Status |
|---|---|---|
| 0 — Discovery | Setup-Call (60-90 Min vor Ort), Service-Katalog erfassen, Mitarbeiter + Buchungs-Volumen klaeren, Meta-Business-Status pruefen, Konditionen finalisieren | offen — kommt nach Test-Phase |
| 1 — Angebot + Vertrag | Festpreis-Angebot mit Phase-1-Notausgang, Unterschrift, Papierkram-Anlage | offen |
| 2 — Bau MCP-Schicht | Cal.com-MCP (✅ 10 Tools live), WhatsApp-MCP (✅ 15 Tools auf AWS Fargate live), Friseur-Account verifiziert + Outbound-ready | ✅ durch (2026-05-14) |
| 2b — Brain (Agent-Loop) | EventBridge-Cron oder Webhook-Trigger → Lambda → Claude API + beide MCPs → autonomer Bot-Loop. System-Prompt mit Salon-Daten + Service-Katalog | aktuell — Next-Session-Prompt: next-session-prompt |
| 3 — WhatsApp-Onboarding fuer Arne live | Arnes eigenes Business-Portfolio, Handelsregister-Verifizierung, eigene Phone-Number, Template-Approval (Bestaetigung + Erinnerung) | offen — kommt nach Demo |
| 4 — Test + Pilot-Mitarbeiter | 2 Wochen Schatten-Modus mit Pilot-Mitarbeiter, Bot prueft Antworten gegen reale Buchungen | offen |
| 5 — Go-Live | Kommunikation an Stammkunden (Vorlage + Aushang), Bot-Nummer aktiv, Buch nur noch als Fallback | offen |
| 6 — Stabilisierung + Lessons | 4-Wochen-Phase-1-Notausgang-Fenster, Beobachtung, Bug-Fixes, Lessons in intern/wissen/patterns/ festhalten | offen |
Vereinbarter Tech-Stack (Vorschlag, im Setup-Call zu bestaetigen)
Quelle: report — Markt-Recherche zeigt Cal.com als einzigen sinnvollen Default (Webhooks + REST API), DACH-SaaS-Konkurrenz hat keine offene API.
| Baustein | Wahl |
|---|---|
| Buchungs-Backend | Cal.com (gehostet, Teams-Plan, ~$12/User/Mo) |
| MCP-Schicht | Cal.com-MCP (Eigenbau, FastMCP-Pattern, 2-3 Tage) |
| WhatsApp-Transport | Meta WhatsApp Cloud API direkt |
| Agent-Hirn | Claude Sonnet 4.6 + Prompt-Caching (Salon-System-Prompt, Services, Mitarbeiter) |
| Hosting | AWS av-production, Lambda + DynamoDB fuer Konversations-State |
| Plan B | Easy!Appointments self-hosted (GPLv3) wenn Cal.com zu generisch wirkt |
Architektur-Skizze siehe vorgeschlagener-tech-stack-im-setup-call-zu-bestaetigen.
Bot-Konventionen
Regeln fuer alle Bot-generierten Texte (WhatsApp-Replies, spaeter auch Templates + Erinnerungen). Wird im Brain-Lambda-System-Prompt einzementiert sobald Variante 2 startet.
- Echte Umlaute Pflicht. Im Content immer
ä ö ü ß, nieae oe ue ss. Letzteres ist Vault-Filename-Konvention und gilt NICHT fuer External-Output. CLAUDE.md Regel 15. - Salon-Voice, nicht Ich-Voice. Der Bot ist kein „ich” — er spricht als Salon (
„wir"/„der Salon"). Beispiele: „wir verschieben den Termin gerne”, „der Salon hat Mo-Fr 9-17 Uhr geoeffnet”. Keine Mitarbeiter-Identitaeten anlegen („Hallo, hier ist Lisa”) bevor Arne Mitarbeiter-Namen freigegeben hat. - Keine Em-Dashes, keine Ausrufezeichen-Ketten. Normale Bindestriche, hoechstens ein Ausrufezeichen pro Nachricht.
- Antwort-Laenge passend zur Frage. Slot-Vorschlaege: kurz, mit Service + Dauer als Kontext. Bestaetigung: Tag + Uhrzeit + Service + Bestaetigungs-Pfad (Mail). Keine doppelten Erklaerungen.
- Geschlossen-Tag transparent benennen. Bei Anfrage fuer Wochenende/Feiertag nicht stillschweigend Mo vorschlagen — kurz erklaeren warum, dann Alternative.
- Bei Email-Pflicht: gezielt nachfragen. Cal.com verlangt Email beim Booking (Bug 2 unten). Bot muss vor
create_bookingggf. Email einsammeln, sonst fallback auf phone-derived Placeholder<phone>@whatsapp.friseur-im-sueden.de.
Bekannte Bugs / TODOs vor Variante 2 (Brain-Lambda)
Aufgesammelt beim manuellen Variante-1-Durchlauf am 2026-05-15.
mcp-calcom: Defaultcal-api-version: 2026-02-25gibt 404 auf List-Routen (/event-types?username=...und/slots). Workaround in Variante 1:raw_getmitapi_version="2024-06-14"(event-types) bzw"2024-09-04"(slots). Brain-Lambda braucht entweder fixe API-Version-Defaults oder Fallback-Logik. spawn_task-Chip ist raus.mcp-calcom create_booking: Docstring sagt „Email ODER Phone Pflicht”, real ist Email zwingend Pflicht. Brain-Lambda muss Email aktiv abfragen oder Placeholder bauen. Mit zum spawn_task vom Punkt 1.mcp-whatsappInbox-DB ist ephemer.WHATSAPP_INBOX_DBnicht gesetzt, kein Volume gemounted →~/.local/share/mcp-whatsapp/inbox.dbist auf Container-FS. Bei jedem Container-Restart sind alle nicht-prozessierten Nachrichten weg. Brain-Lambda muss Messages SOFORT pollen + verarbeiten ODER Inbox auf EFS / DynamoDB umstellen. Bevorzugt: DynamoDB-Backend mit dem gleichen Schema (wamid PK).- ECS-Container reloaded Secrets nicht zur Laufzeit. Behauptung im Troubleshooting-Block des next-session-prompt war falsch. Bei jeder Token-Rotation:
aws ecs update-service --force-new-deploymentnach dem Secret-Update. Im Hosting-Pattern dokumentieren. mcp-whatsapp send_interactive_buttons: Title max 20 Zeichen, ID max 256 — aktuell genutzt: ID-Formatbook|<event_type_id>|<ISO-Start>. Brain muss IDs deterministisch encodieren damit Click-Parser den Slot wiederfindet. Funktioniert in Variante 1 — Festschreiben als Konvention.
Vorgeschlagenes Pricing
- Setup einmalig: 3.900 € netto
- Monatlich: 149 € netto all-in
- Phase-1-Notausgang: nach 4 Wochen Pauschal 1.500 € — Pattern festpreis-phase1-notausgang
Details + Begruendung: vorgeschlagenes-pricing-im-setup-call-zu-bestaetigen.
Risiken + Annahmen
| Risiko | Mitigation |
|---|---|
| WhatsApp-Onboarding bei Meta dauert laenger als 5 Tage (kein Handelsregister-Eintrag, Verifizierungs-Probleme) | Phase 3 parallel zu Phase 2 starten, nicht sequentiell. Im Notfall Twilio-Sandbox als Brueckenloesung |
| Arne hat keine strukturierte Service-Liste, Daten-Erfassung wird langwieriger als 60 Min | Discovery-Termin auf 90 Min ansetzen, eigene Vorlage mitbringen (Excel-Template fuer Service + Dauer + Preis) |
| Stammkunden weigern sich zu WhatsApp zu wechseln, Bot wird nicht angenommen | Kommunikations-Vorlage liefern (Aushang + Postkarte), Telefon bleibt als Zweit-Kanal verfuegbar |
| Cal.com-Teams-Plan ($12/User) macht Margen-Rechnung kaputt wenn mehr als 3 Mitarbeiter | Im Setup-Call Mitarbeiter-Zahl klaeren. Falls >4: Easy!Appointments self-hosted als Alternative pruefen |
| Cal.com-MCP-Bau zieht sich laenger als 3 Tage (Auth-/Webhook-Quirks) | Anstossen sobald Auftrag bestaetigt, eigener Test-Account vor Salon-Daten. mcp-eigenbau-Skill kennt Pattern |
| Phase-1-Notausgang wird gezogen, 1.500 € decken Cal.com-MCP-Bau nicht | Akzeptiert — Cal.com-MCP ist Asset fuer naechste Salons, also kein Verlust |
Offene Punkte (alle aus Setup-Call)
Siehe offene-punkte-fuer-setup-call-mit-arne — komplette Liste der 9 Fragen vor Vertragsunterzeichnung.
Naechste Schritte
- Setup-Call mit Arne terminieren — Telefon 02381 3713526 oder Stippvisite. Bevorzugt vor Ort, 60-90 Min. Innerhalb 1 Woche
- Setup-Call-Vorbereitung: Service-Erfassungs-Template (Excel oder einfache Liste) mitbringen, Beispiel-Cal.com-Buchungsseite zeigen, Kommunikations-Mockup
- Nach Setup-Call: Festpreis-Angebot finalisieren, ueber
email-schreiben-Skill rausschicken (oder vor Ort uebergeben) - Bei Vertragsunterzeichnung: Phase 2 + 3 parallel starten —
mcp-eigenbaufuer Cal.com-MCP, WhatsApp-Onboarding via meta business help - Vault-Pflege: Setup-Call-Notizen in
intern/meetings/2026-MM-DD--setup-friseur-im-sueden.mdablegen
Verlauf
| Datum | Ereignis |
|---|---|
| 2026-05-13 | Lead erfasst via Google-Business-Profil, Markt-Recherche gestartet |
| 2026-05-13 | Kauf-Zusage von Arne. Lead → Kunde, Projekt angelegt. Discovery-Phase laeuft |
| 2026-05-13 | calcom gebaut lokal (10 Tools), Cal.com-Account marvin-gqurrj mit 8 Friseur-Services live |
| 2026-05-13 | whatsapp gebaut lokal (15 Tools, integrierter Webhook, SQLite-Inbox) |
| 2026-05-14 | mcp-whatsapp auf AWS Fargate deployt: ECR + 2 Secrets + Cloudflare-Tunnel a3af8b46... + DNS mcp-whatsapp.agenticventures.de. Erster MCP der Fargate-Tunnel-Pattern voll in agenticventures.de live nutzt |
| 2026-05-14 | Meta-Marathon: erster Account (Test-WABA) hart-gelocked wegen Payment+Verification+Commerce-Check (3 Bloeckungen). Pivot zu Friseur-im-Sueden-Account (889608426871476, App 988192143605811) der verifiziert + Outbound-ready ist |
| 2026-05-14 | End-to-End-Round-Trip durch: User-WhatsApp → Webhook → Inbox-Insert + Bot-Reply → Status sent. Service-Window-Regel bestaetigt (24h ab User-Erstkontakt). Lessons in meta-whatsapp-account-onboarding |
| 2026-05-15 | Hosting-Fix mcp-whatsapp: Production-Endpoint gab 421 Invalid Host header zurueck (FastMCP DNS-Rebinding-Schutz, Default-Allowlist nur 127.0.0.1/localhost). Fix per Env-Var MCP_ALLOWED_HOSTS=mcp-whatsapp.agenticventures.de + Server-Patch der transport_security.allowed_hosts/allowed_origins erweitert. CDK-Redeploy gruen (392s), Smoke gegen /mcp jetzt HTTP 200. Lesson in mcp-hosting-fargate-tunnel |
| 2026-05-15 | MCP-Setup in Claude Code: whatsapp MCP via claude mcp add registriert (Connected). cal.com-MCP lokal auf 127.0.0.1:8770 hochgefahren. Bereit fuer Variante 1 nach Session-Restart |
| 2026-05-15 | Token-Rotation + Variante 1 gruen. WhatsApp-Token vom 14.05. expired, neuer Token in Secret + ecs update-service --force-new-deployment auf McpWhatsappHosted-ServiceD69D759B-HuB3n6EMF0qS. End-to-End-Bot-Loop manuell durchgespielt: Inbound „Termin Waschen, Schneiden, Foehnen morgen Nachmittag?” → Salon Sa zu → 3 Slot-Buttons fuer Mo 18.05. (13:30 / 14:15 / 15:00) → Klick → Cal.com Booking 19634787 status accepted → Bestaetigung. 5 Bugs/Konventionen erfasst (siehe „Bekannte Bugs”-Abschnitt oben). Variante 2 (Brain-Lambda) ist next |
| 2026-05-15 | Plattform-Pivot zu receptionist. Marvin entscheidet: nicht Friseur-spezifisches Brain, sondern Multi-Tenant-Plattform fuer Friseure + Restaurants + weitere KMU. Friseur im Sueden = Customer 1. Neue Capability receptionist. Brain-Lambda + 4 DDB-Tables + Vertical-Adapter-Pattern + Hairdresser-System-Prompt deployed. Smoke blockt aktuell auf Cloudflare-Access-Service-Token (Pilot-must „Auth fuer hosted MCPs” wurde parallel durch Audit-Hardening eingebaut, Brain-Code ist CF-Access-aware, Secret muss noch angelegt werden). 2b.1-2b.3 + Brain-Lambda komplett |
Related
- receptionist — Plattform-Capability die dieser Customer als Customer 1 nutzt
- friseur-im-sueden — Kunden-Stammdaten, Pricing-Vorschlag, Offene Punkte
- report — Markt-Recherche DACH Buchungssysteme
- festpreis-phase1-notausgang — Pricing-Pattern mit Ausstiegs-Option
- SKILL — Skill fuer Cal.com-MCP-Bau
- mcp-hosting-fargate-tunnel — Hosting-Pattern (hier Lambda-Variante)
- produkt-bundle — Custom-Phase-A-Modell