Ticket
Immer wenn eine Serviceanfrage o. ä. per E-Mail eingeht oder ein Agent einen Vorgang anlegt, wird ein sogenanntes Ticket erstellt. Tickets sind mit einer Art Karteikarte vergleichbar, auf welcher ein Vorgang in seiner Gesamtheit abgebildet wird.
Tickets können zu ganz unterschiedlichen Themen angelegt werden: bspw. für die Reparatur einer Maschine, ein Drucker hat keinen Toner mehr, der Fahrstuhl ist defekt, Ersatzteilbestellungen sind erforderlich u.v.a.m.
Für die verschiedenen Aufgabenbereiche sind unterschiedliche Teams zuständig. Damit das Ticket dem Team zugeordnet wird, in dessen Aufgabenbereich der Vorgang fällt, kann es automatisch bei E-Mail-Eingang oder manuell durch einen Agenten in einem bestimmten Team-Ordner angelegt werden. Alle Tickets werden der Reihe nach in einem Team-Ordner (Queue) gespeichert. So entsteht eine Art Warteschlange, in der die Tickets – nach Priorität und Alter sortiert – liegen.
Ein Ticket enthält zunächst das Thema/den Betreff des Vorgangs und die Kontaktinformationen zum Kunden wie Ansprechpartner, E-Mail, Telefon usw. Daneben besitzt jedes Ticket einen verantwortlichen Mitarbeiter und einen Bearbeiter, was dieselbe Person sein kann. Wenn das Ticket – und somit der Vorgang – bearbeitet wird, entstehen in dessen Verlauf weitere Informationen, die dem Ticket als Artikel hinzugefügt werden: z. B. E-Mail-Korrespondenz mit und ohne Anhang, eigene Notizen, Notizen anderer Agenten, Datenblätter usw. So entsteht aus der "Karteikarte" eine ganze "Mappe", in der der gesamte Vorgang abgebildet wird. Ist der Vorgang abgeschlossen, wird auch das Ticket geschlossen.
In den Untermenüs des Menüs können Sie die Grundeinstellungen zu Tickets vornehmen. Sie können Teams anlegen, damit die Tickets den entsprechenden Aufgabenbereichen zugeordnet werden können. Sie können Ticket-Prioritäten, -Typen und -Status anlegen, damit die Tickets mit Eigenschaften gekennzeichnet werden können. Und Sie können Textbausteine anlegen, um den Agenten etwas Schreibarbeit abzunehmen. Alle Einstellungen, die Sie hier vornehmen, stehen einerseits den Agenten zur Verfügung, wenn Sie Tickets bearbeiten, andererseits generiert KIX alle Auswertungen, Tabellen, Übersichten, etc. gemäß der hier konfigurieren Einstellungen.
Wichtig
Es existieren keine Cache-Abhängigkeiten zwischen den Basisobjekten (Status, Priorität usw.) und Business-Objekten (insbes. Tickets). Änderungen an den Basisobjekten erfordern daher ein manuelles Clean-up des Caches, damit die Änderungen korrekt angezeigt werden. Führen Sie dazu im Menü Konsole den Befehl Console::Command::Maint::Cache::Delete aus.
Anmerkung
Bei der Ticketerstellung über die API (z. B. mit Insomnia) muss der Request die Pflichtfelder am Ticket enthalten.
Bei Fehlender Angabe der ContactID wird der Ticketersteller als Kontakt gesetzt und dessen PrimaryOrg als Organisation. Ist dem Nutzer kein Kontakt zugeordnet erfolgt eine Hinweismeldung.
In diesem Konfigurationsschlüssel können Sie globale Einstellungen für das Modul vornehmen.
Parameter | Beschreibung |
|---|---|
addQueueSignature | Definiert, ob an ausgehenden E-Mails die Team-Signatur automatisch enthalten sein soll.
|
ticketColors | Definiert die Darstellung der Tickets in den Ticketlisten anhand ihres Status Siehe auch: Tickets farblich hervorheben |
ticketRouteConfiguration | Definiert die Darstellung von Hinweismeldungen hinsichtlich fehlender Berechtigungen Siehe auch: Hinweise und Ticket-Routing bei fehlenden Berechtigungen |
Dieser Konfigurationsschlüssel erweitert die Basisberechtigungen der Agenten auf ehemalige Tickets.
Der Konfigurationsschlüssel ist initial deaktiviert (ungültig).
Wenn aktiviert (gültig): Agenten können auf ein Ticket zugreifen, welches zu irgendeinem Zeitpunkt in einem der unter Meine Teams (Persönliche Einstellungen des Agenten) gesetzten Teams war, auch wenn sich dieses Ticket jetzt in einem Team befindet, auf welches sie sonst keinen direkten Zugriff haben.
Wichtig
Der Agent benötigt auf das betreffende Team zum aktuellen Zeitpunkt zwingend Lese- und Schreibrechte.
Der Konfigurationsschlüssel ist initial inaktiv (ungültig). Sie können ihn bei Bedarf aktivieren. Suchen und öffnen Sie dazu den Konfigurationsschlüssel im Menü und setzen Sie die Gültigkeit auf gültig.
Der Parameter Permission definiert, welche Rechte die Agenten auf die betreffenden Tickets haben. Mögliche Werte sind:
READ: nur LeseberechtigungRW: Lese- und Schreibrechte
Hinweis
Diese Konfiguration wirkt sich lediglich auf die Basisberechtigungen aus. Sie hat keinen Einfluss auf andere Berechtigungsstufen.
Warnung
Für die Berechtigungsprüfung muss die Tickethistorie geprüft werden, was zur Verschlechterung der Systemperformanz führen kann.
Der Konfigurationsschlüssel ist initial deaktiviert (ungültig).
Wenn aktiviert (gültig): Agenten, welche als Bearbeiter am Ticket gesetzt sind, können auf das Ticket zugreifen, auch wenn sie nicht die entsprechenden Basis-Berechtigungen (z. B. auf das Team) haben.
Wichtig
Deaktivieren Sie zuvor den SysConfig-Schlüssel , da die Konfigurationsschlüssel sonst miteinander konkurrieren würden.
Hinweis
Eine Anzeige von solch indirekt sichtbaren/bearbeitbaren Tickets in Ticketlisten oder Suche erfolgt nicht. Der Zugriff auf das Objekt ist nur per URL-Direktaufruf oder vom Eltern-Ticket ausgehend möglich.
Anmerkung
Diese Konfiguration wirkt sich nur auf Basis-Berechtigungen aus.
Vererbt die Berechtigungen des Eltern-Tickets auf die Kind-Tickets.
Der Konfigurationsschlüssel ist initial deaktiviert (ungültig).
Wenn aktiviert (gültig): Agenten mit Berechtigung auf ein Eltern-Ticket können auch auf dessen Kind-Tickets zugreifen, ohne dass sie über Basis-Berechtigungen auf Kind-Tickets verfügen. Es werden die Basis-Berechtigungen des Eltern-Tickets vererbt.
Das heißt:
Besteht auf ein Ticket "A" READ-Zugriff als Basis-Berechtigung, so kann jedes Kind-Ticket von "A" ebenfalls gelesen werden.
Besteht auf ein Ticket "B" READ+WRITE-Zugriff als Basis-Berechtigung, so kann jedes Kind-Tticket von "B" ebenfalls gelesen und aktualisiert werden.
Somit kann bspw. der Agent auch ohne grundsätzliche Berechtigungen auf Teams Unteraufträge nachverfolgen und ergänzen. Der Zugriff auf die Kind-Tickets erfolgt dabei nur auf direkte Links. Diese Tickets tauchen nicht in Ticketlisten auf.
Voraussetzung für den Zugriff auf ein Kind-Ticket ist eine bestehende Verknüpfung zwischen Eltern- und Kind-Ticket vom Typ "ParentChild". Die Verknüpfung muss zwingend über das Dynamische Feld ParentTickets erfolgen. Eine Verknüpfung mit dem Dynamischen Feld ChildTickets funktioniert nicht. Gegebenenfalls müssen Sie das Dynamische Feld ParentTickets in eine Aktion (z. B. Ticket Edit) bzw. in eine Vorlage (z. B. Default - New Ticket Template) integrieren.
Hinweis
Eine Anzeige von solch indirekt sichtbaren/bearbeitbaren Tickets in Ticketlisten oder Suche erfolgt nicht. Der Zugriff auf das Objekt ist nur per URL-Direktaufruf oder vom Eltern-Ticket ausgehend möglich.
Anmerkung
Diese Konfiguration wirkt sich nur auf Basis-Berechtigungen aus.
Der Parameter MaxGenerations definiert, auf wie viele Ebenen sich die Zugriffsberechtigung ausdehnt, bzw. wie viele übergeordnete Ebenen geprüft werden, wenn eine URL aufgerufen wird.
Der Konfigurationsschlüssel ist initial deaktiviert (ungültig).
Wenn aktiviert (gültig): Agenten, welche als Verantwortliche am Ticket gesetzt sind, können auf das Ticket zugreifen, auch wenn sie nicht die entsprechenden Basis-Berechtigungen (z. B. auf das Team) haben.
Wichtig
Deaktivieren Sie zuvor den SysConfig-Schlüssel , da die Konfigurationsschlüssel sonst miteinander konkurrieren würden.
Anmerkung
Diese Konfiguration wirkt sich nur auf Basis-Berechtigungen aus.
Definiert, mit welchem Präfix die Tickets in der Ticket Detailansicht gekennzeichnet werden. Zum Beispiel:
Ticket#20251110170001411 - Drucker druckt nicht
Fall-Nr: 20251110170001411 - Drucker druckt nicht
Vorgang#20251110170001411 - Drucker druckt nicht
Standard: Ticket#
Definiert, welches Modul für das Generieren der Ticketnummern verwendet wird. Das gewählte Modul bestimmt, wie die Ticketnummern aufgebaut sind.
DateChecksum (Standard): Fügt den Zähler als Prüfsumme nach dem Datum und der SystemID ein. Die Prüfsumme rotiert täglich.
Date: Generiert die Ticketnummer aus dem aktuellen Datum, der SystemID und dem Zähler.
AutoIncrement: Erhöht den Zähler fortlaufend.Die SystemID und der Zähler werden im Format "SystemID.Zähler" dargestellt.
Random: Erzeugt zufällige Ticketnummern im Format "SystemID.Random"
Überprüft die SystemID bei der Erkennung von Ticketnummern in Rückfragen.
Default: 1
Verwenden Sie "0", wenn die SystemID nach der Verwendung des Systems geändert wurde.
Aktiviert den SysConfig-Schlüssel für den Ticketzähler, wenn "Date" oder "DateChecksum" als TicketNumberGenerator ausgewählt ist.
Aktiviert (default): 1
Deaktiviert: 0
Legt die minimale Ticketzählergröße fest, wenn "AutoIncrement", "Date" oder "DateChecksum" als TicketNumberGenerator ausgewählt wurde.
Default: 5 (der Zähler beginnt bei 00001, z. B. 2022113017000011)
Beispiel: 3 (der Zähler beginnt bei 001, z. B. 20221130170011)
Setzt den Bearbeiter eines Tickets automatisch als Verantwortlichen am Ticket. Voraussetzung dafür ist, dass der Konfigurationsschlüssel aktiviert (gültig) ist.
Dies funktioniert nur bei manuellen Aktionen des angemeldeten Benutzers. Bei automatisierten Aktionen, z. B. Automation, Postmaster und API, funktioniert dies nicht.
Legt fest, ob die Beobachter des Ausgangstickets beibehalten werden.
Beim Zusammenfassen von Tickets werden die Beobachter ans Zielticket übertragen. Für eine bessere Übersicht wird dabei die Liste der beobachteten Tickets bereinigt, indem die Tickets mit Status "merged" aus der Beobachtung entfernt werden.
Das Verhalten beim Entfernen aus der Beobachtungsliste kann in diesem Schlüssel konfiguriert werden.
Mögliche Werte:
0 (Standard): Nach dem Zusammenfassen wird das Ausgangsticket nicht mehr beobachtet.
Am Ausgangsticket steht die Aktion wieder zur Verfügung.
1: Nach dem Zusammenfassen bleiben die Beobachter am Ausgangsticket erhalten.
Am Ausgangsticket steht die Aktion zur Verfügung.