Explore: die Kennzahlen, die im Support zählen

Explore kann fast alles messen. Das ist die Falle. Wer das erste Mal ein prebuilt dashboard öffnet, ertrinkt in Zahlen: Tabs, Kacheln, Kurven. Die eigentliche Arbeit ist nicht, mehr zu messen, sondern weniger. Ein paar Kennzahlen sagen dir, ob dein Support gesund ist. Der Rest sieht in Präsentationen gut aus und ändert nie eine Entscheidung. Diese Karte trennt das eine vom anderen.

Was Explore ist

Explore ist Zendesks Reporting-Werkzeug, und es steht auf drei Begriffen. Ein dataset ist eine Sammlung von metrics und attributes, die Daten aus einem Zendesk-Produkt abfragt: Support-Tickets, AI, Knowledge, je eigenes dataset. Ein prebuilt dashboard ist die fertige Auswertung dazu: read-only, aber auf den meisten kostenpflichtigen Plänen lässt sich eine editierbare Kopie ziehen. Und ein custom report ist, was du selbst baust. Jeder report braucht mindestens eine metric, und er lebt vom richtigen dataset: Greifst du zum falschen, fehlt dir schlicht die Kennzahl, die du suchst.

Für den Anfang reicht das Zendesk-Support-dashboard. Es hat neun Tabs: Tickets, Efficiency, Assignee Activity, Agent Updates, Unsolved Tickets, Backlog, Satisfaction, SLAs und Group SLAs. Für den Einstieg genügen davon Tickets, Backlog, Satisfaction und SLAs. Damit deckst du den Grossteil ab, bevor du je einen eigenen report baust.

Den ersten eigenen Report musst du nicht mehr von Hand bauen. Mit Quick Reports beschreibst du in einem Satz, was du sehen willst, und Explore erzeugt den Report daraus. Das nimmt dir die Mechanik ab. Die Auswahl bleibt deine Aufgabe: Welche wenigen Zahlen eine Entscheidung ändern, beantwortet der Prompt nicht. Es greift dabei nur auf das Support-Tickets-dataset zu.

Die Kennzahlen, die zählen

Sechs Zahlen, und warum:

• First reply time: Zeit zwischen Ticket-Erstellung und der ersten öffentlichen Agent-Antwort. Das ist die Zahl, die deine Kundschaft am direktesten spürt. Wichtig: Explore rechnet wahlweise in Kalender- oder in Geschäftszeiten. Wer ohne Geschäftszeiten misst, straft sich für jede Nacht und jedes Wochenende.
• Full resolution time: von der Erstellung bis zur letzten Lösung, Reopens eingerechnet (nicht zu verwechseln mit first resolution time, die nur bis zum ersten Solved zählt). Das strengere Mass, weil es zu früh geschlossene Tickets nicht belohnt.
• SLA-Achievement-Rate: der Anteil der Tickets, die ihre SLA-Ziele einhalten. Wo ihr Reaktions- oder Lösungszeiten zugesagt habt, zeigt diese Zahl, ob ihr die Zusage haltet. Sie prüft die reinen Zeit-Metriken an dem Ziel, das ihr selbst gesetzt habt.
• CSAT: der Anteil guter Bewertungen an den abgegebenen. Explore rechnet gute geteilt durch abgegebene Bewertungen, mal 100. Auf der 1–5-Skala zählen 4–5 als gut, 1–3 als schlecht; die Skala lässt sich auch auf zwei oder drei Stufen umstellen. Der Nenner sind nur die abgegebenen Bewertungen, nicht alle Tickets, und deshalb ist die nackte Prozentzahl wertlos ohne die Antwortquote: 95 % CSAT bei 3 % Rücklauf misst deine lautesten Fans, nicht deinen Support.
• Backlog: die unbearbeiteten Tickets über die Zeit. Als Snapshot-dataset zeigt er den Trend: Läuft die Warteschlange voll, ist das ein Frühwarnsystem, das keine Reaktionszeit-Kurve so früh zeigt. Weil es ein Snapshot-dataset ist, lässt es sich nicht mit ereignisbasierten datasets in einem report mischen.
• One-touch rate & reopen rate: Anteil der Tickets, die mit einer (oder keiner) Agent-Antwort gelöst sind, gegen den Anteil, der nach Solved wieder aufgeht. Zusammen gelesen sind sie ein Qualitätssignal: Viele one-touch und wenige reopens heisst sauber gelöst; viele one-touch und viele reopens heisst vorschnell geschlossen.

Wo AI Agents im Spiel sind, kommt eine siebte dazu: die Automated Resolution. Sie zählt nur, was ein LLM als ohne menschliches Eingreifen erledigt verifiziert hat, und ist zugleich die Abrechnungseinheit. Was da als «gelöst» gilt, steht in der Notiz Was «autonom gelöst» wirklich heisst.

Die Disziplin steckt in der Auswahl: Zwei, drei dieser Zahlen schaust du wöchentlich an, den Rest lässt du bewusst liegen.

Und die, die täuschen

Ticket-Volumen als Erfolg. Mehr gelöste Tickets ist keine gute Nachricht, wenn das Volumen selbst steigt: oft heisst es nur, dass ein Produktproblem Support produziert. Volumen ist ein Diagnose-, kein Leistungsmass.

Durchschnitte bei Zeit-Metriken. Ein einziges Ticket, das drei Wochen liegen bleibt, hebt deine durchschnittliche resolution time so, dass sie nichts mehr über den Normalfall sagt. Zendesk empfiehlt für Zeit-Metriken deshalb den Median als aggregator: Wo ein Ausreisser den Durchschnitt auf 20 Stunden zieht, bleibt der Median bei 4. Er zeigt das typische Ticket, nicht den Ausreisser.

Vanity-CSAT ohne Rücklaufquote. Siehe oben: eine Zufriedenheitszahl ohne die Zahl dahinter, wie viele überhaupt geantwortet haben, ist Dekoration.

Alles auf einmal. Ein dashboard mit dreissig Kacheln wird nicht gelesen, es wird überflogen. Vier bis sechs Zahlen, die zu einer Handlung führen, schlagen jede Vollständigkeit.

Der beste Report ist der, aus dem du regelmässig etwas streichst. Sobald eine Kennzahl über Monate keine Entscheidung mehr ändert, gehört sie raus.