Wenn Sie jemals Zendesk Explore angestarrt und sich gefragt haben, warum es zwei verschiedene Metriken gibt, die beide so klingen, als würden sie gelöste Tickets zählen, sind Sie nicht allein. Die Unterscheidung zwischen „gelösten Tickets“ und „Tickets gelöst“ bringt selbst erfahrene Administratoren durcheinander. Wenn Sie es falsch machen, erzählen Ihre Berichte eine völlig andere Geschichte als das, was tatsächlich in Ihrer Support-Warteschlange passiert.
Lassen Sie es uns aufschlüsseln. Dieser Leitfaden erklärt den entscheidenden Unterschied zwischen diesen beiden Metriken, wann Sie welche verwenden sollten und wie Sie genaue Berichte erstellen, die tatsächlich die Leistung Ihres Teams widerspiegeln.

| Anwendungsfall | Verwenden Sie diese Metrik | Datensatz |
|---|---|---|
| Aktuelle Arbeitslast nach Agent | Gelöste Tickets | Tickets |
| Tickets heute/diese Woche gelöst | Tickets gelöst | Tickets |
| Trends im Zeitverlauf (erstellt vs. gelöst) | Tickets gelöst | Aktualisierungsverlauf (Updates history) |
| SLA-Konformitätsverfolgung | Tickets gelöst | Aktualisierungsverlauf (Updates history) |
| Leistungsbeurteilungen der Agenten | Hängt vom Ziel ab | Entweder |
Unterm Strich? Wenn Sie Trends verfolgen oder die Leistung im Zeitverlauf messen, möchten Sie fast immer Tickets gelöst aus dem Datensatz Aktualisierungsverlauf (Updates history). Wenn Sie eine aktuelle Momentaufnahme der gelösten Arbeitslast benötigen, verwenden Sie Gelöste Tickets aus dem Datensatz Tickets.
Für Teams, die über die manuelle Berichtserstellung hinausgehen möchten, bieten wir eine autonome Auflösungsverfolgung an, die diese Einblicke bietet, ohne dass Sie durch Datensätze und Formeln navigieren müssen.
Auswahl des richtigen Datensatzes für Ihren Bericht
Zendesk Explore organisiert Daten in Datensätze, und die Auswahl des falschen Datensatzes ist der schnellste Weg, um verwirrende Ergebnisse zu erhalten. So entscheiden Sie.
Datensatz Tickets: Für aktuellen Zustand und Momentaufnahmen
Verwenden Sie dies, wenn Sie den Status von Tickets im Moment wissen möchten. Es enthält allgemeine Ticketinformationen ohne historische Änderungen.
- Am besten geeignet für: Aktuelle Arbeitslast, Anzahl offener Tickets, Backlog-Analyse
- Zeitattribute: Ticket erstellt, Ticket gelöst (zuletzt), Ticket aktualisiert
- Schlüsselmetriken: Gelöste Tickets, Ungelöste Tickets, Tickets gelöst - Letzte 7 Tage
Datensatz Aktualisierungsverlauf (Updates history): Zum Verfolgen von Änderungen im Zeitverlauf
Dieser Datensatz erfasst jede an Tickets vorgenommene Änderung. Er ist ereignisbasiert, was bedeutet, dass er verfolgt, was wann passiert ist.
- Am besten geeignet für: Trendanalyse, Berichte über erstellt vs. gelöst, Verfolgung der Agentenaktivität
- Zeitattribute: Aktualisierungszeitstempel (wann Änderungen aufgetreten sind)
- Schlüsselmetriken: Tickets erstellt, Tickets gelöst, Agenten-Updates, Kommentare
Datensatz Backlog-Verlauf: Für historische Momentaufnahmen
Dies zeigt, wie viele ungelöste Tickets an einem bestimmten Datum vorhanden waren. Explore erfasst diese Daten jedes Mal, wenn Ihre Daten synchronisiert werden.
- Am besten geeignet für: Verständnis des Backlog-Wachstums oder -Rückgangs im Zeitverlauf
- Einschränkung: Erfasst nur Daten von Synchronisationspunkten, nicht in Echtzeit
Schneller Entscheidungsrahmen
Fragen Sie sich: Welche Frage versuche ich zu beantworten?
- "Wie viele Tickets sind gerade gelöst?" → Datensatz Tickets
- "Wie viele Tickets haben wir diese Woche gelöst?" → Datensatz Aktualisierungsverlauf (Updates history)
- "Wie ist unser Backlog-Trend?" → Datensatz Backlog-Verlauf
- "Halten wir mit dem Ticketvolumen Schritt?" → Datensatz Aktualisierungsverlauf (Updates history) (erstellt vs. gelöst)
So erstellen Sie einen Bericht über erstellte vs. gelöste Tickets
Dies ist einer der häufigsten Berichte, die Support-Teams benötigen. Er zeigt, ob Sie auf der Stelle treten, zurückfallen oder vorankommen. So erstellen Sie ihn.
Schritt 1: Erstellen Sie einen neuen Bericht im Datensatz Aktualisierungsverlauf (Updates history)
Navigieren Sie zu Explore, klicken Sie auf das Berichtssymbol und dann auf Neuer Bericht. Wählen Sie auf der Seite "Datensatz auswählen" Support > Support - Aktualisierungsverlauf (Updates history) und klicken Sie dann auf Bericht starten.

