Wenn der Kunde anruft — und die KI ihn an die richtige Person weiterleitet

Wer in einem österreichischen KMU telefoniert, kennt drei Szenarien. Entweder nimmt ein Mensch ab, der gerade Zeit hat. Oder ein klassisches IVR begrüßt einen mit „Drücken Sie 1 für Verkauf, 2 für Buchhaltung". Oder es klingelt ins Leere, und am Ende landet eine generische Mailbox-Aufnahme auf einem Server, den niemand abhört.

Die ersten beiden Optionen kosten Geld oder nerven Anrufer. Die dritte verliert Geschäft.

Es gibt eine vierte Option, die seit ein paar Monaten technisch möglich ist: Eine KI hebt ab, hört kurz zu, was der Anrufer will, und leitet den Anruf an die richtige Person — abhängig von Anliegen, Uhrzeit und Verfügbarkeit. Wenn niemand erreichbar ist, nimmt sie eine strukturierte Voicemail auf und schickt das Transkript per WhatsApp oder E-Mail an den zuständigen Mitarbeiter.

So einfach das klingt — der Bauplan dahinter ist nicht trivial. Wir entwickeln eine solche Vermittlung gerade produktiv für unseren ersten Voice-Pilot. Dieser Artikel zeigt die Architektur-Entscheidungen, die wir dabei getroffen haben — und warum.

Die drei Stufen der KI-Telefonvermittlung

Bevor man baut, hilft eine saubere Abgrenzung. Wir unterscheiden drei Stufen.

Stufe A — Smart Receptionist. Die KI hebt ab, sagt etwa „Sie sprechen mit der KI-Sekretärin der Kanzlei XY, ich verbinde Sie weiter", und routet stumpf an eine zentrale Durchwahl. Sinnvoll als Empfang-Filter, aber zu dünn, um echtes Geschäft zu verändern.

Stufe B — Qualifizierter Filter mit dynamischer Vermittlung. Die KI versteht das Anliegen ansatzweise, kennt Bürozeiten und Verfügbarkeiten, leitet an den richtigen Ansprechpartner weiter und übergibt sauber. Wenn niemand erreichbar ist: Voicemail mit Cross-Channel-Zustellung.

Stufe C — Full IVR-Ersatz. Komplette agentic Voice — die KI führt Beratungsgespräche, schlägt Termine vor, erstellt Angebote. Zu komplex für die meisten KMUs ohne dediziertes Pilotprogramm.

Wir bauen Stufe B. Das ist der einzige Sweet Spot, in dem die Technologie heute zuverlässig liefert und gleichzeitig einen sichtbaren Mehrwert produziert.

Die vier Bausteine

Eine KI-Telefonvermittlung besteht aus vier Komponenten, die sauber ineinandergreifen müssen. Wenn einer davon mangelhaft ist, bricht das ganze System.

Baustein 1 — Intent-Klassifikation

Sobald der Anrufer den ersten Satz sagt, muss die KI verstehen, worum es geht: Angebotsanfrage, bestehender Schadenfall, Termin, Rückfrage zu einer Rechnung. Wir nutzen dafür ein kompaktes LLM mit niedriger Latenz — bei uns Mistral, weil EU-gehostet und DSGVO-kompatibel.

Wichtig: Die Klassifikation muss in deutlich unter einer Sekunde durch sein, sonst wirkt das Gespräch zerhackt. Wir messen das vor dem ersten Pilot mit 10 echten Stichproben — nicht mit synthetischen Benchmarks. Latenz-Drift erkennt man nicht im Lab, sondern in der ersten Live-Stunde.

Pro Klassifikations-Ergebnis bekommt das System einen Confidence-Wert. Liegt er unter einem konfigurierbaren Schwellenwert, fällt der Anruf in einen Default-Routing-Pfad — niemals in ein Halluzinations-Routing zu jemandem, der gar nicht zuständig ist.

Baustein 2 — Routing-Logik

Mit dem klassifizierten Intent in der Hand schaut die Routing-Logik in drei Datenquellen.

