Auf einen Blick
ProjektProduktentwicklung, Fragon StudiosBrancheSaaS / DienstleistungsbetriebeTechnologien.NET 10, Blazor Server, PostgreSQL, Redis, WhatsApp Cloud API, Telegram Bot API, Jambonz, Piper TTS, Whisper STTErgebnisVollautomatische Terminbuchung über drei Kanäle, betriebsfertig ab ca. 2 Euro pro Tenant pro Jahr
Die Ausgangssituation
Barbershops, Restaurants, Wellness-Studios, Arztpraxen: Sie alle haben das gleiche Problem. Kunden rufen an oder schreiben WhatsApp-Nachrichten, um Termine zu vereinbaren. Das bindet Personal, führt zu verpassten Anfragen außerhalb der Öffnungszeiten und kostet den Betrieb bares Geld.
Bestehende Buchungssysteme lösen das Problem nur teilweise. Entweder setzen sie auf eine eigene App (die niemand installieren will), eine Website (die der Kunde erst finden muss), oder sie unterstützen nur einen Kanal. Keines der uns bekannten Systeme konnte WhatsApp, Telegram und Telefon gleichzeitig abdecken und dabei echtes Multi-Tenancy bieten, bei dem jeder Betrieb seine eigenen Credentials und Konfigurationen mitbringt.
Die Herausforderung
Drei Kanäle, ein System
Die Lösung muss Buchungen über WhatsApp, Telegram und Telefon abwickeln. Das klingt zunächst nach drei separaten Integrationen, aber die eigentliche Komplexität liegt woanders: Der Buchungsflow muss auf allen Kanälen identisch funktionieren, obwohl die Interaktionsmodelle grundverschieden sind. WhatsApp und Telegram arbeiten mit Buttons und Menüs, das Telefon mit Sprache.
Echtes Multi-Tenancy
Die meisten "Multi-Tenant"-Buchungssysteme teilen sich einen WhatsApp-Account oder speichern API-Keys in Umgebungsvariablen. Das bedeutet: Ein Deployment pro Betrieb. Bei 50 Betrieben hat man 50 Server zu warten. Wir brauchten eine Architektur, bei der ein einzelnes Deployment hunderte Betriebe bedient, jeder mit seinen eigenen WhatsApp-, Telegram- und Kalender-Credentials.
KI-Kosten unter Kontrolle
Ein KI-gestütztes System, das jede Nachricht durch ein Large Language Model schickt, wird schnell teuer. Besonders wenn man bedenkt, dass die meisten Buchungsanfragen einem vorhersehbaren Muster folgen: Service wählen, Datum wählen, Uhrzeit wählen, bestätigen.
Self-Hosted Voice
Für den Telefonkanal brauchten wir Speech-to-Text und Text-to-Speech. Cloud-Dienste wie Google Speech oder Amazon Polly wären die einfache Lösung gewesen, kosten aber pro Minute und schaffen eine weitere externe Abhängigkeit. Für ein System, das wirtschaftlich mit hunderten Tenants skalieren soll, war das nicht tragbar.
Unsere Lösung: BookingBot
BookingBot ist ein vollautomatisiertes Terminbuchungssystem, das als einzelner Docker-Stack deployt wird und beliebig viele Betriebe bedient.
Menübasiert statt KI-intensiv
Die wichtigste Designentscheidung: Der Buchungsflow ist menübasiert. Kunden klicken sich über Buttons durch die Buchung (Service, Mitarbeiter, Datum, Uhrzeit, Bestätigung), statt Freitext zu schreiben. Die KI kommt nur dann zum Einsatz, wenn ein Kunde trotzdem Freitext schreibt oder am Telefon spricht.
Das reduziert die KI-Kosten um den Faktor 20 bis 50 im Vergleich zu einem chatbasierten System. Mit Gemini Flash als KI-Backend liegen die tatsächlichen KI-Kosten bei etwa 5 Cent pro Tenant und Jahr. Das ist kein Tippfehler.
Was Sie daraus mitnehmen können: Nicht jede KI-Anwendung braucht KI für alles. Wenn der Anwendungsfall vorhersehbar ist (und Terminbuchungen sind das), dann ist ein strukturierter Flow mit KI-Fallback deutlich günstiger und zuverlässiger als ein durchgehend KI-gesteuertes System.
Echtes Multi-Tenancy mit verschlüsselten Credentials
Jeder Betrieb (Tenant) konfiguriert seine eigenen Zugänge: WhatsApp Business API Token, Telegram Bot Token, Google Calendar OAuth Credentials und optionale Telefon-Konfiguration. Diese Credentials werden mit der ASP.NET Core Data Protection API verschlüsselt in der Datenbank gespeichert. Der Verschlüsselungsschlüssel selbst liegt nur in den Umgebungsvariablen des Servers.
Das Ergebnis: Ein Betrieb kann seine WhatsApp-Nummer wechseln, ohne dass ein Entwickler den Server anfassen muss. Credentials werden im Admin Panel eingegeben und sind sofort aktiv. Kein Container-Neustart, kein Redeployment.
Was Sie daraus mitnehmen können: Die Trennung von Infrastruktur-Secrets (Datenbank-Passwort, Verschlüsselungskeys) und Business-Credentials (API-Tokens, OAuth-Daten) ist entscheidend für skalierbare Multi-Tenant-Systeme. Infrastruktur-Secrets gehören in Umgebungsvariablen, Business-Credentials gehören verschlüsselt in die Datenbank mit einem Admin-UI davor.
Self-Hosted Voice Stack
Für den Telefonkanal kombinieren wir drei Self-Hosted-Komponenten: Jambonz für die VoIP-Integration (nimmt Anrufe entgegen und routet sie), Piper TTS für die Sprachsynthese (über 30 Stimmen, konfigurierbar pro Tenant) und Whisper STT für die Spracherkennung. Alles läuft auf dem eigenen Server.
Der Telefonflow bietet dabei mehr als nur Buchungen. Innerhalb der Öffnungszeiten kann der Anrufer direkt an einen Mitarbeiter weitergeleitet werden. Außerhalb der Öffnungszeiten bietet das System automatisch einen Rückruf an und bucht dafür den nächsten freien Slot im Kalender. Und wenn das System nach mehreren Versuchen nicht versteht, was der Anrufer möchte, wird ebenfalls eine Weiterleitung oder ein Rückruf angeboten.
Was Sie daraus mitnehmen können: Self-Hosted Voice (TTS und STT) ist mit Open-Source-Modellen wie Piper und Whisper heute erstaunlich gut und wirtschaftlich. Die Qualität reicht für Telefon-Interaktionen problemlos aus, und die Kosten sind praktisch null im Vergleich zu Cloud-Diensten, die pro Minute abrechnen.
Multi-Employee und intelligente Verfügbarkeit
Ein Barbershop hat selten nur einen Mitarbeiter. BookingBot unterstützt mehrere Mitarbeiter pro Service mit intelligenter Verfügbarkeit: Wenn ein Kunde seinen bevorzugten Mitarbeiter wählt und dieser zum gewünschten Zeitpunkt nicht verfügbar ist, schlägt das System automatisch alternative Mitarbeiter vor, die den gewählten Service ebenfalls anbieten.
Der Kalender im Admin Panel zeigt Buchungen gefiltert nach Mitarbeiter, und jede Buchung wird automatisch mit Google Calendar synchronisiert. Zusätzlich erhält der Kunde eine .ics-Datei für den direkten Import in seinen eigenen Kalender.
Mehrsprachigkeit ohne Overhead
BookingBot unterstützt sieben Sprachen (Deutsch, Englisch, Arabisch, Türkisch, Bosnisch, Serbisch, Kroatisch) mit automatischer Spracherkennung. Service-Namen und Beschreibungen werden als JSONB in der Datenbank gespeichert, sodass ein Service gleichzeitig "Herrenhaarschnitt", "Men's Haircut" und "قص شعر رجال" heißen kann. Die Übersetzung läuft über LibreTranslate (self-hosted) oder optional über die DeepL API.
Was Sie daraus mitnehmen können: JSONB-Spalten für mehrsprachige Inhalte sind ein pragmatischer Ansatz, der ohne separate Übersetzungstabellen auskommt. Es macht die Abfragen etwas komplexer, spart aber erheblich an Schema-Komplexität und Join-Overhead.
Architektur-Entscheidungen
Monolith statt Microservices. BookingBot ist ein .NET 10 Monolith mit ASP.NET Core Web API und Blazor Server für das Admin Panel. Für ein Self-Hosted-Produkt, das auf einem €10-VPS laufen soll, ist ein einzelner Container deutlich einfacher zu deployen und zu warten als ein verteiltes System.
PostgreSQL und Redis. PostgreSQL für persistente Daten mit EF Core und Global Query Filters für die Tenant-Isolation. Redis für Sessions, Caching und temporären Conversation State. Die Kombination deckt alle Anforderungen ab, ohne zusätzliche Infrastruktur.
Vertical Slice Architecture. Statt der klassischen Layer-Architektur (Controllers, Services, Repositories) ist der Code nach Features organisiert: Tenants, Services, Bookings, Barbers, Webhooks. Jedes Feature enthält alles, was es braucht. Das macht den Code navigierbar und neue Features lassen sich hinzufügen, ohne durch fünf Schichten zu graben.
SuperAdmin und Tenant Admin als getrennte Rollen. Der SuperAdmin verwaltet plattformweite Einstellungen (KI-Provider, Tenant-Management), der Tenant Admin verwaltet seinen eigenen Betrieb (Services, Mitarbeiter, Kalender). Tenant Admins sehen ausschließlich ihre eigenen Daten. Diese Trennung wird über EF Core Global Query Filters erzwungen, nicht über manuelle Where-Clauses.
Wirtschaftlichkeit
Ergebnisse
MetrikWertUnterstützte KanäleWhatsApp, Telegram, TelefonSprachen7 (automatische Erkennung)KI-Kosten pro Tenant/Jahrca. 0,05 Euro (Gemini Flash)Serverkosten (50 Tenants)ca. 10 Euro/MonatTenant OnboardingKomplett über Admin Panel, kein Entwickler nötigCredential-ÄnderungenSofort wirksam, kein NeustartVoice StackKomplett self-hosted (Jambonz, Piper, Whisper)Phasen abgeschlossen4 von 5 (Phase 5: Production Hardening läuft)
Takeaways für Ihre Projekte
Nicht jede KI-Anwendung braucht KI für alles. Ein strukturierter, menübasierter Flow mit KI-Fallback ist für vorhersehbare Anwendungsfälle günstiger, schneller und zuverlässiger als ein durchgehend KI-gesteuertes System. Die KI dort einsetzen, wo sie echten Mehrwert bringt (Freitext-Verständnis, Spracherkennung), und überall sonst auf bewährte UI-Patterns setzen.
Multi-Tenancy richtig machen heißt Credentials in die Datenbank. Wenn API-Keys in Umgebungsvariablen stecken, braucht jeder Tenant sein eigenes Deployment. Verschlüsselte Credentials in der Datenbank mit einem Admin-UI davor skalieren auf hunderte Tenants mit einem einzelnen Deployment.
Self-Hosted Voice ist 2025 praxistauglich. Open-Source-Modelle wie Piper (TTS) und Whisper (STT) liefern Qualität, die für Telefon-Interaktionen ausreicht. Die Kosten liegen bei null im Vergleich zu Cloud-Diensten, und die Latenz ist sogar geringer, weil kein Netzwerk-Roundtrip nötig ist.
Die Wirtschaftlichkeit früh mitdenken. Die Entscheidung für menübasierte Flows statt Freitext-KI, für Self-Hosted Voice statt Cloud-Services und für einen einzelnen Monolith statt Microservices war nicht nur technisch sinnvoll, sondern hat die Kostenstruktur von Anfang an auf Skalierbarkeit ausgelegt.
BookingBot wird von Fragon Studios entwickelt. Als Engineering Lab verbinden wir KI-Integration mit pragmatischer Softwarearchitektur für Produkte, die wirtschaftlich skalieren.