Ticket-Konzept

Diese Seite erklärt, wie das Ticketsystem zwischen Shop-Frontend, Admin-Warteschlange und Discord funktioniert.

Verwende sie, wenn du die gemeinsamen Mechaniken hinter Sichtbarkeit, Statuswechseln, Teilnehmern und Discord-Verhalten verstehen willst.

Was ein Ticket enthält

Jedes Ticket kombiniert:

• einen Betreff
• einen Status
• eine Teilnehmerliste
• einen Nachrichtenverlauf
• optional einen Bearbeiter
• optional einen Discord-Channel
• optional eine Anliegensart („Kategorie“) und die Antworten, die der Spieler beim Öffnen gegeben hat

Im Shop erstellte Tickets fügen den Ersteller automatisch als Teilnehmer hinzu. Von Mitarbeitern erstellte Tickets können ohne Teilnehmer starten und später in der Admin-Warteschlange ergänzt werden.

Von Mitarbeitern und von der KI erstellte Tickets haben keine Anliegensart: sie durchlaufen kein Aufnahmeformular, also gibt es nichts zu erfassen.

Ticket-Lebenszyklus

Tickets wechseln durch diese Zustände:

• Offen: neu erstellt oder wieder geöffnet
• In Bearbeitung: die erste öffentliche Antwort setzt ein offenes Ticket auf in Bearbeitung
• Geschlossen: das Ticket ist gelöst, kann aber wieder geöffnet werden
• Archiviert: das Ticket ist abgeschlossen und der Discord-Channel wird entfernt

Wichtige Abläufe:

• das Wiederöffnen eines geschlossenen Tickets behält den vorhandenen Discord-Channel und entsperrt ihn erneut
• das Wiederöffnen eines archivierten Tickets erstellt einen neuen Discord-Channel und spielt den letzten öffentlichen Verlauf erneut ein
• wenn Tickets automatisch archivieren aktiviert ist, archiviert das Schließen das Ticket sofort, statt es im geschlossenen Zustand zu belassen

Teilnehmer und Sichtbarkeit

Teilnehmer bestimmen, welche Spieler ein Ticket in Shop -> Tickets sehen können.

Mitarbeiter können hinzufügen:

• einzelne Spieler
• alle aktuellen Mitglieder einer Fraktion

Wichtige Abläufe:

• nur Teilnehmer sehen ein Ticket im Shop
• interne Notizen werden Spielern nie angezeigt
• das Hinzufügen oder Entfernen eines Teilnehmers aktualisiert auch den Discord-Channel-Zugriff für verknüpfte Discord-Konten

Discord-Verhalten

Navigationspfad für die Einrichtung:

• Server Admin -> Einstellungen -> Discord

Relevante Einstellungen:

• Discord-Server
• Discord-Tickets-Kategorie — nur die Ausweichkategorie für ein Support-Level ohne eigene Kategorie
• Discord-Ticket-Channel-Präfix
• Tickets automatisch archivieren

Wenn Discord konfiguriert und der Bot installiert ist:

• erhält jedes Ticket seinen eigenen Discord-Textchannel, angelegt in der Kategorie seines Support-Levels
• besitzt jedes Support-Level eine vom Bot verwaltete Discord-Rolle, deren Mitglieder die Channel dieses Levels lesen können
• erhalten Mitarbeiter diese Rollen automatisch, gesteuert über ihre Level-Rechte in dzbot
• werden öffentliche Nachrichten zwischen dzbot und Discord gespiegelt
• bleiben interne Notizen privat in dzbot und posten in Discord nur einen kurzen Hinweis
• erhalten Teilnehmer bei archivierten Tickets eine DM mit Wiederöffnen-/Ansehen-Aktionen

Aufmerksamkeitsstatus

Jedes aktive Ticket verfolgt, wer die letzte öffentliche Nachricht gesendet hat. Dies steuert App-Badges, die in jeder Ticket-Zeile in der Admin-Warteschlange und der Spieler-Shop-Liste angezeigt werden:

