Das strategische Produktmanagement von Unternehmen beschäftigt sich intensiv mit den Anwendern der eigenen Produkte und Dienstleistungen. Das Bestreben der Produktmanager ist dabei, Zielkunden und deren Kaufprozesse zu verstehen. Dazu werden Personas entwickelt, um den idealen Kunden, seine Situation und Bedürfnisse zu identifizieren. In Customer Journeys werden die Stufen und Touchpoints des Entscheidungs- und Kaufprozesses beschrieben. Es wird Marktforschung betrieben und es werden Interviews geführt. Wenn man es richtig anstellt, können Rückmeldungen aus dem Support eine zusätzliche wichtige Quelle für wertvolle Erkenntnisse über das Kundenverhalten sein. Noch besser und qualifizierter ist dieses Feedback, wenn die Serviceorganisation nach der Knowledge-Centered Service-Methode arbeitet.

Sollten Sie selber Produktmanager *in sein, sind Ihnen Organisationsstruktur und Arbeitsweise in Support und Service vielleicht nicht ganz geläufig. Daher hole ich etwas aus.

Serviceorganisationen denken und handeln typischerweise in Eskalationen.

Die meisten Serviceorganisationen sind mehrstufig organisiert, in die sogenannten Level 1, Level 2 und Level 3. Ob diese Service-Abstufungen bei Ihnen genauso heißen oder ganz anders, ist für meine Betrachtung irrelevant. Es geht hier um die hierarchische Organisationsform mit dem Denk- und Handlungsprinzip der Eskalation:

  • Level 1: Die erste Stufe eines Service Desk mit direktem Kundenkontakt. Hier wird Anwendern Hilfestellung und genereller Support bei Fragen und Problemen in der Nutzung von (IT-) Lösungen geleistet. Oft sind die Hilfestellungen des Level 1 auf Themen begrenzt, die bereits bekannt und, z.B. in einer Wissensdatenbank, dokumentiert sind.
  • Level 2: Die zweite Stufe eines Service Desk mit tieferen allgemeinen oder speziellen Kenntnissen. Es besteht kein direkter Kundenkontakt, sondern der Level 2 bearbeitet nur Anfragen, die aus dem Level 1 fachlich eskaliert worden sind. Hier werden die Ursachen für unbekannte Störungen recherchiert und, soweit möglich, Lösungen durch Änderungen von Einstellungen und Konfigurationen ermittelt. Diese werden dokumentiert und dem Level 1 zur Übermittlung an den Kunden übergeben.
  • Level 3: Manchmal die letzte Stufe innerhalb des Service, oft auch schon organisatorischer Teil der Produktentwicklung. Hier befinden sich Spezialisten-Teams, häufig mit Fokus auf bestimmte Produkte, Technologien oder Anwendungen. Sie erhalten aus dem Level 2 eskalierte Vorgänge, die sich durch Änderungen der Konfiguration alleine nicht beheben lassen, sondern strukturelle Änderungen am Produkt erfordern. Diese Änderungen, z.B. bei Software-Produkten sogenannte Patches, werden hier erstellt und insbesondere auf Wechselwirkungen mit anderen Änderungen und Erweiterungen getestet. Falls der Level 3 organisatorisch noch zum Service gehört, liefert er diese Änderungen als Vorschlag an die Entwicklung bzw. das Produktmanagement, die dann letztendlich die Entscheidung zur Einarbeitung  der Änderung treffen. Meist wird dafür ein anderes System (Bugtracking) verwendet als das im Service eingesetzte „Ticketsystem“. So kommt es zum Medienbruch im Prozess.

Service-Organisation als mehrstufiges Filter von Kundenanfragen

Supportstufen-1-2-3

Supportstufen-1-2-3

Stellen Sie sich die Arbeitsweise dieser Organisation wie einen Trichter vor, in dem die Level wie Filter wirken. Oben in die Öffnung gelangen alle Vorgänge hinein (je nach Organisation werden sie Ticket, Incident, Störung o.ä. genannt). Die Erwartungshaltung an die Filterleistung des Level 1 folgt meist dem Pareto-Verhältnis: 80 Prozent der Vorgänge sollen im Level 1 erfolgreich bearbeitet werden, nur 20 Prozent werden an den Level 2 eskaliert. Das wiederholt sich sinngemäß in Level 2 und 3 genauso.

