Im Matrix42 Service Desk ist es standardmäßig so, dass geschlossene Tickets auch geschlossen bleiben. Wenn der Benutzer also anschließend eine E-Mail schreibt und sagt, das Problem ist noch nicht gelöst, bleibt das Ticket geschlossen und man bekommt keine Information darüber.
Viele wünschen sich hier eine automatische Wiedereröffnung, zumindest wenn das Ticket noch nicht so alt ist. Hierzu gibt es 3 Möglichkeiten:
- Eine Konformitätsregel, die den Status des Tickets ändernd
- Der Systemstandard mit einem speziellen Pausierungsgrund „Warte auf Benutzerrückmeldung“
- Einen Filter, der geschlossene Tickets mit neuen Informationen anzeigt
Möglichkeit 1: Konformitätsregel

Die erste Möglichkeit ist eine Konformitätsregel, die geschlossene Tickets wieder auf den Status „Neu“ ändern, wenn das Attribut „NewInformationReceived“ auf wahr gesetzt wird. Denn passiert bei neuen E-Mails zu einer Anfrage oder auch beim Hinzufügen eines Journaleintrags durch den Initiator.
Neue Regel erstellen

Bedingung konfigurieren

Aktion konfigurieren & speichern
Folge nun einfach den Screenshots, um die Konformitätsregel-Aktionen zu konfigurieren und anschließend zu speichern







Zusätzlich zu der Aktion Daten ändern könntest du natürlich noch dem Verantwortlichen eine E-Mail schicken, in der der über das wiedereröffnete Ticket informiert wird.
Möglichkeit 2: Warte auf Benutzerrückmeldung
Anstatt das Ticket zu schließen, kannst du auch in den Systemeinstellungen vom Service Desk die Einstellung „Ticket bei ausbleibender Benutzerartwort schließen“ aktivieren.


Den Zeitraum kannst du natürlich anpassen.
Wenn du nun das Ticket, anstatt es direkt zu schließen, nur mit der Begründung „Warte auf Benutzerrückmeldung“ anhältst, musst du es mindestens einen Tag länger anhalten, als in den Systemeinstellungen konfiguriert ist.

Sollte der Benutzer innerhalb der 31 Tage dieses Beispiels nicht antworten, wird das Ticket automatisch geschlossen.
Falls der Nutzer innerhalb des Pausierungszeitraums antwortet, wird das Ticket ganz normal reaktiviert und der Bearbeiter erhält eine Information. Danach kann das Ticket entsprechen geschlossen oder weiterbearbeitet werden.
Möglichkeit 3: Filter
Als letzte Möglichkeit kannst du auch einen eigenen Filter anlegen, der nur geschlossene Störungen, Serviceanfragen oder beides mit neuen Informationen anzeigt.


NewInformationReceived = 1
[wpdiscuz-feedback id=“neh2s1xqh8″ question=“Wie handhabt ihr eigentlich das Problem mit den Geschlossenen Tickets & neuen Informationen?“ opened=“0″]In der Praxis hat es sich oft als effektiv erwiesen, die Tickets zu schließen und einfach 1x wöchentlich in diesen Filter zu schauen.<br>[/wpdiscuz-feedback]
Falls du noch etwas Spannendes lernen willst, schau mal hier wie du UUX Elemente abhängig von der Benutzerrolle aus- und einblenden kannst.
Hallo, danke für die Tipps.
Gibt es denn keine Möglichkeit einzustellen dass bei einer Antwort auf ein geschlossenes Ticket, ein neues Ticket erstellt wird und mit dem ursprünglichen verknüpft wird? Kenn das vom OTRS, welches dies im Standard kann.
Hi Dado,
also im Standard gibt es da keine Möglichkeit. Man könnte sich wahrscheinlich ein ziemlich wildes Customizing bauen, welches durch eine Konfi Regel bei geschlossenen Tickets mit neuen Informationen einen WF startet, der den letzten Journaleintrag extrahiert und dann über Create Object ein Ticket anlegt und das bestehende verknüpft.
Einfacher wäre es eine Mail zu senden, den User drauf hinzuweisen er soll doch bitte ein neues eröffnen und ihn somit gleich zu „erziehen“, auch wenn das nicht bei allen klappt 😉
Beste Grüße & schöne Festtage
Simon
Hi Simon,
vielen Dank für die Rückmeldung, die mich doch etwas enttäuscht.
Wir stehen erst in den Startlöchern, und wenn das auch nicht so oft der Fall sein sollte mit den geschlossenen Tickets ist es doch ein Rückschritt – vor allem da man als IT automatisieren und nicht „manualisieren“ sollte 🙂
Beste Grüße & auch dir schöne Festtage
Dado
Hi,
ich habe die Einstellungen der Konformitätsregel, wie im Artikel „Geschlossene Tickets bei neuer E-Mail wiedereröffnen“ beschrieben, umgesetzt. Leider wird die Regel nicht ausgeführt, sodass die Störung nicht wiedereröffnet wird.
Testweise habe ich andere Bedingungen und Aktionen ausführen lassen.
Bedingung:
Journaleintrag.ActivityAction (Aktivität Aktion) Geändert Erstellung durch Email Robot
Aktion:
Daten ändern Benutzer ändern
Auch mit diesen Einstellungen wird die Regel nicht angewendet. Kann ich in einem Log nachvollziehen, warum die Regel nicht angewendet wird? Wo könnte der Fehler noch liegen?
Viele Grüße
Hi,
ich habe da so eine ganz blöde Idee:
Ist es möglich, dass das E-Mail-Konto, dass die E-Mail schickt, in irgendeiner Rolle ist, die Tickets bearbeitet?
Denn falls ja, wird das Flag NewInformationReceived nicht gesetzt (Ticket wird im Grid ebenfalls nicht fett hervorgehoben)…
Wenn das der Fall ist, dann die Konfi-Regel einmal wieder zurückbauen & mit einer anderen Mail testen, dessen zugehöriger Nutzer NICHT in einer verantwortlichen Rolle Mitglied ist.
Beste Grüße
Hi,
entschuldige für die späte Rückmeldung.
Der Tipp war zum Teil richtig und hat zumindest bewirkt, dass das Ticket nun fett hervorgehoben wird.
Leider wird das Tcket aber nicht wiedereröffnet.
Viele Grüße
Hi MX42,
wir hatten da einen kleinen Fehler im Screenshot, sollte nun funktionieren 👌