Schritt 2: Fügen Sie die Metriken hinzu
Klicken Sie im Metriken-Panel auf Hinzufügen. Wählen Sie aus der Liste:
- Tickets > Tickets erstellt
- Tickets > Tickets gelöst
Klicken Sie dann auf Anwenden.

Warum diese Metriken zusammen? Tickets erstellt zeigt das eingehende Volumen. Tickets gelöst zeigt das ausgehende Volumen. Wenn gelöst ständig erstellt übersteigt, reduzieren Sie den Backlog. Wenn erstellt gelöst übersteigt, wächst Ihre Warteschlange.
Schritt 3: Konfigurieren Sie die Datumsfilterung
Klicken Sie im Filter-Panel auf Hinzufügen. Wählen Sie Zeit - Ticket-Update > Update - Jahr und klicken Sie dann auf Anwenden.
Klicken Sie auf den Filter Update - Jahr, den Sie gerade hinzugefügt haben, und klicken Sie dann auf Datumsbereiche bearbeiten. Sie können einen einfachen Bereich wie "Dieses Jahr" auswählen oder auf die Registerkarte Erweitert klicken, um weitere Optionen wie "12 Wochen in der Vergangenheit bis 1 Woche in der Vergangenheit" zu erhalten.

Profi-Tipp: Verwenden Sie für eine genaue Wochentagsanalyse immer vollständige Datenwochen. Teilweise Wochen können Ihre Ergebnisse verfälschen.
Schritt 4: Fügen Sie Spalten und Visualisierung hinzu
Klicken Sie im Spalten-Panel auf Hinzufügen. Wählen Sie Zeit - Ticket-Update > Update - Datum, um tägliche Ergebnisse anzuzeigen. Klicken Sie auf Anwenden.
Wählen Sie im Menü Visualisierungen den Diagrammtyp Spalte. Aus dem Menü zur Diagrammkonfiguration:
- Klicken Sie auf Diagramm und aktivieren Sie Gestapelt
- Deaktivieren Sie Aggregierte Werte
- Klicken Sie auf Angezeigte Werte und wählen Sie aus, Werte innerhalb der Spalten anzuzeigen

