Ticket Eskalation

OTRS bietet verschiedene Möglichkeit, Tickets im System eskalieren zu lassen. Agenten wird hierbei mit Hilfe des Eskalations-Mechanismus eine Eskalationsmeldung in der Oberfläche eingeblendet. Weiterhin bietet OTRS die Möglichkeit, Agenten per Email auf eskalierte Tickets aufmerksam zu machen. Durch die Ticket-Eskalation kann gewährleistet werden, dass Tickets die ein bestimmtes Alter (oder ein vereinbartes SLA) überschreiten, die notwendige Beachtung bei den zuständigen Agenten finden.

Es gibt verschiedene Möglichkeiten die Email-Eskalationen in OTRS zu konfigurieren. Zuerst müssen wir entscheiden, wer Eskalations-Nachrichten zu welchem Zeitpunkt bekommen soll. OTRS bietet hier standardmäßig zwei verschiedene Varianten.

In der Einstellung "NotifyAgentGroupOfCustomQueue" werden alle Agenten benachrichtigt, die die Queue in der sich das eskalierte Ticket befindet, unter Ihren Einstellungen als "Eigene Queue" gewählt haben und damit die Zuständigkeit für die betroffene Queue bestätigt haben.

In der Einstellung "NotifyAgentGroupWithWritePermission" werden alle Agenten benachrichtigt, die Schreib-Berechtigung (rw) auf die betroffene Queue und somit auch auf das eskalierte Ticket besitzen.

Hier die "richtige" Einstellung zu finden, ist eine reine Philosophiefrage. Sollen sich alle berechtigten Agenten um eskalierte Tickets kümmern, oder ausschließlich die, die sich für die betroffene Queue zuständig erklärt haben? Diese Entscheidung muss bei der initialen Konfiguration des Systems, in Abhängigkeit der firmeninternen Prozesse, getroffen werden.

Die Eskalationszeiten (Reaktionszeit, Updatezeit und Lösungszeit) können in den Queue-Einstellungen und in den SLA-Einstellungen festgelegt werden. Falls in Ihrem Unternehmen SLA´s mit festgelegten Eskalationszeiten (z. B. in Form eines Service-Katalogs) existieren, macht es Sinn diese in OTRS zu konfigurieren und mit den entsprechenden Eskalationszeiten zu versehen. Falls keine Services und SLA´s verwendet werden sollen, muss die Eskalationszeit in den Queue-Einstellungen hinterlegt werden. Falls nur eine Teilmenge der Tickets ein SLA zugewiesen bekommt, kann es auch Sinn machen, die Eskalationszeiten in den den Queue-Einstellungen und in den SLA-Einstellungen zu hinterlegen. Die Eskalationszeiten in der Konfiguration des SLA überschreiben hierbei immer die Einstellungen der Queue, falls an beiden Stellen Eskalationszeiten gesetzt wurden.

Beispiel 8.4. GenericAgent Job zum Versand von Eskalations Benachrichtigungen

Mit Hilfe des GenericAgents können Eskalations-Benachrichtigungen per E-Mail an die Agenten versendet werden. In der Datei Kernel/Config/GenericAgent.pm(.dist) ist eine Beispielkonfiguration aufgeführt, mit der Benachrichtigungen über eskalierte Tickets an Agenten versendet werden. Öffnen Sie diese Datei und entfernen Sie die Kommentarzeichen vor den entsprechenden Zeilen:

%Jobs = (
   # --
   # [name of job] -> send escalation notifications
   # --
   'send escalation notifications' => {
       Escalation => 1,
       # new ticket properties
       New => {
           Module => 'Kernel::System::GenericAgent::NotifyAgentGroupOfCustomQueue',
       },
   },
   # insert your jobs (see Kernel/Config/GenericAgent.pm.examples)
);

Bitte beachten Sie, dass Sie je nach benötigter Konfiguration das zugrunde liegende Eskalationsmodul (siehe oben) anpassen müssen. Mithilfe der nachfolgenden Konfiguration werden die Eskalationsnachrichten an alle Agenten versendet, die Schreib-Berechtigung (rw) auf die betroffene Queue und somit auch auf das eskalierte Ticket, besitzen:

%Jobs = (
   # --
   # [name of job] -> send escalation notifications
   # --
   'send escalation notifications' => {
       Escalation => 1,
       # new ticket properties
       New => {
           Module => 'Kernel::System::GenericAgent:: NotifyAgentGroupWithWritePermission',
       },
   },
   # insert your jobs (see Kernel/Config/GenericAgent.pm.examples)
);


