Ticket-Einstellungen
Überblick
Sechs Reiter: Stati, Prioritäten, SLAs, Kategorien, Mail-Regeln und Blacklist.
Ticket-Stati und -Prioritäten sind eigene Kataloge, getrennt von denen der Aufgaben. Das ist kein Versehen: Ein Ticket durchläuft andere Zustände als eine Aufgabe — wartet auf Kunde ergibt im Projekt keinen Sinn.
Kernaufgaben
Stati und Prioritäten pflegen. Wie überall gilt: Status sind Daten, nicht Programm. Die Kategorie hält die Bedeutung fest, damit ein frei benannter Status in Auswertungen richtig zählt.
SLAs festlegen. Ein SLA definiert die Fristen für erste Antwort und Lösung. Zwei Punkte entscheiden über die Brauchbarkeit:
- Fristen rechnen gegen Geschäftszeiten. Ein Wochenplan mit Öffnungszeiten, Zeitzone und
Feiertagen ist die Grundlage. Ohne ihn liefe die Frist auch nachts und am Wochenende — und wäre am Montagmorgen verletzt, ohne dass jemand etwas falsch gemacht hätte.
- Ohne zugeordnetes SLA gibt es keine Frist und damit keine SLA-Zahlen im
- Warnung vor Fristablauf. Je SLA legen Sie fest, bei wie viel Prozent der verstrichenen Frist
ein Ticket als „läuft bald ab" gilt — getrennt für Reaktion und Lösung. Leer heißt: die Vorgabe des SLA, sonst 80 %. Wen die Warnung erreicht, regelt die Automatisierung „SLA-Warnung: Bearbeiter benachrichtigen" unter Automatisierungen. Sie ist anfangs ausgeschaltet und benachrichtigt den Bearbeiter des Tickets; soll zusätzlich eine Teamleitung Bescheid bekommen, legen Sie eine Kopie mit anderem Empfänger an. Ein eigenes Empfänger-Feld am SLA gibt es nicht mehr — es wurde nie ausgewertet.
- Eskalation bei Fristbruch. Reißt eine Frist, greift die Automatisierung
„SLA-Bruch: unzugewiesenes Ticket eskalierend zuweisen": ein Ticket ohne Bearbeiter geht an den Bearbeiter-Pool seiner Kategorie. Sie ist ab Werk eingeschaltet. Wer gebrochene Tickets nur markieren will, schaltet sie unter Automatisierungen aus — ein späteres Update schaltet sie nicht wieder ein. Bei bestehenden Installationen, in denen sie noch aus der Zeit stammt, als sie ausgeschaltet ausgeliefert wurde, schaltet das Update die Eskalation ein, sofern sie nie geändert wurde: niemand hat sie je ein- oder ausgeschaltet, und ihre Historie reicht bis zur Anlage zurück. Im Zweifel bleibt sie aus. Ob und warum, steht im Audit-Log bei der Automatisierung (Aktion backfill, Akteur System). Weitere Folgen (Priorität anheben, Teamleitung benachrichtigen) ergänzen Sie in einer Kopie der Automatisierung.
- Kunden bei Eskalation informieren. Unter dem SLA-Bereich steht der Schalter **„Kunden bei
Eskalation informieren". Ist er an, erfährt der Kunde beim Fristbruch im Ticket-Verlauf, dass seine Anfrage länger dauert und jetzt vorrangig bearbeitet wird — auf dem Kanal des Tickets, in seiner Sprache, als Antwort im bestehenden Mailverlauf. Höchstens eine Mitteilung je Ticket; gelöste und geschlossene Tickets sowie Tickets ohne Kunden-Adresse bekommen keine. Die Mitteilung zählt nicht als erste Antwort, die Reaktionsfrist bleibt also gebrochen. Der Schalter ist ab Werk aus und gilt für alle Marken; je Marke abweichend legen Sie unter System-Einstellungen eine Zeile tickets.escalation_customer_notice mit der Marke an (1 = an, 0 = aus). Den Ablauf steuert die Automatisierung „SLA-Bruch: Kunden über die Eskalation informieren"**; die Aktion Ticket: Kunden über die Eskalation informieren lässt sich auch in eigene Abläufe einbauen.
Kategorien pflegen. Sie gliedern das Aufkommen und sind der übliche Anknüpfungspunkt für SLAs.
Mail-Regeln einrichten. Sie steuern, was mit eingehenden Mails geschieht — etwa die Zuweisung an ein Support-Team.
Blacklist pflegen. Absender, die gar nicht erst ein Ticket erzeugen sollen. Der wirksamste Hebel gegen einen dauerhaft vollen Eingangskorb — Newsletter und automatische Antworten gehören hierher, nicht in die tägliche Handarbeit.
Felder im Detail
Die Spalte Was es bewirkt beantwortet, was sich im System ändert — nicht, wie das Feld heißt. Der graue Name dahinter ist das Feld der API: unter ihm läuft dasselbe über Automation, Import und KI-Werkzeuge.
Ticket-Status
| Feld | Pflicht | Werte / Format | Was es bewirkt |
|---|---|---|---|
Schlüssel key | ja | kurzer, stabiler Text | Die technische Kennung für Automation, Auswertung und Schnittstelle. Nicht mehr ändern, sobald Tickets darauf stehen. |
Bezeichnung label | ja | Text | Was der Bearbeiter sieht. Frei änderbar. |
Kategorie category | nein | offen, in Bearbeitung, wartet auf Kunde, gelöst, geschlossen | Die fachliche Bedeutung hinter Ihrem Namen. Daran entscheidet das System, was als offen zählt — nicht am Namen. |
Gilt als gelöst isResolved | nein | Ja/Nein | Ob ein Ticket in diesem Status als gelöst zählt. Grundlage der Lösungsquote und der Auslöser für die Zufriedenheitsfrage. |
Hält die Frist an stopsSlaClock | nein | Ja/Nein | Das wichtigste Feld der Seite. Auf ja läuft die Frist der Servicezusage nicht weiter — genau richtig für „wartet auf Kunde", denn dessen Schweigen ist nicht Ihre Verzögerung. Falsch gesetzt, verrechnet sich Ihre gesamte Fristmessung. |
Farbe color | nein | Farbwert | Farbe der Statusmarke. |
Reihenfolge sortOrder | nein | Zahl | Position in der Auswahl. |
Standard isDefault | nein | Ja/Nein | Der Status, mit dem ein neues Ticket startet. |
Aktiv active | nein | Ja/Nein | Aus heißt: nicht mehr wählbar, bestehende Tickets behalten ihn. |
Priorität
| Feld | Pflicht | Werte / Format | Was es bewirkt |
|---|---|---|---|
Schlüssel key | ja | kurzer, stabiler Text | Technische Kennung; nicht mehr ändern, sobald Tickets darauf stehen. |
Bezeichnung label | ja | Text | Was der Bearbeiter sieht. |
Stufe level | nein | 1 bis 4 | Die Rangfolge. Nicht der Name entscheidet über „dringender", sondern diese Zahl — Sortierung und Eskalation rechnen damit. |
Standard-Servicezusage defaultSlaId | nein | eingerichtete Servicezusage | Welche Fristen bei dieser Priorität gelten, wenn kein Vertrag etwas anderes sagt. |
Farbe color | nein | Farbwert | Farbe der Prioritätsmarke. |
Reihenfolge sortOrder | nein | Zahl | Position in der Auswahl. |
Standard isDefault | nein | Ja/Nein | Priorität eines neuen Tickets ohne eigene Angabe. |
Aktiv active | nein | Ja/Nein | Aus heißt: nicht mehr wählbar. |
Kategorie
| Feld | Pflicht | Werte / Format | Was es bewirkt |
|---|---|---|---|
Schlüssel key | ja | kurzer, stabiler Text | Technische Kennung; nicht mehr ändern, sobald Tickets darauf stehen. |
Bezeichnung label | ja | Text | Was der Bearbeiter sieht. |
Übergeordnete Kategorie parentId | nein | bestehende Kategorie | Baut eine zweistufige Gliederung. Auswertungen können auf der Oberkategorie zusammenfassen. |
Standard-Bearbeiter defaultAssigneeId | nein | Mitarbeiter | Wer ein Ticket dieser Kategorie automatisch bekommt. |
Bearbeiter-Kreis agentPool | nein | mehrere Mitarbeiter | Unter wem reihum verteilt wird, wenn kein fester Bearbeiter gesetzt ist. |
Standard-Marke defaultBrandId | nein | eine Ihrer Marken | Marke, unter der Tickets dieser Kategorie geführt werden. |
Reihenfolge sortOrder | nein | Zahl | Position in der Auswahl. |
Aktiv active | nein | Ja/Nein | Aus heißt: nicht mehr wählbar. |
Gesperrte Absender
| Feld | Pflicht | Werte / Format | Was es bewirkt |
|---|---|---|---|
Art type | ja | Adresse oder Domain | Ob eine einzelne Adresse oder eine ganze Domain gesperrt wird. Eine Domain-Sperre trifft auch künftige, echte Anfragen von dort — das ist der grobe Griff. |
Wert value | ja | Adresse bzw. Domain | Was gesperrt wird. Post von dort erzeugt kein Ticket mehr; sie wird abgewiesen, nicht heimlich gelöscht. |
Geltung scope | nein | systemweit oder je Marke | Wie weit die Sperre reicht. |
Marke brandId | bei „je Marke" | eine Ihrer Marken | Für welche Marke sie gilt. |
Grund reason | nein | Text | Warum gesperrt wurde. Der Satz, der in einem halben Jahr die Frage „warum kommt von denen nichts an?" beantwortet. |
Aktiv active | nein | Ja/Nein | Aus hebt die Sperre auf, ohne den Eintrag samt Grund zu verlieren. |
Einstellungen & Rechte
- Modul
module.tickets. - Recht
tickets.config.manage. Den Schalter der Kunden-Eskalation ändert, wer System-Einstellungen pflegt (platform.settings.manage). - Der Schlüssel eines Status ist dauerhaft, die Bezeichnung jederzeit änderbar.
- Deaktivieren statt löschen — bestehende Tickets behalten ihren Status.
FAQ & Fehlerbilder
SLA-Fristen wirken zu streng. Prüfen Sie die Geschäftszeiten. Ohne Wochenplan läuft die Frist rund um die Uhr.
Ein Ticket hat kein SLA. Dann greift für seine Kategorie keines. Ordnen Sie das SLA der Kategorie zu.
Der Eingangskorb füllt sich mit Werbung. Tragen Sie die Absender in die Blacklist ein.
Aufgaben-Status stehen nicht hier. Richtig — die liegen unter Aufgaben-Einstellungen, weil sie auch für Aufgaben ohne Support gelten.