KI im Service: So erkennen Sie die Lücken in Ihrer Wissensbasis

Die meisten Wissensdatenbanken im Service haben kein Inhaltsproblem, sondern ein Messproblem. Oft sind bereits zahlreiche Artikel vorhanden – viele davon sogar gut gepflegt. Was jedoch kaum ein Unternehmen beantworten kann, ist, welcher Anteil der gelösten Servicefälle wirklich von Artikeln abgedeckt wird.

Diese Kennzahl existiert in den wenigsten Serviceorganisationen. Und wenn sie doch erhoben wird, fällt sie meist zu positiv aus. Ich habe diesen Ablauf im Bereich KI im Service als praxisnahen Anwendungsfall für Serviceleitungen umgesetzt. In diesem Artikel zeige ich, warum eine realistisch berechnete Deckungsquote zunächst sinkt, weshalb genau diese niedrigere Zahl die aussagekräftige ist und welchen Beitrag ein Sprachmodell dabei tatsächlich leistet.

Die Kennzahl, die kaum jemand nutzt

Die Gesundheit einer Wissensbasis zeigt sich nicht an der Anzahl ihrer Artikel, sondern an ihrer tatsächlichen Abdeckung. Im Zähler stehen alle gelösten Servicefälle eines Zeitraums, für die ein vorhandener Wissensartikel den jeweiligen Fallgrund abdeckt. Im Nenner stehen sämtliche gelösten Fälle desselben Zeitraums. Nur diese Quote beantwortet die entscheidende Frage.

Die Anzahl der Artikel sagt nichts darüber aus, ob die relevanten Themen überhaupt dokumentiert sind. Zugriffszahlen zeigen, wie gut Artikel gefunden werden, nicht aber, ob wichtige Inhalte fehlen. Ein selten aufgerufener Artikel kann den einzigen Leitfaden für einen kostspieligen Spezialfehler enthalten, während der meistgelesene Beitrag lediglich erklärt, wie ein Passwort zurückgesetzt wird. Und selbst hohe Zufriedenheitswerte beziehen sich nur auf vorhandene Artikel und nicht auf die Themen, zu denen gar keine Dokumentation existiert.

Der Fall, an dem sich das zeigen lässt

Nehmen wir einen Hersteller von Verpackungsmaschinen aus dem ersten Anwendungsfall mit rund 500 Mitarbeitenden, etwa 4.000 Anlagen im Einsatz sowie Molkereien und Getränkeabfüllern als Kunden. Die Serviceleitung betrachtet 1.240 abgeschlossene Servicefälle. Rund 305 davon lassen sich keinem wiederkehrenden Fallgrund zuordnen und bleiben deshalb als Ausreißer bestehen. Die übrigen Fälle verteilen sich auf sechs Cluster. Die ausgewiesene Deckungsquote liegt bei 68 Prozent.

Auf den ersten Blick wirkt die Wissensbasis gut gepflegt. Lediglich für den Etikettierer fehlt ein Artikel. Alle anderen häufigen Fallgründe scheinen dokumentiert zu sein, darunter auch der bekannte Fehler E-207 mit einer Anleitung zum Austausch der Heizpatrone. Unter diesen Voraussetzungen könnte eine Serviceleitung zu dem Schluss kommen, dass Wissensmanagement aktuell keine hohe Priorität hat.

Warum die Deckungsquote zunächst sinkt

Der entscheidende Schritt besteht darin, die Fallgruppen vollständig neu zu bilden – ausschließlich auf Basis der Tickettexte. Die vorhandenen Kategorien im Ticketsystem bleiben dabei bewusst unberücksichtigt. Fallbeschreibung und Lösungsnotizen werden zunächst auf ihren eigentlichen Sachverhalt verdichtet, anschließend werden ähnliche Fälle zusammengefasst und erst danach mit den vorhandenen Wissensartikeln abgeglichen.

Im Beispiel zeigt sich, dass rund 55 Tickets, die bislang der Kategorie „Passwort- und Login-Rücksetzung“ zugeordnet waren, in Wirklichkeit zu anderen Themen gehören. Sie wurden damals mit einem Standardtext abgeschlossen, weil sie über dieselbe Eingangsmaske eingingen wie echte Login-Probleme. Anschließend bestand kein Anlass mehr, die ursprüngliche Zuordnung zu hinterfragen.

Gleichzeitig werden zwei wiederkehrende Problemursachen sichtbar, die bisher überhaupt nicht als eigene Kategorien existierten. Der Fehler E-514 nach dem Firmware-Update 4.2 steckt in 96 Fällen – durchschnittlich etwa zwölf pro Monat. Hinzu kommen 88 Anfragen zum Lieferstatus bestellter Ersatzteile, also rund neun pro Monat.

Dadurch sinkt die ausgewiesene Deckungsquote von 68 auf 63 Prozent.

Dabei hat sich am Service nichts verändert. Kein Wissensartikel ist verschwunden, kein Kunde ist unzufriedener geworden. Verändert hat sich lediglich die Qualität der Messung.

Der Grund liegt im Aufbau vieler Ticketsysteme. Kategorien orientieren sich an den Problemen, die beim Einführen des Systems bekannt waren. Neue Fälle werden später meist der ähnlichsten vorhandenen Kategorie zugeordnet.