Wird ein Ticket erstellt oder in eine andere Queue verschoben, werden dem Agenten zunächst die verbleibenden Eskalationszeiten (Reaktions-, Update-, Lösungszeit) dargestellt. Befindet sich das Ticket in einem für die Berechnung relevanten Zeitfenster, werden die Eskalationszeiten von diesem Zeitpunkt an herunter gezählt. Befindet sich das Ticket nicht in den in TimeWorkingHours festgelegten "Arbeitsstunden", oder es ist aktuell ein in TimeVacationDays bzw. TimeVacationDaysOneTime definierter Feiertag, finden keine Berechnungen der Eskalationszeiten statt und die Eskalationszeiten werden angehalten. Wird der Wert 0 bei einer der Eskalationszeiten erreicht, eskaliert das Ticket. Im weiteren Verlauf wird der Wert negativ, das Ticket hat die Eskalationszeit überschritten. Beim nächsten Lauf des GenericAgent-Jobs, werden die Eskalations-Nachrichten versendet und dem Agenten wird eine Eskalationsmeldung in der Oberfläche eingeblendet.

Die Reaktionszeit wird auf den konfigurierten Ursprungswert zurückgesetzt, wenn der erste "externe Artikel" (E-Mail, Telefonanruf) am Ticket dokumentiert wird.

Die Updatezeit wird auf den konfigurierten Ursprungswert zurückgesetzt, wenn ein "externe Artikel" (E-Mail, Telefonanruf) in Form eines "FollowUps" durch einen Kunden oder einen Agenten am Ticket dokumentiert wird.

Die Lösungszeit wird zurückgesetzt, sobald der Ticketstatus in einen Status des Typs "Geschlossen" wechselt.

In der nachfolgenden Tabelle werden die Eskalationszyklen/Eskalationseigenschaften der bisherigen OTRS Versionen verglichen.

Tabelle 8.2. Eskalations Eigenschaften - Reaktionszeit

Eskalations Eigenschaften - Reaktionszeit2.0.x2.1.x2.2.x2.3.x2.4.x

Ein Ticket eskaliert, wenn der Kunde nach Ablauf der hinterlegten Reaktionszeit keine Antwort in Form eines "externen Artikels" (Email, Telefonanruf) bekommen hat.

Nachdem ein "externer Artikel" einem Ticket hinzugefügt wurde, wird die Reaktionszeit zurückgesetzt und deaktiviert.

Die Reaktionszeit beginnt bei der Ticketerstellung und endet mit dem Anlegen eines "externen Artikels" in Form eines E-Mail oder eines Anrufs.

Ob das Ticket von einem Agenten gesperrt ist findet keine Berücksichtigung.

---xx

Tabelle 8.3. Eskalations Eigenschaften - Aktualisierungszeit

Eskalations Eigenschaften - Aktualisierungszeit2.0.x2.1.x2.2.x2.3.x2.4.x
Ein Ticket eskaliert...

a) Wenn eine Aktualisierungszeit für die entsprechende Queue gesetzt, oder wenn dem Ticket ein SLA mit Aktualisierungszeit zugewiesen wurde.

b) Wenn die in den Einstellungen hinterlegte Aktualisierungszeit abgelaufen ist.

c) Wenn sich das Ticket in einem "offen" Status befindet. Wenn ein "pending" Status gesetzt ist, wird die Eskalationszeit ausgesetzt.

xxxxx
Die Eskalationszeit wird zurückgesetzt, wenn ein Kunde einen Artikel am Ticket erstellt (z. B. durch Email-FollowUp). Das Ticket muss dabei nicht wiedereröffnet werden. Ist bereits der letzte Artikel von einem Kunden, wird die Eskalationszeit (Startpunkt) nicht zurück gesetzt, da sich hier die Eskalation verzögern würde. -xxxx
Die Eskalationszeit wird zurückgesetzt, wenn ein Agent einen externen Artikel (z. B. eine Email an einen Kunden oder eine Telefon-Notiz) anlegt. -xxxx

Tabelle 8.4. Eskalations Eigenschaften - Lösungszeit

Eskalations Eigenschaften - Lösungszeit2.0.x2.1.x2.2.x2.3.x2.4.x

Die Lösungszeit eines Tickets wird überschritten, wenn das Ticket nicht innerhalb der konfigurierten Lösungszeit in einen Status des Typs "geschlossen" wechselt.

Durch das Schließen eines Tickets wird die Lösungszeit deaktiviert und zurückgesetzt.

Die Eskalationszeit beginnt mit der Ticket-Erstellung und endet (Endpunkt) mit dem Schließen eines Tickets.

Ob das Ticket von einem Agenten gesperrt oder frei ist findet keine Berücksichtigung.

---xx