Erstens: die Routing-Targets des Kunden. Das sind die Personen oder Abteilungen, an die vermittelt werden kann, jeweils mit Telefonnummer, Skill-Tags („Schadenfall", „Vertrag-Sach", „Vorstand"), Sprachen und Eskalations-Reihenfolge. Wir speichern das nicht in einer eigenen Tabelle, sondern als Sub-Key in einer bereits existierenden Bot-Konfiguration. Refaktorierbar wenn nötig, schnell zu bauen, keine künstliche Tabellen-Multiplikation.

Zweitens: die Bürozeiten. Pro Kunde, mit Wochenschema und Feiertags-Logik, Zeitzone Europe/Vienna als Default. Bürozeiten gelten initial pro Tenant — also für die ganze Organisation. Eine Erweiterung auf „Bürozeiten pro Routing-Target" lassen wir architektonisch offen, indem das Schema von Anfang an einen NULLABLE Foreign Key auf Routing-Target enthält. Wenn NULL, gilt der Tenant-Default. Saubere Erweiterbarkeit ohne späteres Migrations-Drama.

Drittens: die Fallback-Kette. Was passiert, wenn der erste Target nicht abnimmt? Direkt Voicemail? Weiterleiten an den nächsten? Wir bilden das als geordnete Liste pro Routing-Target ab — bis zu drei Versuche, dann Voicemail.

Baustein 3 — Die technische Bridge

Routing-Entscheidung ist getroffen — jetzt muss der Anruf physisch weitervermittelt werden. Wir nutzen den Telnyx-Call-Control-Stack: Die KI bleibt während der Bridge im Hintergrund, beobachtet den Verbindungsaufbau, registriert ob abgenommen wird, wann aufgelegt wurde, ob das Gespräch erfolgreich war.

Jeder Bridge-Versuch wird in einer eigenen Tabelle dokumentiert: voice_bridge_legs. Das ist mehr als ein Logfile — es ist die Grundlage für spätere Analyse („Welcher Mitarbeiter nimmt im Durchschnitt schnell ab?", „Welche Intents führen zu den meisten Fallbacks?"). Bei mehreren Versuchen pro Anruf wird die Kette sauber abgebildet.

Eine Architektur-Entscheidung, die unscheinbar wirkt aber wichtig ist: Wir trennen Inbound-Bridge-Daten von Outbound-Campaign-Daten. Zwei Tabellen, klare Verantwortlichkeiten — keine Spalten-Drift, die ein halbes Jahr später niemand mehr versteht.

Baustein 4 — Voicemail-Pipeline

Wenn keine Bridge erfolgreich ist, nimmt die KI eine Voicemail auf. Das Audio landet in unserem eigenen, EU-gehosteten Storage — nicht beim Telekommunikationsanbieter, sondern in einem S3-kompatiblen Bucket in Hetzners deutschem Rechenzentrum. Das ist eine bewusste DSGVO-Entscheidung. Für regulierte Branchen wie Versicherung, Recht oder Medizin ist die Hoheit über die Audiodaten kein Komfortfeature, sondern Voraussetzung.

Die Aufnahme wird transkribiert, in einer relationalen Tabelle dokumentiert und automatisch mit einem Verfallsdatum versehen. Default-Retention: 30 Tage. Optional konfigurierbar auf 60 oder 90. Keine längere Speicherung, kein Schummeln, kein „nur falls wir später mal forensisch brauchen". Ein Cron-Job räumt täglich auf.

Die Zustellung läuft Cross-Channel: Pro Routing-Target wird konfiguriert, ob die Voicemail per WhatsApp, per E-Mail oder über beide Kanäle landet. Der zuständige Mitarbeiter bekommt das Transkript in seiner gewohnten Inbox — nicht in einem separaten Tool, das er erst öffnen muss.

Drei Architektur-Entscheidungen, die wichtiger sind als sie klingen

KI = was. Datenbank = wohin. Wissensbasis = warum.

Die wichtigste Trennung, die wir gelernt haben: Routing-Daten gehören nicht in die Wissensbasis. Telefonnummern, Skill-Tags, Bürozeiten — das sind strukturierte Stammdaten und müssen in relationalen Tabellen liegen, nicht in semantisch durchsuchbarer Vektor-Form.

Diese saubere Trennung verhindert eine ganze Klasse von Halluzinations-Bugs. Eine KI, die eine Telefonnummer aus einer Vektor-Suche zieht, kann sie verwechseln. Eine KI, die eine Telefonnummer aus einer Foreign-Key-Beziehung zieht, kann es nicht.

Bridge-Targets in einer existierenden Spalte, nicht in einer neuen Tabelle

Wir hatten ursprünglich geplant, für die Bridge-Targets eine eigene Spalte auf der Bots-Tabelle anzulegen. Ein Pre-Build-Audit hat aufgedeckt, dass eine generische JSON-Spalte für Voice-Konfiguration bereits existierte — und leer war.

Statt eine zweite Spalte daneben zu setzen, haben wir die existierende zur Single Source of Truth für Voice-Settings gemacht: Bridge-Targets, Bürozeiten-Referenz, Voicemail-Einstellungen — alles als Sub-Keys in einer JSON-Struktur. Refaktorierbar, schnell, kein Schema-Aufwand.

Diese Entscheidung wäre ohne Audit nicht gefallen. Pre-Build-Recon ist nicht Bürokratie, es ist Architektur-Hygiene.

Eigener Storage statt Cloud-Native-Voicemail

Telnyx bietet Voicemail-Storage nativ an — wir verzichten darauf. Begründung: Die Audiodaten enthalten potenziell sensible Aussagen. Schadenfälle. Vertrauliche Anliegen. Rechtliche Hinweise. Wir wollen Hoheit über jeden Schritt der Verarbeitung haben — wer Zugriff hat, wann gelöscht wird, in welchem Rechenzentrum die Datei liegt.

Was wir damit anders machen als klassische IVR

Klassische IVRs scheitern in der Praxis an drei Punkten.

Erstens: Sie zwingen den Anrufer in ein vorgegebenes Menü. „Drücken Sie 1 für…". Wenn das Anliegen nicht ins Menü passt, gibt es keinen sinnvollen Pfad. Eine KI-Vermittlung hört zu — sie braucht kein Menü.

Zweitens: Sie sind statisch. Bürozeiten ändern sich, Mitarbeiter werden krank, Schichten verschieben sich — und das IVR weiß davon nichts. Eine KI-Vermittlung greift auf eine Datenbank zu, die in der Cloud aktualisiert wird. Wer die Bürozeit am Vorabend ändert, sieht den Effekt beim ersten Anruf am nächsten Morgen.

Drittens: Sie liefern keine Daten zurück. Ein klassisches IVR ist ein Schwarz-Weiß-Schalter. Eine KI-Vermittlung erzeugt strukturierte Datensätze: Welcher Intent kam wie oft? Welcher Mitarbeiter nimmt schnell ab? Welche Voicemail-Themen wiederholen sich? Damit wird Telefonie auswertbar — und das ist die Voraussetzung dafür, sie zu verbessern.

DSGVO ist keine Hürde, sondern eine Architektur-Entscheidung

Wer eine KI-Telefonvermittlung in Österreich oder der EU baut, kommt an drei Themen nicht vorbei.

Erstens: Wo liegen die Audiodaten? Bei einem US-Anbieter sind sie nicht DSGVO-konform speicherbar, egal was der Anbieter behauptet. Bei einem EU-gehosteten S3 schon. Wir wählen letzteres — bewusst, dokumentiert, in den AVV-Verträgen sichtbar.

Zweitens: Wer hat Zugriff? Bei der Voicemail muss klar geregelt sein, welcher Mitarbeiter welche Aufnahme öffnen darf. Wir trennen das per Permission-System: Eine eigene Berechtigungsgruppe voice_routing.* verwaltet diese Rechte. Eine spätere „Sekretärin"-Rolle bekommt nur diese Permissions — ohne Code-Refactor.

Drittens: Wie lange wird gespeichert? Wir haben uns auf eine harte Obergrenze von 90 Tagen festgelegt, mit Default 30. Längere Speicherung ist nicht konfigurierbar. Wer Aufnahmen länger braucht, muss sie aktiv exportieren — das ist eine bewusste Hürde, kein Bug.

Fazit — wann sich Stufe B lohnt

Eine KI-Telefonvermittlung ist nicht für jeden. Sie lohnt sich, wenn:

— das Anrufaufkommen so hoch ist, dass eine Sekretärin überlastet ist — oder so niedrig, dass eine Sekretärin Geldverschwendung wäre,
— es mehrere zuständige Personen oder Abteilungen gibt, zwischen denen sinnvoll routet werden muss,
— außerhalb der Bürozeiten Anrufe verloren gehen, die strukturiert weiterverarbeitet werden könnten,
— Datenschutz wichtig ist und US-Cloud-Anbieter ausgeschlossen sind.

Sie lohnt sich nicht, wenn jeder Anruf ohnehin direkt an die selbe Person geht. Dann reicht ein guter Anrufbeantworter.

Bei getVIA bauen wir Stufe B gerade für einen Versicherungsmakler-Piloten produktiv aus — das Datenmodell ist live, die Bridge-Implementierung folgt in den nächsten Wochen. Der erste echte Live-Test ist in vier Wochen. Wir werden Folge-Artikel mit echten Latenz-Zahlen, Fallback-Quoten und Voicemail-Statistiken nachreichen, sobald wir Produktivdaten haben.

Weiterlesen

Von Prompt Engineering zu Harness Engineering — die dritte Stufe der KI-Entwicklung
Warum einfache Vektorsuche nicht reicht — und wie Hybrid Search KI-Halluzinationen verhindert

Quellen

• Telnyx Inc. (2026). Call Control API Documentation. developers.telnyx.com
• Mistral AI (2026). Mistral Large 3 — Multilingual Models. mistral.ai/news/mistral-3
• Europäische Union (2016). DSGVO Art. 32 — Sicherheit der Verarbeitung.