Es gibt Fälle, in denen in einem Ticket-Tool Genehmigungsprozesse abgebildet werden sollen. Ich nutze beruflich Otobo, das zwar umfangreiche Prozessfunktionen enthält, aber keinen Genehmiungsprozess nach ITIL. Entsprechend muss die genehmigende Person dem Tool als Agent hinzugefügt sein.
Status Quo
Unsere Implementation sieht vor, dass die genehmigende Person eine Mail bekommt, sobald sie etwas zu genehmigen hat, dort auf einen Link klickt, dieser das Ticket im Browser öffnet (Authentifizierung notwendig), und dann dort die Genehmigung oder Ablehnung des Anliegens durchführt.
Während den IT-nahen Abteilungen das (mit einigen Ausnahmen) leichter fällt, sind andere Abteilungen von der Komplexität etwas überwältigt. Vor allem, wenn das Onboarding ins Tool gar nicht oder nur rudimentär erfolgt ist. Dazu kommt, dass nach der Genehmigung im Tool direkt eine Fehlermeldung angezeigt wird, da die Entscheider:innen nach der Freigabe keinen Zugriff mehr auf das Ticket haben, da das ja hinterher von anderen Abteilungen bearbeitet werden soll.
Lösungsansatz: Genehmigung per Mail
Entscheider:innen sollen direkt per Mail aus ihrem Mailprogramm heraus ihre Anfragen genehmigen oder ablehnen können. Das verhindert, dass sie sich in der Oberfläche des Tools anmelden müssen und so bekommen sie auch keine Meldungen über fehlende Berechtigungen.
Implementierung
Um den oben genannten Lösungsansatz umzusetzen sind kaum Anpassungen am Prozess notwendig. Stattdessen werden die Ticket-Benachrichtigungen angepasst und Postmaster-Filter genutzt um DynamicFields entsprechend zu befüllen.
Ticket-Benachrichtigung
Wir senden eine Mail an den Ticket Owner, zum Ereignis NotificationOwnerUpdate. Diese enthält via DynamicFields alle relevanten Informationen die zur Genehmigung notwendig sein sollten, inklusive Name des Bestellers, bestelltes Item, Kostenstelle, Projektnummer, eventuelle weitere Kommentare. Zusätzlich ein Link um das Ticket im Browser zu öffnen, für den Fall, dass weitere Informationen benötigt werden. Herzstück des Prozesses sind aber zwei mailto-Links.
mailto-Links
Wir erstellen zwei mailto-Links, einen zum Genehmigen, einen zum Ablehnen. Beide haben die Ticket-Nummer als OTOBO-Variable eincodiert (<OTOBO_TICKET_TicketNumber>), und senden an eine Mailadresse des Ticket-Tools. Das ist wichtig, da Otobo sonst die Mail nicht dem richtigen Ticket zuordnen kann. Je nach Implementierung ist es sinnvoll dafür eine separate Adresse zu nutzen, mit Postmaster-Filtern kann darauf nochmal separat geprüft werden.
mailto:otobo@example.com?subject=%5BTicket%23%3COTOBO_TICKET_TicketNumber%3E%5D%20Anforderung%20genehmigen
mailto:otobo@example.com?subject=%5BTicket%23%3COTOBO_TICKET_TicketNumber%3E%5D%20Anforderung%20ablehnen
Ich nutze zum Erstellen der Links https://mailtolink.me. In meinen Tests konnte ich die Otobo-Variablen direkt mit ihren spitzen Klammern dort eintragen, Otobo hat den entstandenen Code dann richtig interpretiert.
Ticket-Filter
Passe den Ticket-Filter für dich passend an. Begrenze ihn beispielsweise auf eine bestimmte Queue. Als Trigger nutze ich NotificationOwnerUpdate, da unser Prozess vorsieht, dass der Genehmiger als Ticket-Owner eingesetzt wird.
Postmaster-Filter
Wir nutzen zwei Postmaster-Filter, einen für Genehmigungen, einer für Ablehnungen. In beiden Fällen durchsuchen wir das Mail-Subject, das wir ja mit dem Mailto-Link gesetzt haben. Als Aktion ändert der Filter ein DynamicField auf den Wert Approved oder Denied, je nachdem. Im Prozess kann das Ticket dann entsprechend weiterverarbeitet werden.
Weitere Änderungen
Es empfiehlt sich, an den Standard Ticket-Benachrichtigungen etwas zu drehen, um doppelte Mails zu verhindern. Ich habe für die Queue in der die Tickets auf die Genehmigung warten die TicketOwnerUpdateNotification und Ticket follow-up notification ausgenommen. Alternativ könnte man auch beispielsweise auf eine ActivityID filtern oder bestimmte Personen ausnehmen.