Lassen Sie uns das mit konkreten Zahlen durchspielen, damit der Effekt deutlicher wird. Fiktive 10.000 Vorgänge gelangen an den Level 1. Dort werden 8000 Vorgänge erfolgreich gelöst, somit landen 2000 Vorgänge im Level 2. Dort wiederum werden 1600 Vorgänge gelöst und 400 Fälle an den Level 3 eskaliert. Somit soll der Level 3 aus diesen 400 Fällen 320 selber lösen und nur 80 Vorgänge an Produktmanagement und Entwicklung eskalieren.

Das bedeutet, von den insgesamt 10.000 Problemen, die unsere Kunden mit unseren Produkten und Dienstleistungen gehabt haben, landen nur 80 Fälle (oder 0,8 Prozent) auf dem Schreibtisch des Produktmanagements. Diese 80 Vorgänge stellen Ihre Erkenntniswelt dar, auf sie stützen Sie sich bei den Entscheidungen, wo in Produktverbesserungen und neue Funktionen investiert werden soll. Ohne gleich das Höhlengleichnis zu bemühen wird klar, dass der Horizont des Produktmanagements auf die Probleme und das Feedback der Endkunden systembedingt eingeschränkt ist.

Diese Situation wird sogar noch dramatischer, wenn man sich den Effekt von Self-Service und Communities vor Augen führt.

Abgestufter Service filtert auch Kundenfeedback weg.

Manche Unternehmen sind dazu über gegangen, auf sogenannten Self-Service-Portalen Teile ihres bekannten Lösungswissens den Endkunden zur Verfügung zu stellen. Dies geschieht in der Regel aus der Erkenntnis heraus, dass Kunden auf diese Weise schneller an bekanntes Wissen gelangen. Sie sind auf diese Weise nicht auf die Verfügbarkeit des telefonischen oder E-Mail-Supportes angewiesen. Diese Verfügbarkeit wird nämlich nachfragebedingt schwanken, was dann zu Wartezeiten führen kann. Diese Wartezeiten und das oft negative Serviceerlebnis an den Telefon-Hotlines treiben Anwender letztlich „freiwillig“ in den Self-Service. Der demografische Wandel verstärkt den Trend noch weiter. Laut einer Studie von 2016 würden 42 % der Millenials lieber eine Toilette reinigen, statt eine Hotline anrufen zu müssen. Und, Hand aufs Herz, wo suchen Sie nach Lösungen für Probleme mit einem gekauften Produkt? Auf der Webseite des Herstellers oder lieber gleich bei der Suchmaschine Ihrer Wahl? Genau.

Die Chance ist groß, dass Sie dabei in den Foren einer Community landen. Das sind virtuelle Diskussionräume, oft nicht einmal von den Herstellern selber betrieben, in denen sich Anwender*innen über den Gebrauch der spezifischen Produkte untereinander austauschen. Dort wird, zum Teil mit großem Sachverstand und viel Engagement, diskutiert und Hilfestellung geleistet. Für diesen Service sind in der Regel keine Kosten fällig, bestenfalls jedoch eine Art Mitgliedsgebühr, um den Betrieb der Foren zu finanzieren. Diese Kosten liegen jedoch Dimensionen unter denen, die für einen Servicevertrag mit dem Hersteller fällig wäre.

Der Bedarf an Service ist größer, als im Servicecenter sichtbar wird.

Die Mitglieder des Consortium for Service Innovation haben in langjährigen Untersuchungen den Gesamtbedarf an Service und Support ermittelt. Er setzt sich zusammen aus den Anfragen an das Servicecenter, der Recherche im Self-Service-Portal und der Suche in Communities. Das ermittelte Verhältnis für die drei Anfragequellen beträgt demnach

x : 10x : 30x

