Blog · B2B-Software
Fehlermeldungen vollständig machen:
Support-Tickets, mit denen die Entwicklung arbeiten kann.
Ein Fehlerbericht ohne Version und Schritte ist für die Entwicklung kaum nutzbar. Dieser Beitrag zeigt, wie ein Agent die fehlenden Angaben erfragt und Tickets strukturiert, ohne Ursachen zu vermuten.
Kurz gesagtEin KI-Agent kann Fehlermeldungen im Softwaresupport vollständig machen: Version, Umgebung, Schritte und Auswirkungen erfragen, Screenshots und Logs zuordnen und ein strukturiertes Ticket anlegen. Ursachenanalyse, Priorisierung für die Entwicklung und Zusagen entscheiden Support und Produktverantwortliche.
Von „Es geht nicht“ zum Ticket
Kunden melden Fehler in ihrer Sprache: „Der Export bricht ab“, „Die Seite lädt nicht“. Für den Support ist das ein Anfang, für die Entwicklung zu wenig. Sie braucht Version, Umgebung, die Schritte, die zum Fehler führen, und eine Beschreibung des erwarteten Verhaltens. Ohne diese Angaben beginnt die Arbeit mit Nachfragen, und jede Runde kostet Tage.
Der Support übernimmt diese Nachfragen von Hand. Das ist Routinearbeit, die sich standardisieren lässt, und sie ist ein Grund, warum Tickets lange offen bleiben. Ein Agent kann die Nachfragen stellen, sobald die Meldung eingeht.
Den Fehler zu erklären versucht er nicht. Support und Entwicklung sollen die Angaben vorfinden, die sie brauchen.
So wird eine Meldung vollständig, sechs Schritte
- Meldung aufnehmenDer Agent nimmt die Meldung über Portal, Mail oder Chat an und bestätigt den Eingang.
- Kunde und Produkt zuordnenEr ordnet die Meldung dem Kunden, der Lizenz und dem Produkt zu.
- Angaben erfragenEr fragt nach Version, Umgebung, Schritten zur Reproduktion, erwartetem und tatsächlichem Verhalten sowie Auswirkungen.
- Anhänge zuordnenEr verknüpft Screenshots, Logs und Dateien mit dem Ticket.
- Dubletten prüfenEr sucht nach bekannten Fehlern und verknüpft, wenn ein ähnlicher vorliegt.
- ÜbergebenDas strukturierte Ticket geht an den Support. Der Kunde erhält die Nummer und den nächsten Schritt.
Die Dublettenprüfung ist ein Vorschlag. Ob zwei Meldungen denselben Fehler betreffen, entscheidet der Support.
Ein Beispiel aus dem Alltag
Fiktives Beispiel, kein Kundenfall.
Ein Kunde meldet, der Export einer Auswertung bricht ab. Nach Version, Browser, Umfang der Daten fragt der Agent und danach, ob der Fehler stets oder nur bei bestimmten Auswertungen auftritt. Der Kunde antwortet, es betreffe nur große Auswertungen, und schickt einen Screenshot der Fehlermeldung.
Das Ticket legt er an, verknüpft es mit einem offenen Ticket zu einem ähnlichen Exportproblem und markiert das als möglichen Zusammenhang. Der Support prüft, bestätigt die Verbindung und gibt das Ticket an die Entwicklung. Die Reproduktion gelingt am selben Tag.
Reproduktionsschritte erfragen
Das Herzstück eines guten Fehlerberichts sind die Schritte, die zum Fehler führen. Kunden beschreiben sie ungern, weil sie ihnen selbstverständlich erscheinen. Der Agent fragt nach, Schritt für Schritt: Was haben Sie zuerst getan? Was geschah dann? Gibt es eine Fehlermeldung? Zusammengefasst werden die Schritte und vom Kunden bestätigt.
Er interpretiert die Schritte nicht und ergänzt keine, die der Kunde nicht genannt hat. Fehlt etwas, bleibt die Lücke sichtbar. Der Support entscheidet, ob eine Rückfrage per Telefon sinnvoller ist.
Die Reihenfolge der Schritte erfragt der Agent so, wie der Kunde sie geschildert hat, und fasst sie nummeriert zusammen. Der Kunde bestätigt, ob sie stimmt.
Umgebung und Version
Fehler können an Versionen hängen, Konfigurationen und Umgebungen. Soweit möglich, liest der Agent Angaben aus dem Lizenzsystem oder aus der Anwendung und fragt nach, wo sie fehlen. So muss der Kunde nicht aus dem Kopf angeben, welche Version er nutzt. Er bestätigt nur.
Bei Cloud-Produkten kann der Agent den Mandanten zuordnen, wenn Sie das freigeben. Zugriff auf Kundendaten im Produkt erhält er nicht.
Auswirkung und Dringlichkeit
Die Auswirkung entscheidet über die Priorität: Betrifft der Fehler einen Nutzer oder alle? Gibt es eine Umgehung? Steht ein Geschäftsprozess still? Die Auswirkung erfragt er in den Worten des Kunden und hält sie fest. Die Einstufung der Priorität nimmt der Support vor, nach Ihrer Matrix.
Er nennt dem Kunden keine Zeiten für die Behebung. Zusagen zu Fehlerbehebungen und Releases sind Sache des Produktmanagements.
Zusammenarbeit mit der Entwicklung
Die Entwicklung profitiert, wenn Tickets in einer Form ankommen, die sie lesen kann: gleiche Gliederung, gleiche Begriffe, Anhänge am richtigen Ort. Wir stimmen die Struktur mit den Entwicklerinnen ab und passen sie an, wenn sie etwas vermissen. Die Struktur liefert der Agent, über die Bearbeitung entscheidet die Entwicklung.
Rückmeldungen der Entwicklung, etwa dass ein Ticket eine bestimmte Angabe nicht hatte, fließen in die Fragenliste. So verbessert sich die Aufnahme mit jedem Ticket.
Bekannte Probleme und Workarounds
Gibt es zu einem Fehler bereits eine bekannte Umgehung, die der Support freigegeben hat, kann der Agent sie nennen. Dass es eine Umgehung ist und keine Lösung, sagt er und legt das Ticket trotzdem an. Er erfindet keine Workarounds und nutzt keine, die nicht als solche dokumentiert sind.
Die Liste bekannter Probleme pflegt der Support. Der Agent meldet Tickets, die zu einem bekannten Problem passen, und sorgt so dafür, dass Kunden nicht lange warten müssen, wenn eine Antwort vorliegt.
Auswertung für Produkt und Qualität
Aus den strukturierten Tickets lassen sich Zusammenstellungen bilden: welche Module, welche Versionen, welche Fehlerarten. Der Agent stellt sie auf Anfrage zusammen. Das Produktteam und die Qualitätssicherung nutzen sie, um Schwerpunkte zu erkennen. Die Deutung bleibt bei ihnen.
Die Zusammenstellungen zeigen, welche Produktbereiche viele Meldungen auslösen. Welche Folgerung daraus gezogen wird, entscheidet das Produktteam.
Fehler und Anwendungsfragen unterscheiden
Nicht jede Meldung betrifft einen Fehler. Manchmal fehlt dem Kunden Wissen über die Bedienung, manchmal liegt ein Konfigurationsproblem vor. Der Agent kennzeichnet Meldungen, die eher nach Frage klingen, und verweist, wenn möglich, auf die Dokumentation. Er stuft nichts abschließend ein; der Support entscheidet, ob es ein Fehler ist.
Die Unterscheidung spart Entwicklung Zeit und Kunden Wartezeit. Wer eine Antwort in der Dokumentation findet, braucht kein Ticket, und wer einen echten Fehler meldet, soll nicht in der Frageschleife landen.
Sprache und Ton im Dialog
Fehler machen Kunden ungeduldig. Sachlich und freundlich antwortet der Agent, erklärt, wozu er fragt, und bedankt sich für Geduld. Entschuldigungen formuliert er knapp, Zusagen macht er nicht. Wer das Gespräch lieber mit einem Menschen führt, bekommt es sofort.
Bleibt der Ton auch bei Frust sachlich, ist das für alle Seiten angenehmer. Der Agent bedankt sich für die Angaben und nennt den nächsten Schritt.
Besondere Fälle
- Meldung betrifft Sicherheitslücke: Der Agent nimmt auf und leitet nach Ihrer Regel sofort an die Sicherheitsstelle, ohne Details zu diskutieren.
- Kunde schickt Daten mit Personenbezug: Er weist auf den Datenschutz hin und bittet um anonymisierte Beispiele.
- Fehler tritt nur gelegentlich auf: Er hält die Beobachtungen fest und markiert die Unregelmäßigkeit.
- Meldung zu einem nicht unterstützten Produkt oder einer alten Version: Er weist auf den Stand der Unterstützung nach Ihren Angaben hin und übergibt.
- Streit über Vertragsleistung: Sofortige Übergabe.
Als Testfälle dienen abgeschlossene Tickets aus Ihrem System.
Was ausschließlich Menschen entscheiden
Er stellt keine Ursachendiagnose, bewertet keine Fehler als Mangel und sagt keine Behebung oder Releasetermine zu. Er gibt keine Hinweise, wie Kunden das Produkt abweichend von der Dokumentation einsetzen sollen, und beurteilt keine Haftung. Er greift nicht in Kundensysteme ein.
Diese Entscheidungen liegen bei Support, Entwicklung und Produktmanagement. Rechtsfragen zu Mängeln und Gewährleistung gehören in den Vertrag und zu Ihrer Beratung.
Daten und Rechte
Fehlermeldungen können Kundendaten enthalten: Screenshots mit Namen, Logs mit Kennungen. Der Agent weist auf die Gefahr hin und bittet um anonymisierte Beispiele. Arbeiten wir in Ihrem Auftrag mit personenbezogenen Daten, regelt ein Vertrag nach Art. 28 DSGVO die Zusammenarbeit; er bestimmt unter anderem Gegenstand und Dauer sowie Art und Zweck der Verarbeitung.
Gegenüber Kunden gibt sich der Agent nicht als Mensch aus: Er sagt zu Beginn, dass er ein KI-System ist (Art. 50 Abs. 1 der KI-Verordnung, soweit nicht offensichtlich). Das BSI beschreibt in seinem Papier zu generativen KI-Modellen Risiken und Gegenmaßnahmen; daran orientieren wir uns.
Pilot-Vorschlag (Ein Produkt, vier Wochen)
- Woche 1: Produkt wählen, Fragenliste erarbeiten, Ticketsystem anbinden, Übergabe an den Support klären.
- Woche 2: Der Agent legt Tickets parallel an, der Support vergleicht mit seiner Aufnahme.
- Woche 3: Neue Meldungen laufen über den Agenten, Support und Entwicklung geben Rückmeldung.
- Woche 4: Auswertung: Vollständigkeit, Zahl der Rückfragen durch Support, Zeit bis zur Reproduktion.
Wir brechen den Pilot ab, wenn der Agent Ursachen vermutet oder Zusagen zur Behebung macht.
Wie Sie Wirkung feststellen
Tickets kommen vollständig bei der Entwicklung an, Rückfragen werden seltener, und Fehler werden schneller reproduziert. Der Support verbringt weniger Zeit mit Nachfragen und mehr mit Lösungen.
Fragen Sie die Entwicklung, ob die Tickets nützlich sind. Ihre Antwort bestimmt die Fragenliste.
Einwände aus dem Support
Der erste Einwand: Kunden sind genervt von Fragen. Deshalb bleibt die Liste kurz, und der Agent sagt, wozu die Angabe dient.
Der zweite: Manche Fehler lassen sich nur am Telefon klären. Dann übergibt der Agent mit der Zusammenfassung dessen, was er schon hat.
Kennzahlen
Aussagekräftig sind der Anteil der Tickets ohne Rückfrage, die Zeit bis zur Reproduktion und die Zahl der erkannten Dubletten. Sie beschreiben die Qualität der Aufnahme, nicht die Leistung einzelner Mitarbeitender.
Was Sie vorab klären können
- Nehmen Sie fünf Tickets und notieren Sie, welche Angaben zur Reproduktion fehlten.
- Schreiben Sie die Pflichtangaben für Fehlermeldungen auf.
- Klären Sie, wie Dubletten erkannt und verknüpft werden.
- Legen Sie fest, welche Meldungen sofort an die Sicherheitsstelle gehen.
Mehr zur Branche auf der Seite B2B-Software. Im Glossar: Ticketsystem, Übergabe an Menschen und Posteingang-Triage. Leistung: Support-Automatisierung.
Häufige Fragen
Stellt der Agent Diagnosen?
Nein. Er erfasst Angaben und verknüpft Tickets. Ursachen analysieren Support und Entwicklung.
Kann er Releasetermine nennen?
Nein. Behebungen und Releases kündigt das Produktmanagement an.
Was passiert bei Sicherheitslücken?
Er leitet nach Ihrer Regel sofort an die Sicherheitsstelle weiter und diskutiert nichts.
Wie werden Kundendaten in Screenshots behandelt?
Er weist auf die Gefahr hin und bittet um anonymisierte Beispiele.
Was kostet der Einstieg?
Ab 1.000 € Setup und ab 100 € im Monat für den Wissens-Agenten; Anbindung an Ticketsystem und Lizenzdaten richtet sich nach Umfang.
Quellen und rechtlicher Rahmen
- DSGVO, Art. 28 (Auftragsverarbeiter): Verarbeitet ein Dienstleister personenbezogene Daten im Auftrag, arbeitet der Verantwortliche nur mit Auftragsverarbeitern, die hinreichende Garantien für geeignete technische und organisatorische Maßnahmen bieten. Die Verarbeitung folgt einem Vertrag, der unter anderem Gegenstand, Dauer, Art und Zweck festlegt. (abgerufen 21. Oktober 2026)
- BSI: Generative KI-Modelle, Chancen und Risiken für Industrie und Behörden (21.1.2025): Das BSI beschreibt neben den Chancen neuartige IT-Sicherheitsrisiken generativer KI-Modelle sowie mögliche Gegenmaßnahmen. Es richtet sich an Unternehmen und Behörden, die den Einsatz in ihren Arbeitsabläufen erwägen. (abgerufen 21. Oktober 2026)
- KI-Verordnung (EU) 2024/1689, Art. 50 Abs. 1 (konsolidiert, Stand 27.7.2026): Anbieter von KI-Systemen, die direkt mit Personen interagieren, stellen sicher, dass diese informiert werden, dass sie mit einem KI-System interagieren, es sei denn, das ist aus den Umständen offensichtlich. Der Artikel gilt seit dem 2. August 2026. (abgerufen 21. Oktober 2026)
Die Zusammenfassungen sind sinngemäß; maßgeblich sind die verlinkten Originaltexte. Das ist ein allgemeiner Überblick zu Ihrem Umfeld, keine Rechtsberatung und keine Aussage zu Ihrem Einzelfall.
Autor: Melvin Mümken, Gründer & Technischer Leiter. Stand: 22.10.2026. Die Hinweise sind ein allgemeiner Überblick und keine Rechtsberatung.