Ein Entscheidungsprozess
The Kanso Filter.
Sechs Fragen, bevor eine Änderung eingeführt wird.
Wir wenden ihn an, bevor wir eine Änderung an einem Service-Team empfehlen. Die meisten Änderungen, die scheitern, scheitern nicht im Aufbau. Sie werden eingeführt, ohne eine klare Antwort auf eine dieser sechs Fragen zu haben. Der Filter erzwingt diese Antworten, bevor die Arbeit beginnt, solange es noch günstig ist, darauf zu reagieren. Wenden Sie ihn auf Ihre eigenen Entscheidungen an, auf Anbieter-Vorschläge und auf unsere.
Warum dieser Filter existiert
Er begann als Aufstellung von Arbeit, die nirgendwo hinführte.
Wir haben immer wieder beobachtet, wie Änderungen eingeführt wurden, die einen Workflow, eine Integration, einen Bildschirm hinzufügten, und sechs Monate später hatten sich die Kennzahlen, an denen das Team gemessen wurde, nicht bewegt. Der Aufwand war real. Das Ergebnis nicht. Also haben wir die Fragen aufgeschrieben, die rückblickend jede dieser Änderungen gestoppt hätten, bevor jemand sie gebaut hat. Diese Liste ist der Filter. Er ist bewusst direkt: Wenn eine Änderung diese Fragen nicht beantworten kann, ist der ehrliche Schritt, sie nicht vorzunehmen.
Jede Frage fängt ein Fehlermuster ab, bevor es eingeführt wird.
01
Entfällt dadurch ein Schritt?
Schritte sind Klicks, Formularfelder, Nachschlageaktionen, Übergaben, Entscheidungen, die das Team treffen muss.
02
Bewegt es eine Kennzahl, die Sie verantworten?
Bearbeitungszeit, Customer Effort, CSAT, First-Contact-Resolution, Lifetime Value. Wählen Sie die Kennzahl, an der das Team gemessen wird, nicht die, die am einfachsten zu zählen ist.
03
Verbessert es die Genauigkeit oder Qualität?
Messbar. Benennen Sie die Kennzahl vor der Einführung.
04
Minimiert es den Wartungsaufwand?
Wägen Sie den laufenden Wartungsaufwand, einzelne Ausfallpunkte und die technischen Schulden ab, die das Team danach trägt, nicht nur die eingesparte Zeit.
05
Schlägt die native Funktion eine individuelle Lösung?
Plattform-Roadmaps entwickeln sich schneller als individueller Code.
06
Können Sie die Kennzahl benennen, die es bewegen soll, und wie Sie sie messen?
Benennen Sie das Maß und den Zeitraum, bevor Sie anfangen, damit Sie hinterher sagen können, ob es funktioniert hat.
Was als Nächstes zu tun ist
Entscheiden Sie anhand einer spürbaren Verbesserung, nicht anhand eingesparter Kosten.
Eine Änderung verdient ihren Platz, wenn sie eine Kennzahl, die Sie verantworten, spürbar bewegt. Eingesparte Kosten sind ein Faktor, kein Maßstab. Wenn Sie Kennzahl, Ziel und Zeitraum nicht benennen können, bevor Sie anfangen, können Sie hinterher nicht sagen, ob die Änderung funktioniert hat. So scheitert eine Änderung still: Niemand hat das Maß festgelegt, das es gezeigt hätte. Scheitern Sie also schnell. Töten Sie die schwache Idee in der Fragephase, wo sie einen Nachmittag kostet, nicht nach dem Aufbau, wo sie ein Quartal kostet. Der Sinn des Filters ist, diesen Nachmittag zu investieren.
Jetzt anwenden
Bewerten Sie Ihre Änderung.
Beantworten Sie jede Frage für die Änderung, die Sie abwägen. Das Urteil aktualisiert sich während Sie vorgehen. Nichts, was Sie eingeben, verlässt Ihren Browser.
01
Entfällt dadurch ein Schritt?
02
Bewegt es eine Kennzahl, die Sie verantworten?
03
Verbessert es die Genauigkeit oder Qualität?
04
Minimiert es den Wartungsaufwand?
05
Schlägt die native Funktion eine individuelle Lösung?
06
Können Sie die Kennzahl benennen, die es bewegen soll, und wie Sie sie messen?
Laufendes Urteil
0 von 6 mit Ja beantwortet
Dies läuft vollständig in Ihrem Browser. Wir sehen Ihre Antworten nicht und speichern sie nicht.
So wenden Sie den Filter an
Gehen Sie die sechs Fragen der Reihe nach durch. Dann entscheiden Sie.
- Alle sechs JaEinführen.
- Vier oder fünfEinführen mit expliziten Hinweisen zu den Lücken.
- Weniger als vierNicht einführen. Der Scope stimmt nicht, oder die Änderung bringt nicht genug, um den Wartungsaufwand zu rechtfertigen.
Warum Änderungen scheitern
Eine Änderung scheitert selten daran, dass sie schlecht entwickelt wurde.
Sie scheitert, weil niemand die Kennzahl benannt hat, die sie bewegen sollte, so konnte hinterher niemand sagen, ob sie es getan hat. Oder weil der Wartungsaufwand den Nutzen still überholt hat. Oder weil die Plattform drei Monate später dasselbe nativ ausgeliefert hat und die individuelle Entwicklung zur Belastung wurde.
Die Lösung ist nicht mehr Disziplin beim Aufbau. Es geht um gute Entscheidungen vor dem Aufbau. Wählen Sie die Kennzahl, die Sie verantworten, legen Sie Ziel und Zeitraum fest und prüfen Sie zuerst, ob die native Funktion den Weg größtenteils abdeckt. Wenn eine Änderung keine spürbare Verbesserung vorweisen kann, ist der richtige Schritt in der Regel, sie nicht vorzunehmen.
Durchgearbeitetes Beispiel
Einführung von Auto-Tagging-KI in Zendesk.
Der Filter, Zeile für Zeile auf eine reale Entscheidung angewendet.
| # | Frage | Urteil | Anmerkungen |
|---|---|---|---|
| 01 | Entfällt dadurch ein Schritt? | Ja | Entfernt manuelles Tagging bei 80% der Tickets. |
| 02 | Bewegt es eine Kennzahl, die Sie verantworten? | Ja | Schnelleres Routing verkürzt die Time-to-First-Response; ca. 45 Sek. × 30.000 Tickets/Monat = 375 Stunden zurück in die Warteschlange. |
| 03 | Verbessert es die Genauigkeit? | Vielleicht | Baseline-Vergleich vor Go-Live erforderlich. |
| 04 | Minimiert es den Wartungsaufwand? | Vielleicht | Quartalsweises Modell-Retraining (gering), ohne neuen einzelnen Ausfallpunkt, muss sich aber lohnen. |
| 05 | Schlägt die native Funktion eine individuelle Lösung? | Vielleicht | Zuerst das native Auto-Tagging in Zendesk prüfen. |
| 06 | Können Sie die Kennzahl benennen, die es bewegen soll, und wie Sie sie messen? | Ja | Tagging- und Routing-Genauigkeit vorab benannt, wöchentlich gegen eine Baseline verfolgt. |
| Filter-Ergebnis | Einführen, wenn die native Funktion die Taxonomie nicht abdeckt. Andernfalls native Funktion verwenden. | ||
Wägen Sie gerade eine Änderung ab?
Wir finanzieren eine begrenzte Anzahl von Maturity Mapping Assessments für Teams mit einem konkreten Service-Problem. Beantragen Sie das Assessment mit der Kennzahl, die Sie verbessern möchten, und wenn es nicht passt, sagen wir das.