Wenn Sie also in Ihrem Servicecenter die besagten 10.000 Anfragen sehen, müssen Sie davon ausgehen, dass weitere 100.000 Anfragen im Self-Service selber gelöst werden. Weitere 300.000 Anfragen werden in irgendwelchen Communities diskutiert, von denen Sie im Zweifel nicht einmal wissen. Was wiederum bedeutet, nur 2,4 % des Gesamtbedarfes an Service landet überhaupt in der Level 1,2,3-Struktur des Servicecenters. Und von denen bekommen Sie als Produktmanager *in nur 0,8 % zu sehen! Vielleicht war der Bezug zum Höhlengleichnis doch ganz passend?

Wieso macht Knowledge Centered Service (KCS©) einen Unterschied aus?

KCS ist eine Methodik, die das kollektive Wissen einer Supportorganisation als zentralen Bestandteil für die Serviceerbringung ansieht. Dahinter steckt die Erkenntnis, dass das kollektive Wissen einer Gruppe immer vollständiger ist, als das der jeweiligen Individuen. Dieses Wissen des Kollektivs wird in einer Wissensdatenbank verfügbar gemacht. Bestehendes Wissen wird dort gefunden und kann wieder verwendet werden. Bei der Wiederverwendung wird während des Gebrauches das Wissen auf Aktualität überprüft und gegebenenfalls überarbeitet.

Der zweite wesentliche Aspekt beruht auf dem Wesen won Wissen an sich. Wissen besteht aus Daten und Informationen, denen in einem bestimmten Kontext eine Bedeutung gegeben wird. Verdeutlichen lässt sich das am besten mit dem berühmten weißen Blatt Papier, das vor einem liegt. Der Aufforderung „Schreiben Sie mal alles auf, was Sie wissen!“ können Sie schlecht nachkommen. Wo fängt man, wo hört man auf? „Schreiben Sie mal auf, wie man Kaffee kocht.“ ist hingegen eine bewältigbare Aufgabe, vorausgesetzt, man verfügt über das Wissen, wie Kaffee gekocht wird. Nutzbares Wissen entsteht demnach dann, wenn es von implizitem zu explizitem Wissen wird. Oder, um mit Dave Snowden zu sprechen:

„We don’t know what we know until someone asks us.“

Anders als in anderen Serviceprozessmodellen wird bei KCS der Kontext des Kunden explizit mit erfasst und im Wissensartikel beschrieben: Was genau wurde versucht zu tun, was hat nicht funktioniert und aus welchen Komponenten besteht die Kundenkonfiguration?  Das geht weit über das hinaus, was üblicherweise in Support-Tickets erfasst wird. Da Wissen immer aus Informationen in einem bestimmten Kontext bestehen, sind Inhalt und Kontext gleichermaßen wichtig. Zudem stellt der erfasste Kontext sicher, dass das Problem in der Sprache des Kunden beschrieben wird. Dies führt zu besserer Auffindbarkeit von relevanten Artikeln, als wenn zwar technisch präzisere, doch von typischen Kunden nicht verwendete Begriffe genutzt werden.

Wissen wird als Nebenprodukt der Problemlösung erzeugt.

Der beste Zeitpunkt zum Erfassen und Dokumentieren dieses Wissens ist der Moment des Entstehens, also während der Interaktion mit dem Kunden. Dem trägt KCS Rechnung, indem die Methode die Dokumentation in den Problemlösungsprozess verlagert und dort zum integralen Bestandteil macht.

KCS-Workflow: UFFA

KCS-Workflow: UFFA

Der Prozess beginnt mit der Suche in der Wissensdatenbank nach wiederverwendbarem Wissen. Passt es zur Problembeschreibung des Kunden und ist vollständig und aktuell, kann es direkt genutzt werden. Fehlen Aspekte darin oder sind veraltet, wird es vor dem Versenden an den Kunden in der Wissensdatenbank aktualisiert. Fehlen dazu die Kenntnisse oder Berechtigungen, wird der Artikel zumindest als zu überarbeiten gekennzeichnet. Wird kein Wissen gefunden, muss es wie in anderen Organisationen auch jetzt erarbeitet werden.

