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 oben in der Liste „In progress“ unter Einstellungen > Inbox > Tickets platzieren.
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.

Submitted-Status-Tickets

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 verschieben. Sie können auch ein Ticket von anderen Status (z. B. In progress) zurück in einen Submitted-Status verschieben.

FAQs

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

Es gibt keine Änderungen an historischen Daten. Reporting-Metriken, die die in Submitted-Status verbrachte Zeit 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 Verschieben eines Tickets vom Resolved-Status zurück zu Submitted bedeutet, dass der SLA-Timer nicht zurückgesetzt wird.
Das Verschieben 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 oben in der Liste In Progress für diesen Tickettyp unter Einstellungen > Inbox > Tickets platzieren.

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 gesamten 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 der Verwendung von Command-K zum Wechseln eines Tickets von einem Status in einen anderen angezeigt.

Die verfügbaren Ticket-Status hängen von den für diesen Tickettyp konfigurierten Status ab.

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, unter Ticket-Status, um ihn zu aktivieren:

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 der Ticket-Status, wenn ein Ticket mit ihnen über den Messenger, E-Mails oder das Customer portal geteilt wurde.

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

Vor dem Update gesendete E-Mails 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“ verschoben 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 den Ticket time in state dataset verwenden, um die in jedem Ticket-Status verbrachte Zeit zu berichten. Dies beinhaltet eine Metrik „Ticket time spent in all states“ und zusätzliche Reporting-Attribute, um Ihren benutzerdefinierten Bericht zu filtern und zu segmentieren.