Welche Aufgaben KI übernimmt – und welche nicht

Bei diesem Anwendungsfall lohnt sich eine klare Trennung zwischen KI und klassischer Datenverarbeitung. Tatsächlich benötigen nur zwei der sieben Arbeitsschritte ein Sprachmodell.

Lösungsnotizen sind in der Praxis oft knapp formuliert: „Temp.fenster CIP geweitet, lief danach“ oder „Reset durchgeführt, Anlage ok“. Für Menschen mit Erfahrung sind solche Einträge verständlich, für eine systematische Auswertung jedoch kaum vergleichbar.

Ein Sprachmodell kann diese Notizen auf ihren eigentlichen Sachverhalt verdichten und unterschiedliche Formulierungen in eine gemeinsame Beschreibung überführen. Erst dadurch lassen sich ähnliche Fälle zuverlässig zusammenführen.

Das eigentliche Clustering ist anschließend keine KI-Aufgabe mehr. Sind die Problemursachen einmal vereinheitlicht, übernehmen Machine Learning Verfahren das Gruppieren, Zählen und Auswerten. Auch der Abgleich mit vorhandenen Wissensartikeln sowie die Berechnung der Deckungsquote folgen klaren Regeln.

Warum die fachliche Freigabe unverzichtbar bleibt

Trotz des KI-Einsatzes gibt es im gesamten Ablauf genau einen Schritt, der nicht automatisiert werden sollte: die Veröffentlichung eines neuen Wissensartikels.

Zu diesem Zeitpunkt liegt bereits ein vollständiger Entwurf vor – mit Symptomen, Ursache, Lösung und Geltungsbereich. Die verantwortliche Fachperson prüft den Inhalt, ergänzt fehlende Hinweise und entscheidet über die Freigabe.

Was neue Wissensartikel tatsächlich bewirken

Sobald der Wissensartikel zum Fehler E-514 veröffentlicht ist, verbessert sich die Deckungsquote unmittelbar. Die bislang ungedeckten 96 Fälle zählen nun als abgedeckt und die Kennzahl steigt wieder – diesmal nicht aufgrund einer optimistischeren Bewertung, sondern weil tatsächlich eine Lücke geschlossen wurde.

Darüber hinaus lässt sich abschätzen, welchen Nutzen der neue Artikel künftig bringt. Im Beispiel treten durchschnittlich rund zwölf Fälle pro Monat zu diesem Fehler auf. Ein Teil davon kann künftig schneller gelöst oder bereits durch Selbsthilfe vermieden werden. Wie groß dieser Effekt tatsächlich ist, hängt allerdings von mehreren Faktoren ab: Nutzen Kunden das Serviceportal? Finden Mitarbeitende den Artikel im richtigen Moment? Und wird der erwartete Effekt später anhand der realen Fallzahlen überprüft?

Der Cluster rund um Ersatzteil-Lieferzeiten zeigt ein anderes Problem. Die 88 Anfragen entstehen nicht, weil Informationen fehlen, sondern weil Kunden aktiv nach dem Status ihrer Bestellung fragen müssen. Ein Wissensartikel kann hier zwar kurzfristig helfen, indem er auf die Sendungsverfolgung verweist. Die eigentliche Ursache liegt jedoch im Prozess. Sinnvoller wäre eine automatische Statusinformation, bevor der Kunde überhaupt nachfragt.

Gerade darin liegt ein zusätzlicher Nutzen der Auswertung: Sie zeigt nicht nur Lücken in der Wissensbasis, sondern macht auch Schwachstellen im Serviceprozess sichtbar.

Welche Voraussetzungen erfüllt sein müssen

Die Auswertung selbst ist technisch überschaubar. Entscheidend ist jedoch, dass einige grundlegende Voraussetzungen erfüllt sind.

• Aussagekräftige Lösungsnotizen. Abgeschlossene Tickets sollten nachvollziehbar dokumentieren, was tatsächlich getan wurde. Ein Eintrag wie „erledigt“ liefert keine Grundlage für eine inhaltliche Auswertung.

• Zentral verfügbare Wissensartikel. Die Wissensartikel müssen strukturiert und durchsuchbar vorliegen. Nur dann lassen sie sich systematisch mit den Servicefällen abgleichen.

Eine Wissensbasis pflegt sich nicht von selbst. Die Qualität der Ergebnisse hängt unmittelbar von der Qualität der vorhandenen Servicedokumentation ab. Sind Lösungsnotizen unvollständig oder uneinheitlich, lassen sich auch mit KI keine belastbaren Aussagen ableiten.

Fazit

Eine Wissensbasis wird nicht an der Zahl ihrer Artikel gemessen, sondern daran, wie viele reale Servicefälle sie tatsächlich abdeckt. Eine belastbare Deckungsquote fällt anfangs oft niedriger aus – nicht weil der Service schlechter ist, sondern weil erstmals die tatsächlichen Lücken sichtbar werden. Genau darin liegt ihr Wert: Sie schafft eine verlässliche Grundlage, um Wissensmanagement gezielt weiterzuentwickeln.

Zur stilistischen und formalen Überarbeitung dieses Textes wurde KI genutzt – der Inhalt blieb davon unberührt.