Ticket-Status helfen, klare Erwartungen zu setzen, damit sowohl Ihre Kunden als auch Teammitglieder über den Fortschritt eines Tickets informiert sind. Diese sind in vier Kategorien organisiert: Submitted, In Progress, Waiting on Customer und Resolved, jede mit eigenem Verhalten.

Ticket-Status-Kategorien

Die folgende Tabelle beschreibt jede Kategorie und das Verhalten, das ein Status in dieser Kategorie annimmt.

Ticket-Status-Kategorie	Beschreibung	Verhalten
Submitted	Der Status „Submitted“ markiert die Anfangsphase eines Tickets.	Diese Status werden einem Ticket bei der Erstellung zugewiesen und sind für Kunden sichtbar, wenn Tickets geteilt werden.
In progress	Der Status „In Progress“ zeigt an, dass an einem Ticket gearbeitet wird.	Diese Status sind für Ihre Kunden sichtbar, wenn ein Ticket geteilt wird.
Waiting on customer	Der Status „Waiting on customer“ zeigt an, dass für die Bearbeitung eines Tickets weitere Informationen vom Kunden benötigt werden.	Status in dieser Kategorie können SLAs pausieren, wenn konfiguriert. Wenn ein Kunde auf ein Ticket in diesem Status antwortet, wechselt das Ticket automatisch zurück in einen „In progress“-Status. Wenn benutzerdefinierte In-Progress-Status konfiguriert sind, wechselt das Ticket in den ersten Status der Gruppe „In progress“ für diesen Tickettyp. Sie können steuern, welcher benutzerdefinierte Status standardmäßig ist, indem Sie ihn in Einstellungen > Inbox > Tickets an die Spitze der Liste „In progress“ setzen.
Resolved	Der Status „Resolved“ zeigt den Abschluss der Arbeit an einem Ticket an.	Diese Status sind für Ihre Kunden sichtbar, wenn ein Ticket geteilt wird, und werden verwendet, um die Metrik „Time to resolve“ zu messen. Wenn ein Kunde auf ein Ticket in diesem Status antwortet, wird es nicht automatisch wieder geöffnet. Um ein gelöstes Ticket bei einer Kundenantwort wieder zu öffnen, richten Sie einen workflow mit der Aktion Set ticket state ein.

Wichtig: Das Setzen eines Tickets auf resolved schließt die Konversation nicht automatisch. Weitere Informationen finden Sie hier.

Wichtig: Das Hinzufügen eines Teilnehmers durch einen Endbenutzer ändert den Ticket-Status von Waiting on Customer und startet den SLA-Timer, auch ohne Antwort. Dies ist das erwartete Verhalten.

Tickets im Submitted-Status

Sie können in Ihrem Workspace mehrere Submitted-Status pro Tickettyp haben. Navigieren Sie zu Einstellungen > Inbox > Tickets und fügen Sie so viele Submitted-Status hinzu, wie Sie möchten.

Sobald Sie zusätzliche Status zu Ihren Submitted-Tickettypen hinzugefügt haben, können Sie ein Ticket zwischen verschiedenen Submitted-Status wechseln. Sie können auch ein Ticket von anderen Status (z. B. In progress) zurück in einen Submitted-Status ändern.

FAQs

Was passiert mit den Reporting-Metriken, die die Zeit in Submitted-Status berechnen?

Es gibt keine Änderungen an historischen Daten. Reporting-Metriken, die die Zeit in Submitted-Status berechnen, berücksichtigen die Zeit in allen Submitted-Status. Der erste Submitted-Zeitstempel wird verwendet, um die Zeit bis zur Lösung zu messen.

Ändert sich die Ticketansicht im Messenger, wenn ein Ticket zurück zu Submitted verschoben wird?

Nein, die Ticketansicht wechselt zurück und zeigt den Submitted-Status wie erwartet an.

Kann ein Ticket über workflows zurück zu Submitted verschoben werden?

Ja, Sie können Submitted-Status über die Aktion Set ticket state in workflows auswählen. Wenn ein Ticket jedoch bereits im durch die Aktion ausgewählten Status ist, wird die Statusänderung nicht verarbeitet. Dies gilt für alle Ticket-Statusänderungen, nicht nur für Submitted-Ereignisse.

Was passiert mit SLAs, wenn ein Ticket zurück in einen Submitted-Status verschoben wird?

Der SLA-Timer wird einmalig beim Auslösen des workflows gestartet. Der Timer wird nicht zurückgesetzt, wenn ein Ticket zurück in einen Submitted-Status verschoben wird. Nachfolgende Statusaktualisierungen zu Submitted-Status werden wie andere Statusänderungen behandelt.

