Je nach Konfiguration des Systems kann zwischen einer Eskalation nach Lösungszeit (bis eine Lösung für den Incident erfasst ist) und einer Eskalation nach Reaktionszeit (bis eine erste qualifizierte Rückmeldung an den Kunden erfolgt) gewählt werden. Für letzteres muss in der Scheduler Config Datei das Flag considerResponseTimes auf “true” gesetzt werden.
Eine Übersicht der Farbcodes in der Incident-Detailansicht finden sie unter Incident Pool.

Eskaliert werden nur Incidents, in deren Supportkategorie die Eskalation aktiviert und deren Inciden-Status “Offen” ist. Zudem muss das Eskalations-Startdatum den Grenzwert für Eskalationsstufe 1 oder 2 überschreiten. Sollten Geschäftszeiten definiert sein, so eskaliert der Incident nur innerhalb der Geschäftszeiten. Ist ein Incident eskaliert, so erhalten alle zuständigen der Support-Mitarbeiter in regelmäßigen, konfigurierbaren Abständen eine Eskalations-Email. Außerdem ist es dem Administrator möglich, dem Anwender ein Recht (Case.Search.ShowEscalatedCasesAlways) zuzuweisen, welches ihm verbietet eskalierte Cases auszublenden.

Überfällig werden nur Incident, deren Incident-Status „Offen“ ist und deren Eskalations-Startdatum den Grenzwert für Überfälligkeit überschreitet. Bei der Anlage eines Incident wird das Eskalations-Startdatum auf das aktuelle Datum gesetzt. Beim Lösen und im Falle der Wiederöffnung eines Incidents der wird das Eskalations-Startdatum auf das aktuelle Datum zurückgesetzt. Nachdem eine erste Rückmeldung an den Kunden ging oder der Incident gelöst wurde (Systemeinstellung), kann ein Incident nicht mehr eskalieren oder überfällig werden - es sei denn er wird erneut geöffnet.

Die Grenzwerte sind abhängig von den Prioritäten, denen der Incident zugeordnet ist, und können in der Prioritäten-Maske (priorities) konfiguriert werden. Eine Deaktivierung beider Features (Eskalation/Überfälligkeit) ist bei der Installation konfigurierbar; der Administrator hat selbst keine Einflussmöglichkeit darauf.

Entscheidend für die Eskalation ist, ob bei der gewählten Kategorie die Eskalation aktiviert wurde:

Startpunkt der Eskalation nach Lösungszeit ist das Erstellungsdatum des Case (dateEscalationStart). Die Zeitdifferenz zwischen jetzt und dem Erstellungsdatum ist ausschlaggebend, ob ein Case eskaliert wird oder nicht. Vom Eskalationsdienst wird periodisch geprüft, ob diese Zeitspanne den bei der Incident-Priorität hinterlegten Zeitwert für Überfälligkeit, Eskalationsstufe 1 und Eskalationsstufe 2 übersteigt.
Sobald ein Case gelöst, benachrichtigt, geschlossen oder abgerechnet ist, wird die Eskalation außer Kraft gesetzt. Die Statusanzeigen des Case bleiben aber unverändert, d.h. wenn ein auf Stufe 1 eskalierter Incident gelöst wird, bleibt seine Statusanzeige weiterhin auf gelb.
Beim Wiedereröffnen eines Incident ist das Wiedereröffnungsdatum ausschlaggebend für die Eskalation. Zusätzlich werden beim Wiedereröffnen die Statusanzeigen für Überfälligkeit und Eskalationsstufe auf grün zurückgesetzt.

Startpunkt der Eskalation nach Reaktionszeit ist das Erstellungsdatum des Incident (dateEscalationStart). Die Zeitdifferenz zwischen jetzt und dem Erstellungsdatum ist ausschlaggebend, ob ein Incident eskaliert wird oder nicht. Vom Eskalationsdienst wird periodisch geprüft, ob diese Zeitspanne den bei der Incident-Priorität hinterlegten Zeitwert für Überfälligkeit, Eskalations-stufe 1 und Eskalationsstufe 2 übersteigt.
Sobald im Incident eine erste qualifizierte Rückmeldung (dateFirstResponse) im Incident gespeichert wird, der Incident gelöst, benachrichtigt, geschlossen oder abgerechnet ist, wird die Eskalation außer Kraft gesetzt. Die Statusanzeigen des Incident bleiben aber unverändert, d.h. wenn in einem auf Stufe 1 eskalierten Incident eine qualifizierte Rückmeldung gespeichert wird, bleibt seine Statusanzeige weiterhin auf gelb.

Wird die Priorität eines Incidents geändert, so wird die Eskalation neu berechnet, beginnend mit dem Erstellungsdatum des Incidents, aber basierend auf den Zeitwerten der neuen Priorität. Wird eine höhere Priorität gewählt, kann es daher passieren, dass die Incident sofort 'durch-eskaliert'.
Wenn gewünscht kann über die Einstellung 'restartEscalationOnPriorityChange' in der tbGlobalSettings eingestellt werden, dass als neues Startdatum der Eskalation das aktuelle Datum (Zeitpunkt der Prioritätsänderung) genutzt wird und damit die Eskalation neu startet. Die Statusanzeigen für Überfälligkeit und Eskalationsstufe werden dabei auf grün zurückgesetzt.

Die Eskalation ist an die Incident-Lebenszyklen gekoppelt. Dies bedeutet konkret, dass die Eskalation nicht neu beginnt, wenn der Incident aus dem Status „gelöst“ wieder geöffnet wird. Erst ab dem Status „benachrichtigt“ wird beim wiederöffnen die Eskalation erneut gestartet.

Ist der Status vor dem wiedereröffnen nicht gelöst, gilt:
Beim Wiedereröffnen eines Incidents ist das Wiedereröffnungsdatum ausschlaggebend für die Eskalation. Zusätzlich werden beim Wiedereröffnen die Statusanzeigen für Überfälligkeit und Eskalationsstufe auf grün zurückgesetzt.

Wird ein Incident als überfällig markiert versendet der Eskalationsdienst eine E-Mail an alle Mitglieder der entsprechenden Supportteams. Dazu wird die interne E-Mail-Vorlage supportcase.escalate.overdue verwendet.

Wird ein Incident in Stufe 1 eskaliert, versendet der Eskalationsdienst eine E-Mail an alle bei der Kategorie des Case hinterlegten E-Mailadressen. Dazu wird die interne E-Mail-Vorlage supportcase.escalate.tolevel1 verwendet.

Wird ein Incident in Stufe 2 eskaliert versendet der Eskalationsdienst eine E-Mail an alle bei der Kategorie des Case hinterlegten E-Mail-Adressen. Dazu wird die interne E-Mail-Vorlage supportcase.escalate.tolevel2 verwendet.