• Benötigt Aufmerksamkeit — die letzte öffentliche Nachricht stammt von einem Spieler; der Support hat noch nicht geantwortet
• Wartet auf Antwort — die letzte öffentliche Nachricht stammt vom Support; der Spieler hat noch nicht geantwortet

Discord-Channel-Header-Aktionen

Die angeheftete Header-Nachricht in jedem Ticket-Channel enthält interaktive Steuerelemente:

• Schließen / Wiederöffnen / Archivieren – Statusschaltflächen für Nutzer mit dem entsprechenden Zugriffsrecht
• Mir zuweisen / Zuweisung aufheben – Zuweisungsschaltflächen
• Teilnehmer hinzufügen (Benutzerauswahl) – eine Discord-Benutzerauswahl, mit der Moderatoren direkt im Channel einen Discord-Nutzer als Teilnehmer hinzufügen können; erfordert das Zugriffsrecht admin.tickets.add_participant
• Support-Level-Button – nur auf Servern mit mehreren Levels sichtbar. Ein Klick antwortet mit einer privaten Auswahl der Ziel-Level; die Level-Namen stehen bewusst nie in der angepinnten Nachricht, die die Teilnehmer des Tickets mitlesen können. Mitarbeiter ohne admin.tickets.change_level erhalten eine private Absage.

Wenn ein ausgewählter Nutzer kein verknüpftes Spieler-Konto hat, antwortet der Bot mit einer Fehlermeldung im Channel. Das erneute Auswählen eines bereits vorhandenen Teilnehmers wird stillschweigend ignoriert.

Anliegensarten und das Aufnahmeformular

Jeder Server hat eine konfigurierbare Menge von Anliegensarten (Kategorien). Jede Art besitzt ein kleines Formular, das der Spieler ausfüllt, bevor das Ticket existiert — damit eine Meldung vollständig ankommt statt als „hi ich hab ein Problem“: eine Fraktionsanmeldung fragt nach dem Fraktionsnamen, eine Multi-Account-Meldung nach dem Gemeldeten und dem Beweis.

Es geht um eine saubere Aufnahme, nicht um Auswertung. Nichts im System liest die strukturierten Antworten zurück — sie existieren, damit das Team genau sieht, was gefragt und was geantwortet wurde.

Feldtypen

Ein Formular hat maximal fünf Felder. Das ist keine Geschmacksfrage: ein Discord-Modal nimmt „zwischen 1 und 5 Komponenten“, und ein abgesendetes Modal kann kein zweites öffnen. Beide Oberflächen müssen dasselbe Formular zeigen — also gibt Discord die Untergrenze vor.

Typ	Discord	Shop
Kurzer Text	einzeiliges Texteingabefeld	<input>
Langer Text	mehrzeiliges Texteingabefeld	<textarea>
Auswahl	Dropdown, Radio-Gruppe oder Checkbox-Gruppe	Select, Radios oder Checkboxen
Checkbox	Checkbox (eine erforderliche muss gesetzt sein)	Checkbox
Datei-Upload	Datei-Upload, 1–10 Dateien	Datei-Eingabe

Jedes Feld kann zusätzlich einen Hinweis tragen, der neben der Eingabe erscheint und keinen Formularplatz kostet.

Wie aus Antworten ein Ticket wird

Jede Art hat zwei Vorlagen, beide mehrsprachig:

• die Betreff-Vorlage erzeugt den Ticket-Betreff
• die Nachrichten-Vorlage erzeugt die erste Nachricht des Tickets

Verfügbare Platzhalter:

