Die Frage
Wer einen KI-Telefonassistenten evaluiert, vergleicht Features, Preise, Integrationen. Die Frage, die dabei fast nie gestellt wird — und die wichtiger ist als alle anderen:
Die Frage, die vor dem Preis kommt und trotzdem fast nie gestellt wird: Was kauft man eigentlich, wenn man "einen Voicebot" kauft?
Im Markt gibt es drei grundlegend verschiedene Antworten. Die meisten Käufer merken erst bei der Kündigung, welche Antwort sie gewählt haben (Gartner CCaaS Market Analysis, 2025).
Die drei Kaufmodelle
Modell 1: Shared-Cloud-SaaS — "Minuten kaufen"
Man bucht einen Voicebot als Service. Der Anbieter stellt Infrastruktur, Modell, Dashboard. Schnell eingerichtet, niedrige Einstiegshürde.
Was man besitzt: Nichts. Daten liegen beim Anbieter. Bei Kündigung: neuer Prompt, neue FAQ, neues Training bei einem neuen Anbieter. Für Solo-Selbständige ein sinnvoller Test. Für Unternehmen mit Datenschutzanforderungen eine Entscheidung, die man bereuen wird.
Modell 2: Single-Tenant — "Eigentümer statt Mieter"
Der Bot läuft nicht auf der Infrastruktur des Anbieters — er läuft in der eigenen Cloud-Subscription des Kunden. Eigene Datenbank, eigene Schlüssel, eigener Vertrag mit dem Cloud-Provider. Der Plattform-Anbieter hat delegierten Konfigurationszugriff — keinen Datenzugriff (Azure Lighthouse).
Was man besitzt: Alles. Bei Kündigung bleiben Daten, Transkripte, Konfiguration beim Kunden. Der Bot kann sogar weiterlaufen. Das ist die Sontor-Architektur.
Modell 3: Eigenentwicklung — "Alles selbst bauen"
Maximale Kontrolle: Eigener Code, eigene Infrastruktur, vollständige Unabhängigkeit. Was man investiert: Monate an Entwicklungszeit und ein dediziertes Team. Für Konzerne mit eigener IT-Abteilung der richtige Weg. Für den Mittelstand — der KI-Druck von oben spürt, aber keinen Entwickler im Haus hat — unrealistisch.
Was bei Kündigung passiert — der eigentliche Vergleich
| SaaS | Single-Tenant | Eigen | |
|---|---|---|---|
| Daten gehören | Dem Anbieter | Ihnen (100%) | Ihnen |
| Bei Kündigung | Alles weg | Bot läuft weiter | Alles bleibt |
| §203-konform | Fraglich | ✓ Physische Isolation | ✓ |
| Credentials | An Anbieter übertragen | Beim Kunden | Beim Kunden |
| IT-Ressourcen nötig | Gering | Gering | Sehr hoch |
| Time-to-Value | Tage–Wochen | 30 Minuten | 3–6 Monate |
Was Ownership in der Praxis bedeutet
Drei Fehler, die ich immer wieder sehe
Fehler 1: Kaufmodell mit Feature-Set verwechseln
Die meisten Entscheidungsprozesse vergleichen Features: Integrationen, Sprachen, Modell. Die primäre Frage ist: In welchem Kaufmodell bewege ich mich? Features lassen sich nachrüsten. Die Architektur nicht.
Fehler 2: Lock-in ignorieren
Nach sechs Monaten Prompt-Optimierung und FAQ-Aufbau ist man eingeschlossen — nicht durch einen Vertrag, sondern durch Wechselkosten. Bei Single-Tenant gibt es dieses Lock-in nicht: Daten bleiben im Kunden-Tenant, Konfiguration ist exportierbar (Art. 20 DSGVO — Datenportabilität).
Fehler 3: Architekturentscheidung aufschieben
"Wir fangen erst mal mit Shared Cloud an und wechseln später." In der Praxis passiert es nie — weil der Wechsel bedeutet: neue Subscription, neues Setup, neue AVV-Kette, neue Datenmigration. Die Architekturentscheidung fällt am Anfang.
Die Ownership-Checkliste
Fazit — Eigentümer statt Mieter
Die Frage ist nicht, was ein Voicebot kostet. Die Frage ist, was einem danach gehört.
Sontor ist eine Antwort auf diese Frage: Ein Werkzeug, das dem Kunden gehört. Nicht dem Anbieter.
Lassen Sie sich direkt mit den Gründern verbinden.
Kostenlos. Ohne Registrierung. Ihr Gespräch wird nicht aufgezeichnet.