Ticket eskaliert, obwohl es das eigentlich nicht sollte
Ticket eskaliert, obwohl es das eigentlich nicht sollte
Hallo Zusammen,
wir haben ein Ticket, bei dem letzte Woche Donnerstag die letzte Aktion statt fand. Dem Ticket wurde ein neuer Besitzer zugeordnet und dieser hat nachdem er eine Antwort an den Kunden gesendet hat den Status auf "Warte auf Rückmeldung vom Kunden" mit einer Wartezeit bis 21.06.2016 14:55 Uhr gesetzt. In der Queue, in der sich das Ticket befindet, sind folgende Eskalationszeiten definiert:
Eskalation - Zeit für erste Reaktion (Minuten):
120
Eskalation - Aktualisierungszeit (Minuten):
120
Eskalation - Lösungszeit (Minuten):
1440
Ein Kalender wurde ebenfalls definiert (9-18 Uhr; Mo-Fr).
Am Freitag ist das Ticket nicht eskaliert, dafür aber heute Vormittag (20.06). Drei Agenten haben heute, nachdem die ersten Eskalationsbenachrichtigungen rausgangen sind, diese Queue erst abonniert und haben daraufhin später am Tag noch die Eskalationsbenachrichtigungen erhalten. Nur warum ist das Ticket überhaupt eskaliert? Da es Freitag nicht eskaliert ist und dazu noch mit einer Wartezeit bis zum 21.06 versehen wurde, hätten wir erwartet, dass das Ticket heute genauso wenig eskaliert. Wird nach dem Ablauf einer Kalenderwoche bei den Tickets irgendwas zurückgesetzt, sodass diese dennoch eskalieren, obwohl sie eigentlich nicht sollten?
Kann uns da jemand weiterhelfen?
Danke und viele Grüße
Anbei noch ein Auszug aus der Historie des Tickets:
wir haben ein Ticket, bei dem letzte Woche Donnerstag die letzte Aktion statt fand. Dem Ticket wurde ein neuer Besitzer zugeordnet und dieser hat nachdem er eine Antwort an den Kunden gesendet hat den Status auf "Warte auf Rückmeldung vom Kunden" mit einer Wartezeit bis 21.06.2016 14:55 Uhr gesetzt. In der Queue, in der sich das Ticket befindet, sind folgende Eskalationszeiten definiert:
Eskalation - Zeit für erste Reaktion (Minuten):
120
Eskalation - Aktualisierungszeit (Minuten):
120
Eskalation - Lösungszeit (Minuten):
1440
Ein Kalender wurde ebenfalls definiert (9-18 Uhr; Mo-Fr).
Am Freitag ist das Ticket nicht eskaliert, dafür aber heute Vormittag (20.06). Drei Agenten haben heute, nachdem die ersten Eskalationsbenachrichtigungen rausgangen sind, diese Queue erst abonniert und haben daraufhin später am Tag noch die Eskalationsbenachrichtigungen erhalten. Nur warum ist das Ticket überhaupt eskaliert? Da es Freitag nicht eskaliert ist und dazu noch mit einer Wartezeit bis zum 21.06 versehen wurde, hätten wir erwartet, dass das Ticket heute genauso wenig eskaliert. Wird nach dem Ablauf einer Kalenderwoche bei den Tickets irgendwas zurückgesetzt, sodass diese dennoch eskalieren, obwohl sie eigentlich nicht sollten?
Kann uns da jemand weiterhelfen?
Danke und viele Grüße
Anbei noch ein Auszug aus der Historie des Tickets:
You do not have the required permissions to view the files attached to this post.
Re: Ticket eskaliert, obwohl es das eigentlich nicht sollte
OTRS 2025 SILVER (Prod)
OTRS 2025 auf Debian 12 (Test)
Znuny 7.x latest version testing auf Debian 12
-- Ich beantworte keine Forums-Fragen PN - No PN please
I won't answer to unfriendly users any more. A greeting and regards are just polite.
OTRS 2025 auf Debian 12 (Test)
Znuny 7.x latest version testing auf Debian 12
-- Ich beantworte keine Forums-Fragen PN - No PN please
I won't answer to unfriendly users any more. A greeting and regards are just polite.
Re: Ticket eskaliert, obwohl es das eigentlich nicht sollte
Hi wurzel,
danke für die Info. Für uns lohnt es sich nicht auf die Business Solution umzusteigen, wenn wir nur ein Addon davon bräuchten. Das hat preislich gesehen wenig Sinn. Dann müssen wir damit leben oder uns etwas eigenes überlegen.
Viele Grüße
Niroc
danke für die Info. Für uns lohnt es sich nicht auf die Business Solution umzusteigen, wenn wir nur ein Addon davon bräuchten. Das hat preislich gesehen wenig Sinn. Dann müssen wir damit leben oder uns etwas eigenes überlegen.
Viele Grüße
Niroc
Re: Ticket eskaliert, obwohl es das eigentlich nicht sollte
Hey,
binde das Znuny Repository bei dir ein: http://znuny.com/#!/znuny4otrs
Dort bietet Znuny kostenfrei sein Modul Escalation Suspend an. Danke Znuny!
Viele Grüße
binde das Znuny Repository bei dir ein: http://znuny.com/#!/znuny4otrs
Dort bietet Znuny kostenfrei sein Modul Escalation Suspend an. Danke Znuny!
Viele Grüße
-
- Znuny expert
- Posts: 173
- Joined: 22 Sep 2016, 11:44
- Znuny Version: 6.0.38
- Real Name: Tux
- Location: Germany
- Contact:
Re: Ticket eskaliert, obwohl es das eigentlich nicht sollte
Hi,
kannst du mir einmal erklären wie ich ein Ticket mit (Znuny - Escalation Suspend) aussetzen kann?
Ich finde 'pending auto close+', 'pending auto close-' und 'pending reminder' nicht.
Einen Staus ändere ich sonst immer über Notiz hinzufügen.
Konfigurationseinstellungen in Znuny4OTRS-EscalationSuspend
EscalationSuspendCancelEscalation = Ja
Gruß, Tom.
kannst du mir einmal erklären wie ich ein Ticket mit (Znuny - Escalation Suspend) aussetzen kann?
Ich finde 'pending auto close+', 'pending auto close-' und 'pending reminder' nicht.
Einen Staus ändere ich sonst immer über Notiz hinzufügen.
Konfigurationseinstellungen in Znuny4OTRS-EscalationSuspend
EscalationSuspendCancelEscalation = Ja
Gruß, Tom.
-----------------------
Debian
OTRS 6.0.38, ITSM 6
Debian
OTRS 6.0.38, ITSM 6
Re: Ticket eskaliert, obwohl es das eigentlich nicht sollte
Das sind die drei Status
- Warten
- Warten auf erfolgreich schließen
- Warten auf erfolglos schließen
-
- Znuny expert
- Posts: 173
- Joined: 22 Sep 2016, 11:44
- Znuny Version: 6.0.38
- Real Name: Tux
- Location: Germany
- Contact:
Re: Ticket eskaliert, obwohl es das eigentlich nicht sollte
Das habe ich jetzt getestet.
Nachdem ich das Ticket (nach 2 Std.) wieder auf "offen"gesetzt habe ist die Aktualisierungszeit und die Lösungszeit wieder auf Anfang gesetzt.
Normal sollte doch die Lösungszeit jetzt ab dem Zeitpunkt weiter machen wo das Ticket auf "Warten auf erfolgreich schließen" gesetzt wurde, ist aber nicht.
Verstehe ich das vielleicht falsch??
Nachdem ich das Ticket (nach 2 Std.) wieder auf "offen"gesetzt habe ist die Aktualisierungszeit und die Lösungszeit wieder auf Anfang gesetzt.
Normal sollte doch die Lösungszeit jetzt ab dem Zeitpunkt weiter machen wo das Ticket auf "Warten auf erfolgreich schließen" gesetzt wurde, ist aber nicht.
Verstehe ich das vielleicht falsch??
-----------------------
Debian
OTRS 6.0.38, ITSM 6
Debian
OTRS 6.0.38, ITSM 6
Re: Ticket eskaliert, obwohl es das eigentlich nicht sollte
Das kannst du sicherlich in der Sysconfig einstellen. Ich habe mein System gerade nicht zugänglich. Aber ich denke das wirst du selbst finden.
-
- Znuny expert
- Posts: 173
- Joined: 22 Sep 2016, 11:44
- Znuny Version: 6.0.38
- Real Name: Tux
- Location: Germany
- Contact:
Re: Ticket eskaliert, obwohl es das eigentlich nicht sollte
Ich habe jetzt eine Einstellung verändert:
EscalationSuspendCancelEscalation : Nein
Bringt aber auch nichts, Lösungszeit läuft weiter ab.
EscalationSuspendCancelEscalation : Nein
Bringt aber auch nichts, Lösungszeit läuft weiter ab.
You do not have the required permissions to view the files attached to this post.
-----------------------
Debian
OTRS 6.0.38, ITSM 6
Debian
OTRS 6.0.38, ITSM 6
-
- Znuny expert
- Posts: 173
- Joined: 22 Sep 2016, 11:44
- Znuny Version: 6.0.38
- Real Name: Tux
- Location: Germany
- Contact:
Re: Ticket eskaliert, obwohl es das eigentlich nicht sollte
kleine Änderung.
Im Moment bleibt die Lösungszeit stehen, hat aber erst nach 5 Minuten angehalten.
Ich werde das weiter beobachten.
Funktioniert, brauche wohl mehr Geduld
Im Moment bleibt die Lösungszeit stehen, hat aber erst nach 5 Minuten angehalten.
Ich werde das weiter beobachten.
Funktioniert, brauche wohl mehr Geduld

-----------------------
Debian
OTRS 6.0.38, ITSM 6
Debian
OTRS 6.0.38, ITSM 6