Platzhalter	Betreff	Nachricht	Wert
{category}	✅	✅	Name der Anliegensart in der Sprache, in der ausgefüllt wurde
{player}	✅	✅	Anzeigename des Erstellers
{field:<key>}	✅	✅	die Antwort eines Feldes (Auswahl → Option-Labels, Checkbox → ja/nein, Datei → Dateinamen)
{fields}	❌	✅	eine Label: Wert-Zeile pro ausgefülltem Feld, in Formularreihenfolge

Regeln, die in der Praxis zählen:

• ein Platzhalter, der zu nichts auflöst, wird durch nichts ersetzt; eine Zeile, die dabei leer wird, fällt weg
• der Betreff wird auf eine Zeile zusammengezogen und auf 100 Zeichen gekürzt; ergibt er nichts, greift der Name der Anliegensart und danach „Ticket“
• die erste Nachricht hat dieselbe Kette mit dem Namen der Anliegensart und danach einem Gedankenstrich — ein Formular, dessen Felder alle optional und alle leer sind, darf keinen leeren Eröffnungsbeitrag erzeugen
• Vorlagen sind reiner Text; Ticket-Nachrichten werden nach Discord gespiegelt und im Shop gerendert, und Markdown würde auf einer der beiden Seiten seine Sternchen zeigen

Der Antwort-Snapshot

Neben der gerenderten Nachricht speichert das Ticket einen Snapshot der Aufnahme: Feld-Labels und die Labels der gewählten Optionen werden hineinkopiert. Ein Ticket ist ein Protokoll — ein umbenanntes Feld oder eine drei Monate später gelöschte Anliegensart darf ein altes Ticket nie umschreiben oder leeren. Wird eine Art gelöscht, bleiben ihre Tickets lesbar; sie verlieren nur Badge und Platz im Warteschlangenfilter.

Die Willkommensnachricht

Eine Anliegensart kann eine Willkommensnachricht tragen. Sie wird als erste Support-Nachricht gepostet, noch vor der eigenen Nachricht des Spielers, und liest sich damit als Vorwort. Sie ist mehrsprachig wie alles andere an der Art und wird in der Sprache aufgelöst, in der das Formular ausgefüllt wurde.

Früher war das eine serverweite Einstellung (Ticket-Willkommensnachricht). Sie ist an die Anliegensart gewandert, weil ein Fraktionsbewerber etwas anderes wissen muss als jemand, der einen Multi-Account meldet. Zwei Konsequenzen:

• die Server-Einstellung gibt es nicht mehr; jede Art wird einzeln konfiguriert, eine leere postet nichts
• ein Ticket ohne Anliegensart bekommt gar keine Willkommensnachricht — das betrifft von Mitarbeitern erstellte Tickets (die nie eine hatten), von der KI erstellte, und den alten ticket_embed_create-Button, bis der Server echte Panels veröffentlicht

Wie die Aufnahme-Nachricht ist sie reiner Text, und sie wird nur gepostet, wenn das Ticket einen Discord-Channel hat.

Discord-Panels

Eine Anliegensart kann pro Discord-Channel eine Panel-Nachricht besitzen: ein Embed mit Name und Beschreibung der Art und einem „Ticket erstellen“-Button pro gepflegter Sprache. Der geklickte Button trägt die Sprache mit, also muss nichts aus den Discord-Einstellungen des Spielers geraten werden.

Mehrere Panels pro Art sind der Normalfall, nicht die Ausnahme: Eine Guild, die registrierte Spieler von Gästen trennt, hat mehr als einen Channel, aus dem ein Ticket geöffnet werden darf, und dieselbe Art muss aus jedem erreichbar sein. Der Button trägt nur Art und Sprache, deshalb sind alle Panels einer Art austauschbar — ein Ticket aus dem Gäste-Channel ist dasselbe Ticket wie eines aus dem Mitglieder-Channel.

Eine Sprache gilt nur dann als gepflegt, wenn Name und jedes Feld-Label darin gefüllt sind — sonst bekäme ein deutscher Spieler ein halb englisches Formular.