In der KCS-Welt nutzt man also nicht nur kollektives Wissen, sondern setzt auch auf die kollektive Verantwortung aller Wissensarbeitenden für Inhalt und Qualität der Wissensdatenbank. Das Wissen der Anderen ungeprüft zu verwenden oder selber halbfertige Lösungen zu beschreiben, schadet nicht nur den betroffenen Kunden, sondern dem ganzen Kollektiv. Darum funktioniert KCS nur in einer lernenden Organisation, in der das Teilen von Wissen und voneinander zu lernen zur Unternehmenskultur gehört.

Der dritte bedeutende Unterschied ist das Feedback zur Artikelqualität. Die KCS-Methode sieht vor, dass ein zur Lösung des Kundenproblemes herangezogener Artikel mit dem Vorgang im System verknüpft wird. Jedes Mal, wenn Wissensarbeitende einen Artikel wieder verwenden und erfolgreich ein Problem damit lösen, wird der entsprechende Zähler hochgezählt. Über die Zeit sieht man also, welche Artikel tatsächliche Probleme von tatsächlichen Kunden lösen und welche nicht. Das alleine ist wertvolles Feedback für das Produktmanagement. Zugleich wird bei jedem Wiedergebrauch der Artikel erneut qualitätsgesichert und aktualisiert.

Aktuelles Wissen ist Voraussetzung für erfolgreichen Self-Service.

Nun stellen Sie sich vor, dass Sie das vorhandene Wissen der internen Knowledgebase Ihren Kunden nach außen in einem Self-Service-Portal öffneten. Stellen Sie Ihren Kunden darin eine Funktion zur Verfügung, Feedback geben können in der Art „Dieser Artikel hat mein Problem behoben.“.  Das Ergebnis wäre noch valideres Feedback von einer noch größeren Kundenzahl.

Gehen Sie noch einen Schritt weiter und analysieren Sie das Suchverhalten Ihrer Kunden im Portal („click stream analysis“). Sie würden Muster im Suchverhalten entdecken: immer wiederkehrende Klickverläufe und auch Brüche in der Navigation durch die Artikel. Dadurch würden Sie feststellen, an welcher Stelle die Kunden ihre Suche abbrechen, also welche Wissensartikel noch Lücken aufweisen, bzw. durch andere Artikel ergänzt werden müssen. Das können zum Beispiel Artikel sein, in denen die Diagnostik beschrieben wird, mit der man beobachtete Symptome ihren Ursachen zuweisen bzw. zwischen ihnen differenzieren könnte.

Auf diese Weise würde Ihr Self-Service-Portal immer vollständiger und aktueller werden. Sie würden qualifiziertes Feedback und aus den Zugriffszahlen quantitative Rückschlüsse gewinnen und mit dessen Hilfe bessere Produkte und Services gestalten können. Und je mehr Wissen in Ihrem Portal zur Verfügung steht, desto geringer ist die Neigung Ihrer Kunden an anderen Orten zu suchen und Ihnen damit dieses wertvolle Feedback zu entziehen.

Muster in der Suche sind wertvolles Feedback für das Produktmanagement.

Zusammen gefasst bedeutet es, dass eine Organisation die nach KCS-Methodik arbeitet:

  • vollständigeres und aktuelleres Wissen generiert,
  • aus dem Wiedergebrauch bestehendes Wissens wertvolles Feedback über dessen Kundennutzen gewinnt,
  • mithilfe des Wissens attraktiven Self-Service anbieten und darüber weiteres Feedback gewinnen kann
  • und somit die Möglichkeit hat, bessere Produkte und Services für ihre Kunden zu schaffen.

Wenn Sie als Produktmanager *in die Verantwortung für den Gewinn und Verlust ihres Produktes haben, sollten Ihnen diese Möglichkeiten am Herzen liegen. Falls in Ihrem Unternehmen der Service noch nicht nach Knowledge-Centered Service-Methodik arbeitet, reden Sie doch einfach mit denen und überzeugen Sie sie von den Vorteilen.