Telefonische Supportanfragen erfassen: vom Anruf zur Aufgabe

Formular, Widget, E-Mail: Für die meisten Supportkanäle gibt es inzwischen eine Struktur. Pflichtfelder, automatisch angehängte Browserdaten, ein Eingang, in dem alles auflaufen kann. Nur beim Telefon läuft es wie vor zwanzig Jahren – jemand nimmt ab, schreibt nebenher mit, und was hinterher im System landet, hängt davon ab, wie aufmerksam diese Person in genau diesen vier Minuten war.

Dabei ist der Anruf oft der informationsreichste Kanal überhaupt. Der Kunde erzählt mehr, als er je in ein Formular tippen würde, und man kann sofort nachfragen. Das Problem ist nicht der Kanal. Das Problem ist, dass zwischen dem Gespräch und der Aufgabe im Team eine Handschrift liegt.

Was von einem Anruf übrig bleibt

Ein Anruf um 9:40 Uhr. Der Kunde sagt, dass „das mit den Rechnungen seit gestern nicht mehr geht“, schiebt nach, dass es nur die Filiale Heidelberg betrifft, erwähnt beiläufig, dass er bis 15 Uhr in einem Termin sitzt, und legt auf. Was im System landet, ist meistens dieser Satz: „Kunde Meyer, Rechnungen gehen nicht, bitte prüfen.“

Drei Angaben sind damit weg – und ausgerechnet die drei, die den nächsten Schritt bestimmt hätten. Ohne „nur Heidelberg“ sucht die Entwicklung im ganzen System statt an einer Filiale. Ohne „seit gestern“ fehlt der Bezug zum Deployment von vorgestern. Ohne „bis 15 Uhr im Termin“ ruft jemand um 11 Uhr zurück, erreicht niemanden und legt den Vorgang zurück auf Wiedervorlage.

Das ist keine Frage von Sorgfalt. Wer telefoniert, zuhört, beruhigt und gleichzeitig strukturiert mitschreiben soll, verliert zwangsläufig etwas. Die Frage ist, ob die Struktur vom Gedächtnis abhängt oder vom Ablauf.

Sechs Angaben, aus denen eine Aufgabe wird

Es braucht weniger, als man denkt. Diese sechs Punkte reichen, damit jemand anderes den Fall übernehmen kann, ohne noch einmal beim Kunden anzurufen:

• Anliegen: Bereich plus Symptom in einem Satz – „Rechnungsversand Filiale Heidelberg schlägt fehl“, nicht „Problem mit Rechnungen“.
• Anrufer: Name, Firma, Rückrufnummer und – falls vorhanden – Kunden- oder Vertragsnummer.
• Wirkung: blockiert komplett, stört mit Umweg, oder Kleinigkeit. Aus Sicht des Kunden, nicht aus Sicht der Technik.
• Bereich: Standort, Konto, Projekt oder Modul – alles, was das Suchfeld später kleiner macht.
• Erreichbarkeit: wann ein Rückruf ankommt, und auf welchem Weg der Kunde lieber Antwort bekommt.
• Nächster Schritt: Rückruf, Prüfung, Termin oder Weiterleitung – vereinbart, nicht vermutet.

Was hier bewusst fehlt, ist das Volltranskript. Niemand liest vier Minuten Gesprächsverlauf, bevor er eine Aufgabe anfasst. Drei Sätze Zusammenfassung schlagen jede vollständige Mitschrift.

Der Weg dorthin: Leitfaden oder Assistent

Für diese sechs Angaben gibt es zwei Wege, und der günstigere kommt zuerst.

Ein Gesprächsleitfaden kostet nichts

Die sechs Punkte als Zettel neben das Telefon oder als Formularfelder in der Maske, die beim Annehmen aufgeht. Das klingt banal und erledigt trotzdem den Großteil des Problems: Wer die Liste vor sich hat, fragt „Betrifft das alle Standorte oder einen bestimmten?“, bevor der Kunde auflegt – und nicht zwei Stunden später per Mail. Für Teams mit ein paar Anrufen am Tag ist das die ganze Lösung, und sie steht morgen früh.

