Wissensarbeit im Support: Wissen, das Fälle löst statt in Ablagen zu liegen
Die Antwort existiert meistens. Sie liegt nur in Confluence, in alten Tickets oder in Köpfen. Wie strukturiertes Wissen Agenten trägt und wie eine Lückenanalyse zeigt, was zuerst fehlt.
Das Frustrierende an vielen Support-Fällen ist nicht, dass die Antwort fehlt. Sie existiert. Die Anleitung liegt in Confluence, die Lösung steht in einem Ticket von vor acht Monaten, den Prozess kennt eine Kollegin auswendig. Nur findet all das niemand rechtzeitig, und so wird derselbe Fall zum dritten Mal von Hand gelöst.
Für Menschen ist das ärgerlich. Für KI Agenten ist es ein Ausschlusskriterium: Ein Agent, der Wissen nicht zuverlässig findet, rät. Und ein ratender Agent ist im Support schlimmer als gar keiner.
Warum eine FAQ für Agenten nicht reicht
Der erste Reflex ist oft, die vorhandenen Dokumente in eine Suche zu kippen und darüber einen Chatbot zu setzen. Das scheitert regelmäßig am selben Punkt: Dokumente beschreiben Sachverhalte, aber sie modellieren sie nicht. Welche Fehlermeldung zu welchem System gehört, welcher Lösungsweg welche Voraussetzungen hat, wer für welchen Dienst zuständig ist, steht zwischen den Zeilen.
nara Memory geht deshalb einen Schritt weiter und modelliert Wissen als Schemas, Objekte und Beziehungen in einem Knowledge Graph. Symptome, Systeme und Lösungswege sind verknüpft statt nur verschlagwortet. Dokumente und Tickets werden fortlaufend importiert, und Agenten wie Menschen greifen auf dieselbe Wissensschicht zu.
Antworten mit Beleg
Der sichtbarste Unterschied im Alltag: Agenten beantworten Fälle aus Memory und Knowledge Graph und verweisen auf die Quelle, statt zu raten. Wer die Antwort liest, kann prüfen, worauf sie beruht. Und wenn das Wissen nicht ausreicht, ist Nichtwissen ein Ergebnis: Der Agent leitet den Fall an die richtige Fachperson weiter und dokumentiert die Antwort, damit sie beim nächsten Mal existiert.
Lücken finden: die Wissensbasis gegen das reale Aufkommen prüfen
Die meisten Wissensbasen sind historisch gewachsen. Geschrieben wurde, was gerade anlag oder wofür sich jemand verantwortlich fühlte, nicht das, was am häufigsten gebraucht wird. Ob die Wissensbasis zum tatsächlichen Aufkommen passt, lässt sich messen: durch den Abgleich von Ticket-Historie und vorhandenen Artikeln.
Wie das aussehen kann, zeigt eine anonymisierte Analyse für eine europäische Fertigungsgruppe auf Basis von 43.676 ServiceNow Incidents. Die bestehende Wissensbasis umfasste 85 Artikel. Der Abgleich mit dem realen Ticketaufkommen machte sichtbar, für welche häufigen Fälle Anleitungen komplett fehlten. Für die größten Lücken erstellte nara 20 Artikelentwürfe, die das Team anschließend prüfte und freigab. Das Ergebnis war keine schönere Dokumentation, sondern eine priorisierte Liste: Welches Wissen fehlt, und was sollte zuerst geschrieben werden.
Entwerfen dürfen Agenten, freigeben nur Menschen
Der Schritt vom gelösten Fall zum Wissensartikel ist Fleißarbeit, und genau deshalb unterbleibt er so oft. Agenten können ihn übernehmen: Aus gelösten Fällen und der Ticket-Historie entstehen Artikelentwürfe, fertig strukturiert und mit Bezug auf die zugrunde liegenden Vorgänge.
Gültig wird neues Wissen damit noch nicht. Jeder Entwurf geht zur Prüfung und Freigabe an das Team. Ohne diesen Schritt würde ein ungeprüfter Einzelfall zur allgemeinen Regel, und die Wissensbasis wäre schnell weniger wert als vorher. Die Freigabe von Wissen bleibt Menschenarbeit, so wie Freigaben, Zahlungen und Personalentscheidungen generell bei Menschen bleiben.
Wissen ist Infrastruktur, keine Ablage
Wer Support automatisieren will, baut zuerst an der Wissensschicht. Sie entscheidet darüber, ob ein Agent mit Beleg antwortet oder plausibel klingt, und sie entscheidet darüber, was sich überhaupt automatisieren lässt. Was davon in Ihrer Umgebung trägt, wird pro Stack validiert, nicht pauschal versprochen.
Der nüchternste Einstieg ist der Blick auf die eigenen Daten: Welche Fälle kommen am häufigsten, und welche davon deckt Ihre Wissensbasis heute ab? Genau diesen Abgleich machen wir in einer Ticketanalyse. Sie zeigt die größten Lücken und liefert die Reihenfolge, in der sich das Schreiben lohnt. Mehr zum Vorgehen steht auf der Seite zur Ticketanalyse.