Das Panel spricht die Sprache des Servers: Embed-Titel, die führende Beschreibung und der erste Button stehen in der am Server eingestellten Sprache. Jede weitere gepflegte Sprache folgt dahinter — ihre Beschreibung als Abschnitt mit einer Überschrift in dieser Sprache („English version“ auf einem deutschen Server), ihr Button als nächster in der Reihe. Eine Art mit nur einer gepflegten Sprache zeigt diese ohne Überschrift, welche es auch ist.

Panels sind verwaltet: Channel- und Nachrichten-ID werden für jedes gespeichert, und die Nachricht wird bei jeder Änderung an ihrer Stelle aktualisiert — ein veraltetes Panel, dessen Button nicht mehr zu seinem Formular passt, ist der klassische Ticket-Bot-Fehler. Drei Konsequenzen:

• Veröffentlichen wird verweigert, solange die Art nicht mindestens ein Feld und eine gepflegte Sprache hat
• jede Änderung verteilt sich über alle Panels der Art, und ein Channel, in dem der Bot seine Rechte verloren hat, hält die übrigen nicht davon ab, aktualisiert zu werden
• Discord kann Nachrichten nicht umsortieren, also verschiebt das Umsortieren der Anliegensarten die Panels nicht; dafür gibt es die ausdrückliche Aktion „Panels neu aufbauen“, die die Panels eines Channels löscht und neu postet

Ein Panel-Eintrag lebt genau so lange wie seine Discord-Nachricht: Löscht jemand die Nachricht, verwirft der nächste Aktualisierungsversuch den Eintrag und der Editor bietet erneutes Veröffentlichen an.

Zuweisung

Eine Anliegensart kann ein Standard-Support-Level benennen, damit der häufigste Wunsch — „diese Art von Anfrage gehört immer zu Team X“ — keine manuelle Eskalation braucht. Ohne eines starten Tickets dieser Art wie alle anderen in der Eingangs-Warteschlange.

Support-Level

Die Ticketbearbeitung lässt sich in Support-Level aufteilen, damit der First-Level-Support nur die Eingangs-Warteschlange bearbeitet und hochgereichte Tickets für ihn unsichtbar werden.

• Jeder Server hat mindestens ein Level. Neue Tickets starten immer auf Position 1.
• Anzahl und Namen der Level sind unter Server Admin -> Tickets -> Level konfigurierbar.
• Die Sichtbarkeit ist kumulativ: Das höchste Level, das ein Mitarbeiter hat, gewinnt, und alle Level darunter bleiben sichtbar. Eine vergessene Checkbox kostet damit die Sicht auf das Level darüber, niemals die auf die Tickets darunter.
• Das Level eines Tickets ist in dzbot maßgeblich. Alle mitarbeiterseitigen Oberflächen respektieren es: Warteschlange, Ticket-Detailseite, globale Suche, die Ticket-Werkzeuge des KI-Companions, das Spielerdossier und die Discord-Channel-Buttons.
• Spieler sehen keine Level. Ein Teilnehmer erreicht sein eigenes Ticket immer, egal wohin es verschoben wurde.
• Dashboards und Statistiken werden bewusst nicht nach Level gefiltert — das sind systemweite Zahlen.

Hoch- und Zurückreichen

Ein Ticket kann von der Ticket-Detailseite im Admin-Bereich oder aus dem angepinnten Discord-Header in jedes höhere und zurück in jedes niedrigere Level verschoben werden. Beides erfordert admin.tickets.change_level sowie aktuelle Sicht auf das Ticket, und beides verlangt eine Begründung.

Bei jedem Levelwechsel:

• wird die Begründung als interne Notiz mit beiden Levels und dem handelnden Mitarbeiter festgehalten
• wird die Zuweisung entfernt, damit das Ticket in der empfangenden Warteschlange als unbearbeitet auftaucht
• bleiben Status und Aufmerksamkeitsstatus unverändert
• wandert der Discord-Channel in die Kategorie des neuen Levels, und die Rollen-Overwrites werden getauscht