Ein KI-Telefonassistent nimmt auch um 22 Uhr ab

Der Leitfaden hat zwei Grenzen: Er braucht einen freien Menschen, und den gibt es nicht immer. Bei fünf gleichzeitigen Anrufen, abends, im Urlaub oder während alle in einem Termin sitzen, landet der Kunde auf der Mailbox – dem unstrukturiertesten Kanal von allen.

Hier setzen KI-Telefonassistenten an. Sie nehmen das Gespräch in natürlicher Sprache an, verstehen frei formulierte Anliegen, fragen fehlende Angaben nach und geben das Ergebnis strukturiert weiter. Der Unterschied zum alten Sprachmenü ist wesentlich: Der Anrufer muss sein Anliegen nicht in „Drücken Sie die 3“ übersetzen, sondern erzählt es einfach.

Ein deutscher Anbieter in diesem Feld ist die Teloro GmbH aus Mannheim. Ihre Assistenten beantworten Standardfragen aus einer freigegebenen Wissensbasis, erfassen Kunden- und Vorgangsdaten im Gespräch und übergeben das Ergebnis nach eigenen Angaben per Integration, API, Webhook oder E-Mail an nachgelagerte Systeme. Wie das im automatisierten Kundenservice konkret aussieht, beschreibt Teloro selbst ausführlicher, als wir es hier könnten.

Wichtig bei der Auswahl – egal bei welchem Anbieter – sind zwei Dinge: eine Eskalationsregel, die schwierige Fälle früh an einen Menschen gibt, und eine Übergabe, die strukturierte Felder liefert statt einer Textwand. Ein Assistent, der am Ende eine E-Mail mit dem kompletten Gesprächsverlauf schickt, hat das Problem nur verschoben.

Aus gesprochenen Sätzen werden Felder

Der eigentliche Trick liegt in der Übersetzung. Kunden sprechen nicht in Datenfeldern, aber fast jeder Satz enthält eines:

• „Seit heute Morgen geht gar nichts mehr.“ → Wirkung: blockierend, seit heute – der Fall gehört nach oben in die Triage.
• „Es geht um unsere Filiale Heidelberg.“ → Bereich: Standort Heidelberg – bestimmt, wer zuständig ist.
• „Bitte erst nach 15 Uhr zurückrufen.“ → Erreichbarkeit ab 15:00 – verhindert den Fehlversuch am Vormittag.
• „Bei uns hat das früher immer funktioniert.“ → Regression statt Bedienfehler – ändert die Suchrichtung komplett.
• Die freie Schilderung → Titel plus drei Sätze Zusammenfassung, in denen der Wortlaut des Kunden erhalten bleibt.

Der letzte Punkt ist der, an dem am meisten schiefgeht. Wer zusammenfasst, interpretiert – und genau die Formulierung, die später den Fehler erklärt hätte, fällt raus. Deshalb gilt für die Beschreibung dasselbe wie bei jeder Bug-Report-Vorlage: zitieren statt übersetzen.

Wo IssuePilot übernimmt

Ab hier ist der Anruf kein Anruf mehr, sondern eine Meldung wie jede andere – und der Ablauf ist derselbe wie bei allem, was über Widget, Formular oder E-Mail hereinkommt. Sie läuft im Eingang auf und wird dort sortiert: beantworten, beheben oder einplanen.

cockpit.issuepilot.app/inbox

Diese Sortierung ist der Punkt, an dem der Aufwand entsteht oder verschwindet. Wie sie sich als fester Ablauf einrichten lässt, beschreibt der Beitrag zum Triage-Workflow im Eingang. Was aus dem Fall dann wird – Antwort, Aufgabe oder Produktentscheidung –, folgt denselben Kriterien wie bei jeder anderen Supportanfrage, die zur Aufgabe wird.