Das Ändern eines Tickets vom Resolved-Status zurück zu Submitted bedeutet, dass der SLA-Timer nicht zurückgesetzt wird.
Das Ändern eines Tickets von Waiting on customer zurück zu Submitted setzt die SLA-Pause zurück.

Benutzerdefinierte Ticket-Status

Sie können Ticket-Status erstellen oder anpassen unter jeder dieser Kategorien, und sie übernehmen das Verhalten ihrer jeweiligen Kategorie.

Hinweis: Wenn ein Kunde auf ein Ticket in einem Waiting on customer-Status antwortet, wechselt das Ticket automatisch in den Standard-In progress-Status für diesen Tickettyp — kein workflow erforderlich. Der Standard ist der erste Status in der Gruppe In progress für diesen Tickettyp. Wenn ein Kunde auf ein Resolved-Ticket antwortet, wird es nicht automatisch wieder geöffnet. Um dies zu handhaben, richten Sie einen workflow mit der Aktion Set ticket state ein.

Am Beispiel des Screenshots wäre der Standard in diesem Fall „With Us“. Das bedeutet, Sie können steuern, welcher benutzerdefinierte Status für einen bestimmten Tickettyp Standard wird, indem Sie den benutzerdefinierten Status an die Spitze der Liste „In Progress“ für diesen Tickettyp in Einstellungen > Inbox > Tickets setzen.

Wenn Sie benutzerdefinierte Status verwenden, wechselt das Ticket bei einer Kundenantwort in den ersten/obersten „In progress“-Status in Ihrer Ticket-Status-Liste.

Hinweis:

Jeder Tickettyp muss mindestens einen Status aus jeder dieser Kategorien enthalten.
Ticket-Status können für mehrere Tickettypen verwendet werden.
Ticket-Status im Workspace dürfen nicht dasselbe interne Label haben. Sie können jedoch dasselbe kundenorientierte Label teilen.

📖 Erfahren Sie, wie Sie Ihre eigenen benutzerdefinierten Ticket-Status erstellen und über Ticket-Status berichten.

Erfahrung der Teammitglieder im Inbox

Teammitglieder sehen die Ticket-Status (einschließlich benutzerdefinierte Ticket-Status), während sie an Tickets aus dem Inbox arbeiten. Diese werden in der Hauptansicht des Tickets, innerhalb der Links-App und bei Verwendung von Command-K angezeigt, um ein Ticket von einem Status in einen anderen zu wechseln.

Die verfügbaren Ticket-Status hängen von den Status ab, die Sie für diesen Tickettyp konfiguriert haben.

Um den Ticket-Status in Ihrem Inbox-Dropdown zu sehen 👇, müssen Sie den Ticket-Status-Inbox-Filter aktivieren.

Gehen Sie zu Einstellungen > Inbox > Tickets und aktivieren Sie unter Ticket states den Filter:

Erfahrung der Teammitglieder in Slack & Jira für Tickets

Das interne Label der Ticket-Status wird in Slack-Benachrichtigungen angezeigt.

Und Jira for Tickets.

Kundenerfahrung

Ihre Kunden sehen das kundenorientierte Label für Ticket-Status, wenn ein Ticket mit ihnen geteilt wird, über Messenger, E-Mails oder Customer portal.

Wenn Sie einen Ticket-Status bearbeiten oder anpassen, sehen Kunden die aktualisierten Ticket-Status-Labels im Messenger sowie in neuen E-Mail-Benachrichtigungen.

E-Mails, die vor der Aktualisierung gesendet wurden, behalten die ursprünglichen Ticket-Status-Labels.

API

Sie können die internen und externen Labels eines benutzerdefinierten Ticket-Status sehen, wenn Sie ein einzelnes Ticket über die tickets API abrufen.

Sie können derzeit nur den Systemstatus eines Tickets über die API ändern. Wenn Sie dies tun, wird der benutzerdefinierte Status dieses Tickets auf den ersten benutzerdefinierten Status auf der Ticket-Typen-Seite gesetzt, der diesem Systemstatus entspricht. Zum Beispiel wird ein Ticket, das auf „In progress“ gesetzt wird, auf den ersten benutzerdefinierten Status im Abschnitt „In progress“ auf der Ticket-Typen-Seite gesetzt.

Ticket-Status können nicht über die API verwaltet werden (z. B. erstellt oder archiviert).

Über Ticket-Status berichten

Sie können das Ticket time in state dataset verwenden, um die Zeit in jedem Ticket-Status zu berichten. Dies umfasst eine Metrik „Ticket time spent in all states“ und zusätzliche Reporting-Attribute, um Ihren benutzerdefinierten Bericht zu filtern und zu segmentieren.