Ein Ticket über das eigene Level hinaus zu verschieben ist erlaubt; die App warnt vorher und führt danach zurück in die Warteschlange, weil das Ticket dann nicht mehr sichtbar ist.

Level in Discord

Jedes Level besitzt:

• eine Kategorie, die der Bot beim Anlegen des Levels erstellt und die später über den Verwaltungs-Drawer austauschbar ist
• eine vom Bot verwaltete Rolle, deren Mitgliedschaft dem Level-Recht in dzbot folgt — dzbot-Rechte sind hier die einzige Wahrheit, genau wie bei den Rollen connected und online

Weil die Sichtbarkeit kumulativ ist, erhält ein Mitarbeiter mit Level 3 auch die Rollen von Level 1 und 2, sodass die unteren Kategorien lesbar bleiben.

Ist Discord nicht installiert oder fehlen dem Bot Rechte, funktionieren Level trotzdem — Kategorie und Rolle bleiben leer, und den Verwaltungs-Drawer bietet eine Reparatur an.

Gesperrte Ticketverweise

Eine Notiz, Einschränkung oder ein Dossier-Eintrag kann auf ein Ticket verweisen, das der Betrachter nicht sehen darf. Solch ein Verweis behält seinen Link und wird mit einem Schloss markiert, sein Betreff wird jedoch nicht ausgeliefert. Beim Öffnen wird gezeigt, in welchem Level das Ticket liegt, statt eines allgemeinen Zugriffsfehlers — der umgebende Kontext geht so nie still verloren.

Zugriffsrechtsmodell

Spielerrechte:

• player.tickets.view, um den Ticketbereich im Shop zu öffnen
• player.tickets.create, um neue Tickets zu erstellen
• player.tickets.send_message, um bei aktiven Tickets zu antworten und den Betreff zu bearbeiten
• player.tickets.close, um aktive Tickets zu schließen
• player.tickets.archive, um gelöste Tickets zu archivieren, wenn Auto-Archivierung deaktiviert ist

Admin-Rechte:

• admin.tickets.view für schreibgeschützten Zugriff auf die Admin-Warteschlange
• admin.tickets.reply für öffentliche Support-Antworten, von Mitarbeitern erstellte Tickets, das Anheften von Nachrichten und das Hochladen von Beweisdateien
• admin.tickets.internal_message für interne Notizen
• admin.tickets.assign für Bearbeiter-, Teilnehmer- und Betreffverwaltung im Admin-Panel
• admin.tickets.change_status für manuelle Statusänderungen
• admin.tickets.add_participant, um Teilnehmer direkt über die Discord-Channel-Benutzerauswahl hinzuzufügen
• admin.tickets.change_level, um ein Ticket zwischen Support-Levels zu verschieben
• admin.tickets.manage_levels, um Support-Levels anzulegen, umzubenennen, umzusortieren und zu löschen
• admin.tickets.manage_categories, um Anliegensarten anzulegen, zu bearbeiten, umzusortieren und zu löschen und ihre Discord-Panels zu veröffentlichen
• admin.tickets.level_<id> — ein Recht pro Support-Level, siehe Support-Level
• logs.view, um den Untersuchungs-Tab auf der Ticket-Detailseite zu nutzen
• restrictions.view, um verknüpfte Einschränkungen im Prüfungs-Tab eines Tickets einzusehen
• restrictions.create, um Einschränkungen direkt aus einem Ticket heraus zu erstellen

Für Gruppenstrategien und gemischte Mitarbeiter-/Spieler-Setups siehe Zugriffskontrolle.

Verwandte Dokumentation

• Tickets in der Spieleransicht
• Tickets in der Admin-Ansicht
• Einstellungen
• Discord-Integration
• Zugriffskontrolle