Klicken Sie auf Speichern, um Ihren Bericht zu speichern. Sie können ihn jetzt einem Dashboard hinzufügen oder später aus der Bibliothek wieder öffnen.
Erstellen benutzerdefinierter Metriken für die erweiterte Verfolgung
Manchmal geben Ihnen die integrierten Metriken nicht genau das, was Sie benötigen. Hier sind zwei häufige Szenarien, in denen berechnete Metriken helfen.
Metrik für das erste gelöste Datum
Verwenden Sie dies, wenn Sie verfolgen möchten, wann Tickets zuerst gelöst wurden, auch wenn sie später wiedereröffnet wurden. Dies ist nützlich, um die First-Touch-Resolution-Raten zu messen.
So erstellen Sie es:
- Klicken Sie in Ihrem Bericht auf das Berechnungsmenü (Rechnersymbol)
- Wählen Sie Standard berechnete Metrik
- Nennen Sie es "Datum des ersten gelösten Updates"
- Fügen Sie diese Formel ein:
IF ([Changes - Field name] = "status" AND [Changes - New value] = "solved"
AND [Changes - Previous value] != "solved" AND [Update - Timestamp] =
DATE_FIRST_FIX([Update - Timestamp], [Ticket ID], [Changes - Field name]))
THEN [Update ticket ID]
ENDIF
- Klicken Sie auf Speichern
Quelle: Zendesk Help Center - Erstellen einer Metrik für das erste gelöste Datum eines Tickets
Prozentsatz innerhalb der SLA gelöst
Möchten Sie verfolgen, welcher Prozentsatz der Tickets Ihre SLA-Ziele erreicht? Sie benötigen zwei berechnete Metriken.
Erstellen Sie zunächst eine Metrik für Tickets, die innerhalb Ihres Schwellenwerts gelöst wurden (Beispiel: 20 Minuten):
IF (VALUE(Full resolution time (min)) < 20 AND [Ticket status - Unsorted] = "Solved")
THEN [Ticket ID]
ENDIF
Erstellen Sie dann eine Prozentmetrik:
COUNT(Tickets solved in less than 20 minutes) / COUNT(Solved tickets)
Formatieren Sie dies als Prozentsatz und wenden Sie es auf Ihre Berichte an. Sie können den Schwellenwert (20 Minuten) an Ihre SLA anpassen.
Quelle: Geckoboard - % Tickets Solved in Less than 20 Minutes
Häufige Fehler und wie Sie sie vermeiden können
Selbst erfahrenen Administratoren unterlaufen diese Fehler. Hier ist, worauf Sie achten sollten.
Fehler 1: Verwenden des Datensatzes Tickets für die Trendanalyse
Der Datensatz Tickets zeigt den aktuellen Status, nicht historische Ereignisse. Wenn Sie versuchen, einen Bericht "erstellt vs. gelöst nach Datum" mit dem Datensatz Tickets zu erstellen, stimmen Ihre Zahlen nicht mit der Realität überein. Verwenden Sie für Trendberichte immer den Datensatz Aktualisierungsverlauf (Updates history).
Fehler 2: Ignorieren von Geschäftszeiten vs. Kalenderstunden
Zendesk verfolgt beides. Wenn Ihre SLA auf Geschäftszeiten basiert, Sie aber Kalenderstunden in Ihrem Bericht betrachten, erhalten Sie irreführende Ergebnisse. Überprüfen Sie, welche Zeitmetrik Sie verwenden:
- Kalenderstunden: "Full resolution time (min)" (Vollständige Auflösungszeit (Min.))
- Geschäftszeiten: "Full resolution time - Business hours (min)" (Vollständige Auflösungszeit - Geschäftszeiten (Min.))
Fehler 3: Nichtberücksichtigung der Fehlermarge
Zendesk räumt ein, dass einige Berechnungen im Datensatz Aktualisierungsverlauf (Updates history) aufgrund der Art und Weise, wie Metriken berechnet werden, eine kleine Fehlermarge aufweisen. Für die meisten operativen Berichte spielt dies keine Rolle. Wenn Sie jedoch präzise Finanzberechnungen oder Executive-Dashboards durchführen, validieren Sie Ihre Zahlen anhand von Ticketdaten.
Quelle: Zendesk - Reporting on created and solved tickets
Fehler 4: Doppeltes Zählen von Übergängen von gelöst zu geschlossen
Die Metrik "Tickets gelöst" im Datensatz Aktualisierungsverlauf (Updates history) schließt bereits Übergänge von gelöst zu geschlossen aus. Wenn Sie jedoch benutzerdefinierte Formeln erstellen, stellen Sie sicher, dass Sie diese Übergänge nicht als separate Auflösungen zählen.
Validierungstipps
- Überprüfen Sie Stichproben-Tickets anhand Ihrer Berichtszahlen
- Vergleichen Sie "Tickets gelöst" im Aktualisierungsverlauf (Updates history) mit "Gelöste Tickets" im Datensatz Tickets für denselben Zeitraum. Sie sollten nahe beieinander liegen (wenn auch nicht identisch aufgrund wiedereröffneter Tickets).
- Testen Sie berechnete Metriken zuerst mit einem kleinen Datumsbereich
Über die grundlegende Berichterstattung hinaus mit unserem KI-Agenten
Zendesk Explore ist leistungsstark, erfordert jedoch manuelle Berichtserstellung, Datensatzkenntnisse und Formelschreiben. Für Teams, die Auflösungseinblicke ohne die Komplexität wünschen, gibt es eine weitere Option.

Unser KI-Agent lässt sich direkt in Zendesk integrieren und bietet eine autonome Auflösungsverfolgung. Anstatt Berichte zu erstellen, erhalten Sie:
- Echtzeit-Auflösungseinblicke ohne benutzerdefinierte Formeln
- Abfragen in natürlicher Sprache - fragen Sie "Wie viele Tickets haben wir diese Woche gelöst?" anstatt durch Datensätze zu navigieren
- Automatisierte Verfolgung von Auflösungsraten, SLA-Konformität und Agentenleistung
- Keine manuelle Berichtswartung - Einblicke werden automatisch aktualisiert, wenn Tickets durch Ihr System fließen
Für Teams, die bereits Zendesk verwenden, arbeiten wir mit Ihrem bestehenden Setup zusammen. Unsere KI lernt aus Ihren vergangenen Tickets, dem Help Center und Makros, um Einblicke zu liefern, die Ihrem spezifischen Geschäftskontext entsprechen.

Wenn Sie mehr Zeit mit dem Erstellen von Berichten als mit dem Handeln nach Erkenntnissen verbringen, ist es möglicherweise an der Zeit, einen Ansatz in Betracht zu ziehen, der die Analysen automatisch verarbeitet.
Häufig gestellte Fragen
Diesen Beitrag teilen

Article by
Stevia Putri
Stevia Putri is a marketing generalist at eesel AI, where she helps turn powerful AI tools into stories that resonate. She’s driven by curiosity, clarity, and the human side of technology.