Entsteht daraus eine Aufgabe, tragen die sechs Angaben aus dem Gespräch direkt die Felder: Das Anliegen wird zum Titel, die Wirkung zur Priorität, der Bereich zum Projekt oder Label, der nächste Schritt zur Zuweisung.

cockpit.issuepilot.app/issues

Der Anrufer selbst bleibt dabei an der Sache dran. Die Kundenanfrage bleibt dem Kunden zugeordnet und wird mit der Aufgabe verknüpft – melden drei Filialen dasselbe, hängen drei Anfragen an einer Aufgabe. Ist sie erledigt, steht direkt daran, wer jetzt einen Rückruf bekommt. Kunden & Kundenanfragen gehören zum Pro-Plan; Eingang, Triage und Aufgaben decken den Ablauf schon im Free-Plan ab.

cockpit.issuepilot.app/customers

Zur Einordnung, damit hier kein falscher Eindruck entsteht: Eine fertige Integration zwischen Teloro und IssuePilot, die man anklicken kann, gibt es aktuell nicht. Der beschriebene Weg ist technisch naheliegend, weil Teloro strukturiert übergeben kann und IssuePilot Aufgaben aus solchen Übergaben anlegen kann – heute wäre er aber ein Eigenbau über Webhook und API. Wir schreiben das hin, weil ein Beitrag, der eine Anbindung andeutet, die es nicht gibt, niemandem weiterhilft.

Warum „alles automatisch“ das falsche Ziel ist

Es ist verlockend, den Anspruch auf „kein Anruf landet mehr bei uns“ zu setzen. Das geht in den meisten Fällen schief. Beschwerden, Kündigungsdrohungen, unklare Fehlerbilder und alles, wo jemand ausdrücklich einen Menschen verlangt, gehören zu einem Menschen – und zwar früh im Gespräch, nicht nach der dritten missverstandenen Rückfrage.

Der Gewinn liegt woanders. Wenn ein Mensch übernimmt, startet er mit Name, Anliegen, Wirkung, Bereich und dem, was schon gefragt wurde. Er fängt nicht bei null an, und der Kunde muss seine Geschichte nicht zum zweiten Mal erzählen. Das ist der eigentliche Unterschied – nicht die Zahl der eingesparten Gespräche.

Häufige Fehler

• Volltranskript statt Zusammenfassung: Niemand liest vier Minuten Gesprächsverlauf, bevor er die Aufgabe anfasst.
• Der telefonische Fall bekommt einen eigenen Ablauf: Zwei Eingänge nebeneinander bedeuten, dass einer davon nicht gepflegt wird.
• Keine Eskalationsregel: Ein Assistent, der auch bei Beschwerden auf Vollständigkeit besteht, kostet mehr Vertrauen als er Zeit spart.
• Erreichbarkeit nicht erfasst: Der Rückruf ins Leere ist die häufigste stille Verzögerung im telefonischen Support.
• Wirkung aus Technikersicht gesetzt: Ob etwas blockiert, entscheidet der Kunde – nicht die Einschätzung, wie schwer der Fix wird.

Fazit

Telefonischer Support muss nicht unstrukturiert bleiben, nur weil Menschen frei sprechen. Zwischen dem Gespräch und der Aufgabe liegt eine Übersetzung, und die lässt sich beschreiben: sechs Angaben, ein Eingang, eine Sortierung.

Ob diese Übersetzung ein Zettel neben dem Telefon leistet oder ein KI-Telefonassistent, ist eine Frage der Menge. Für die meisten kleinen Teams reicht der Zettel länger, als Anbieter es gerne hätten. Wer abends, am Wochenende oder bei parallelen Anrufen erreichbar sein muss, kommt um Automatisierung schwer herum – und sollte dann darauf achten, dass am Ende strukturierte Felder herauskommen und nicht die nächste Textwand.

In beiden Fällen gilt derselbe Maßstab: Am Ende des Anrufs muss jemand anderes den Fall übernehmen können, ohne noch einmal anzurufen. Wie IssuePilot Support-Teams dabei unterstützt, zeigt die Seite für Support & QA.