Priorisiere Support-Tickets nach dem, was wirklich wiederkehrt
5 Min. Lesezeit
Die meiste Priorisierung beginnt bei den Tickets, die ein PM zufällig kürzlich gelesen hat, oder bei denen, die laut eskaliert wurden. Das ist nicht dasselbe, wie zu wissen, was tatsächlich am häufigsten vorkommt, und es heißt, dass ein stilles, aber häufiges Problem jedes Mal gegen ein seltenes, aber lautes verlieren kann. Ein PM, der montagmorgens die Support-Warteschlange öffnet, handelt viel wahrscheinlicher am Ticket, das ein Account Manager übers Wochenende eskalierte, als an der Tatsache, dass dreißig andere Nutzer im vergangenen Monat leise eine kleinere Fassung derselben zugrunde liegenden Reibung meldeten.
Achtung
Ein Ticket, an das du dich erinnerst, und ein Ticket, das wiederkehrt, sind verschiedene Signale. Das, an das du dich erinnerst, ist vielleicht nur das, das eskaliert wurde, nicht das, das die meisten Nutzer betrifft.
Das Ticket, an das du dich erinnerst, ist nicht immer das, das zuerst behoben werden sollte. Das, das immer wiederkehrt, ist es.
Warum das Lesen von Tickets der Reihe nach die echte Häufigkeit nicht zeigt
Eine Support-Warteschlange durchzulesen gibt dir Eindrücke, keine Zählungen. Ein Problem, das fünfzehn verschiedene Nutzer auf fünfzehn Arten melden, sieht nicht wie ein Muster aus, wenn du ein Ticket nach dem anderen liest, es sieht wie fünfzehn einzelne Beschwerden aus. Die mentale Anstrengung, über Dutzende Tickets mit jeweils anderer Formulierung eine laufende Zählung zu halten, ist genau die Art Zählaufgabe, bei der ein menschlicher Prüfer schlecht ist und zum Unterschätzen neigt.
Stell dir die Support-Warteschlange eines Onboarding-Flows vor, in der ein Nutzer, ein Enterprise-Konto, laut einen verwirrenden Einrichtungsschritt eskaliert. Dieses Ticket bekommt schnell Aufmerksamkeit. Währenddessen reichen in derselben Woche dreißig Nutzer des kostenlosen Tarifs leise Tickets zum selben Schritt ein, in dreißig Formulierungen, keines eskaliert, keines für sich alarmierend. In Eingangsreihenfolge gelesen, dominiert das laute Enterprise-Ticket das mentale Modell des PM davon, was kaputt ist, während das tatsächlich häufigste Problem, das weit mehr Nutzer betrifft, als Muster über dreißig einzelne Tickets unerkannt bleibt.
Vorher: die jüngsten Tickets überfliegen, die priorisieren, die am dringendsten wirken oder eskaliert wurden, weitermachen.
Nachher: einen Stapel Tickets in Claude einfügen, bitten, sie zu Themen nach Zahl der Tickets je Thema zu gruppieren, und nach echter Häufigkeit priorisieren.
Ein Vorgehen, Tickets in geordnete Themen zu verwandeln
- 1
Sammle einen echten Stapel, nicht eine Handvoll
Zieh Tickets aus einem festgelegten Zeitfenster, einer ganzen Woche oder einem Monat, statt dem, was gerade in deinem Posteingang liegt. Eine Teilstichprobe neigt zu dem, was zuletzt hereinkam.
- 2
Bitte um nach Häufigkeit gruppierte Themen, nicht um eine Zusammenfassung
Eine Zusammenfassung verdichtet, was gesagt wurde. Verlange gezielt Tickets, zu wiederkehrenden Themen gruppiert, mit der Zahl der Tickets in jeder Gruppe.
- 3
Bitte um ein repräsentatives Ticket pro Thema
Ein echtes Beispiel verankert jedes Thema in etwas Konkretem, und es ist später nützlich, wenn du eine Priorität mit einem tatsächlichen Fall belegen musst, nicht nur mit einer Zahl.
- 4
Priorisiere nach Zahl, prüfe dann mit der Schwere gegen
Häufigkeit sagt dir, was verbreitet ist, nicht unbedingt, was am teuersten ist. Prüfe mit der geordneten Liste, ob ein weniger häufiges Thema wegen seiner Schwere dennoch nach oben gehört.
Hier sind 30 Support-Tickets zu unserem Onboarding-Flow. Gruppiere sie zu den drei häufigsten Beschwerden und sag mir, wie viele Tickets in jede Gruppe fallen.
”Sind die Themen geordnet, lohnt es sich zu prüfen, ob sie gegenüber einem früheren Zeitraum gewachsen oder geschrumpft sind, denn ein Thema, das Woche für Woche rasant zunimmt, ist eine andere Art Dringlichkeit als ein monatelanges, gleichmäßiges Grundrauschen.
Hier ist dieselbe Themenaufteilung vom letzten Monat. Vergleiche beide und sag mir, welche Themen als Anteil an allen Tickets wachsen, nicht nur, welche diesen Monat die höchste Rohzahl haben.
”
In Claude Tutorial
Nach echter Häufigkeit statt Aktualität zu ordnen, ist übertragbar.
Verstreute Meldungen zu gezählten Themen zu gruppieren, statt zu priorisieren, was du zuletzt gesehen hast, gilt weit über Support-Tickets hinaus. Die App hat dazu eine vollständige Lektion, mit Übungen, die für jedes Feedback gelten, auf das du reagieren musst.
Wenn Häufigkeit und Schwere in verschiedene Richtungen zeigen
Manchmal ist das häufigste Thema nicht das schädlichste. Ein häufig gemeldetes kleines Ärgernis und ein seltener, kontoblockierender Fehler verdienen beide einen Platz auf der Liste, nur nicht unbedingt in Häufigkeitsreihenfolge. Häufigkeit als einzigen Input zu behandeln riskiert, seltene, aber schwere Probleme systematisch zu unterpriorisieren, die nicht viele Tickets erzeugen, einfach weil die betroffenen Nutzer nicht weit genug ins Produkt kommen, um eines einzureichen.
Tipp
Bitte Claude zu markieren, welche Themen Nutzer vollständig blockieren und welche sie nur stören. Ein blockierendes Problem mit weniger Meldungen kann dennoch ein größeres, aber wenig schweres Thema überholen.
Welche der drei gefundenen Themen betreffen Nutzer, die das Onboarding gar nicht abschließen können, und welche nur von Reibung genervte? Ich will die Schwere neben der Häufigkeit abwägen, bevor ich die Priorität festlege.
”Es lohnt sich auch zu prüfen, ob ein seltenes, aber schweres Thema gerade deshalb unterberichtet sein könnte, weil es schwer ist, denn ein Nutzer, der früh im Onboarding auf eine harte Sperre stößt, verlässt das Produkt vielleicht ganz, statt sich die Zeit für ein Ticket zu nehmen.
Dieses blockierende Problem erzeugte nur 3 Tickets, was für etwas so Schweres wenig scheint. Gibt es einen Grund, warum ein blockierendes Problem wie dieses weniger gemeldet wird als ein mildes, bei dem Nutzer weitermachen können?
”Weiterlesen
- Ein Roadmap-Dokument schreiben, das die Abwägungen erklärt: eine geordnete Themenliste in eine Roadmap-Entscheidung verwandeln, der Stakeholder folgen können.
- Ein PRD aus einer einzeiligen Feature-Anfrage schreiben: was zu tun ist, sobald ein Thema ein spezifizierungswürdiges Feature aufzeigt.
- Ein PRD schärfen, bevor du es zur Prüfung schickst: Randfälle abfangen, auf die ein Thema wie dieses vor der Prüfung hindeuten kann.