Zum Hauptinhalt springen

Tickets in der Admin-Ansicht

Diese Seite erklärt, wie Mitarbeiter die Ticket-Warteschlange im Admin-Bereich verwenden.

Navigationspfad:

  • Server Admin -> Tickets

Für den gemeinsamen Lebenszyklus und das Discord-Verhalten hinter der Warteschlange siehe Ticket-Konzept.

Zugangsvoraussetzungen​

  • admin.tickets.view für schreibgeschützten Zugriff auf Warteschlange und Ticket-Details
  • admin.tickets.reply, um Mitarbeiter-Tickets zu erstellen, öffentliche Antworten zu senden, Nachrichten anzuheften und Beweisdateien hochzuladen
  • admin.tickets.internal_message, um interne Notizen hinzuzufügen
  • admin.tickets.assign, um Tickets zuzuweisen, Teilnehmer zu verwalten und den Betreff zu bearbeiten
  • admin.tickets.change_status, um den Ticketstatus manuell zu ändern
  • admin.tickets.add_participant, um Teilnehmer direkt über die Discord-Channel-Benutzerauswahl hinzuzufügen
  • admin.tickets.change_level, um ein Ticket in ein anderes Support-Level zu verschieben
  • admin.tickets.manage_levels, um Tickets -> Level zu öffnen und die Level selbst zu verwalten
  • admin.tickets.manage_categories, um Tickets -> Anliegensarten zu öffnen und die Anliegensarten samt ihrer Discord-Panels zu verwalten
  • admin.tickets.level_<id> für jedes Support-Level, dessen Tickets die Rolle sehen soll
  • logs.view, um den Untersuchungs-Tab zu nutzen und gespeicherte Log-Abfragen im Prüfungs-Tab auszuführen
  • restrictions.view, um verknüpfte Einschränkungen im Prüfungs-Tab einzusehen
  • restrictions.create, um Einschränkungen direkt aus einem Ticket heraus zu erstellen

Kompatibilitätshinweis: Bestehende Support-Gruppen mit admin.tickets.reply, admin.tickets.internal_message, admin.tickets.assign oder admin.tickets.change_status können die Warteschlange weiterhin auch ohne admin.tickets.view öffnen. Für neue Rollensetups sollte admin.tickets.view jedoch explizit vergeben werden, wenn die Rolle schreibgeschützten Zugriff braucht.

Support-Level​

Badge und Filter erscheinen nur auf Servern, die tatsächlich mehr als ein Level nutzen — ein Server mit einem Level sieht von dem Konzept nichts. Der Level-Button ist die Ausnahme: er wird Inhabern von admin.tickets.manage_levels immer gezeigt, weil nur dort ein zweites Level angelegt werden kann.

Auf einem Server mit mehreren Levels bekommt die Warteschlange:

  • einen Level-Badge in jeder Ticket-Zeile, der bei aktivem Level-Filter wieder verschwindet (er würde den Filter in jeder Zeile wiederholen)
  • eine Level-Kette neben dem Suchfeld zur Auswahl des angezeigten Levels
  • ein Warnbanner, wenn du Ticketrechte, aber überhaupt kein Level-Recht hast — ein ausdrückliches „dir fehlt ein Level-Recht" statt einer still leeren Warteschlange

Level eines Tickets wechseln​

Level wechseln auf der Ticket-Detailseite öffnet einen Dialog mit dem Ziel-Level (voreingestellt ist das nächsthöhere) und einer verpflichtenden Begründung. Über das eigene Level hinaus zu verschieben ist erlaubt: Der Dialog warnt, dass das Ticket aus deiner Ansicht verschwindet, und die App führt nach dem Speichern zurück in die Warteschlange.

Die Begründung landet als interne Notiz mit beiden Levels und dir, die Zuweisung wird entfernt, damit das Ticket in der empfangenden Warteschlange als unbearbeitet auftaucht, und Status wie Aufmerksamkeitsstatus bleiben unverändert.

Dieselbe Aktion steht im angepinnten Discord-Ticket-Header zur Verfügung.

Gesperrte Tickets​

Ein Ticket in einem Level, das du nicht hast, bleibt als Verweis in Notizen, Einschränkungen und im Spielerdossier sichtbar: Link und Ticketnummer bleiben, mit Schloss markiert, aber Betreff und Status werden nicht ausgeliefert — zusammen mit einer Ticket-ID würden sie jede Notiz sonst zu einem Existenz- und Status-Orakel für genau die Warteschlange machen, die die Level abschirmen. Beim Öffnen wird das Level genannt statt eines allgemeinen Zugriffsfehlers. Ein solcher Verweis kann außerdem von niemandem angelegt oder entfernt werden, der das Ticket nicht sehen darf.

Level verwalten​

Der Level-Button öffnet einen Drawer über der Warteschlange — die Liste dahinter behält ihre Filter und lädt nicht neu. Er listet alle Level in ihrer Reihenfolge und erlaubt:

  • ein Level anzulegen (wird am Ende angefügt), umzubenennen und umzusortieren
  • zu sehen, wie viele Tickets es enthält und wie viele Gruppen und Spieler sein Recht haben
  • den Zustand seiner Discord-Kategorie und -Rolle zu sehen, mit einer Neu anlegen-Aktion, wenn eines fehlt
  • es zu löschen, wobei nach einem Ziel-Level gefragt wird, solange es noch Tickets enthält

Zwei Regeln:

  • Level 1 kann nicht gelöscht werden — dort startet jedes neue Ticket.
  • Ein neues Level hat niemand. Seine Tickets sind unsichtbar, bis du das Recht vergibst, und die Zeile warnt solange mit einem Link zum Gruppen-Rechteeditor. dzbot schreibt niemals Rechte für jemanden mit. Gruppen mit einer admin.*-Wildcard sind automatisch abgedeckt.

Umsortieren ändert nur die Anzeigeposition; die Rechte hängen an der ID des Levels, es wird also keine Berechtigung neu vergeben. Umsortieren und Auflösen ändern allerdings, was ein bestehendes Recht sieht — die Sichtbarkeit löst kumulativ über die Position auf — deshalb erfordern beide Zugriff auf alle Level, nicht nur admin.tickets.manage_levels.

Aufmerksamkeits-Badges​

Jede Ticket-Zeile in der Warteschlange zeigt einen Badge, der anzeigt, wer als Nächstes antworten sollte:

  • Benötigt Aufmerksamkeit (Amber-Pille) — die letzte öffentliche Nachricht stammt von einem Spieler; der Support hat noch nicht geantwortet
  • Wartet auf Antwort (Sanduhr, Zeile abgedunkelt) — die letzte öffentliche Nachricht stammt vom Support; der Spieler hat noch nicht geantwortet

Standardmäßig wird nach Dringlichkeit sortiert, damit die auf das Team wartenden Tickets oben stehen. Die Sortierung lässt sich neben den Filtern umstellen, und die Filter für Teilnehmer, Bearbeiter und Status liegen im Filtermenü daneben; was aktiv ist, erscheint als entfernbarer Chip über der Liste. Jede Zeile trägt außerdem eine Altersmarkierung: wie lange das Ticket existiert und wie lange es im aktuellen Zustand wartet.

Anliegensarten​

Tickets -> Anliegensarten öffnet den Editor. Eine Anliegensart ist das, was ein Spieler wählt, bevor das Formular erscheint; das Formular macht aus „hi ich hab ein Problem“ eine vollständige Meldung. Die Mechanik hinter Vorlagen, Panels und Antwort-Snapshot steht im Ticket-Konzept.

Dein Server hat bereits eine Art namens Allgemein, die nach Betreff und Nachricht fragt. Bestandsserver wurden damit migriert, jeder neue Server startet damit — so kann der Shop ein Ticket annehmen, bevor überhaupt jemand diesen Editor öffnet, und ihr Formular samt Vorlagen bildet genau das ab, wie das Öffnen eines Tickets vor den Anliegensarten aussah. Ansonsten ist es eine gewöhnliche Art: umbenennen, Formular umbauen oder weitere Arten daneben anlegen.

Die Liste​

Jede Zeile zeigt Name, Anzahl der Formularfelder, Anzahl der Tickets, die sie schon nutzen, und in welchen Channels ihre Panels veröffentlicht sind. Zeilen lassen sich per Drag umsortieren; diese Reihenfolge sehen die Spieler im Shop.

Der Schalter Aktiv / Inaktiv ist die einzige Sichtbarkeitssteuerung. Discord regelt Zugriff bereits über Channel-Rechte, und eine zweite Schranke würde nur zur zweiten Wahrheit. Deaktivieren versteckt die Art im Shop und nimmt alle ihre Discord-Panels herunter; die bestehenden Tickets bleiben unberührt.

Die letzte verbleibende Art kann nicht gelöscht werden — der Shop hätte dann überhaupt keinen Weg mehr, ein Ticket zu öffnen. Alle zu deaktivieren ist möglich; der Shop sagt das dann ausdrücklich, statt auf ein generisches Formular zurückzufallen.

Der Editor​

  • Name und Beschreibung sind pro Sprache. Die Beschreibung ist das, was Spieler die richtige Art wählen lässt, also lohnt sie sich: sie erscheint in jedem Discord-Panel der Art und auf der Karte im Shop.
  • Willkommensnachricht wird als erste Support-Nachricht ins Ticket gepostet, noch vor der eigenen Nachricht des Spielers. Leer lassen für keine. Ersetzt die frühere serverweite Einstellung Ticket-Willkommensnachricht, die es nicht mehr gibt.
  • Support-Level schickt Tickets dieser Art direkt zu einem Team statt in die Eingangs-Warteschlange.
  • Formular: bis zu fünf Felder, je mit Typ, stabilem Schlüssel, Pflichtkennzeichen, Label, Hinweis und Platzhalter pro Sprache sowie typspezifischen Einstellungen (Längen, Dateianzahl, Auswahloptionen). Umsortieren per Drag.
  • Vorlagen: der erzeugte Betreff und die erste Nachricht, mit einer Übersicht der Platzhalter, die diese Art anbietet.
  • Panels: eine Bereitschaftsliste pro Sprache, die Channels, in denen die Art schon veröffentlicht ist, und eine Auswahl, um sie in einem weiteren zu veröffentlichen.

Der Schlüssel eines Feldes ist das, worauf {field:…} in den Vorlagen und die Discord-Komponente verweisen. Er wird aus dem englischen Label abgeleitet, solange das Feld neu ist, und wird schreibgeschützt, sobald Tickets die Art verwenden — ein Umbenennen würde dann stillschweigend Vorlage und erfasste Antworten abkoppeln.

Panels veröffentlichen​

Eine Art kann veröffentlicht werden, sobald sie mindestens ein Feld und eine vollständige Sprache hat. Die Bereitschaftsliste benennt pro Sprache, was fehlt — „warum gibt es keinen deutschen Button“ ist damit ohne Raten beantwortbar.

Das Panel steht zuerst in der Sprache des Servers: Titel, Beschreibung und der linke Button folgen der unter Einstellungen gesetzten Sprache, die weiteren vollständigen Sprachen kommen dahinter, jede unter einer Überschrift in ihrer eigenen Sprache.

Eine Art kann ein Panel pro Channel tragen, in so vielen Channels wie nötig — ein Support-Channel für registrierte Spieler und einer für Gäste bekommen beide ihren eigenen Button, und beide öffnen dasselbe Formular. Veröffentlichen in einem Channel, der schon ein Panel hat, ersetzt genau diese Nachricht; die Panels der anderen Channels bleiben, wo sie sind. Zum Verschieben veröffentliche das Panel im neuen Channel und entferne das alte aus der Liste.

Speichern aktualisiert jedes Panel der Art an seiner Stelle. Zwei Grenzen sind wichtig:

  • Discord kann Nachrichten nicht verschieben, also sortiert das Umsortieren der Liste die Panels im Channel nicht um. Panels neu aufbauen löscht alle Panels eines Channels und postet sie in der aktuellen Reihenfolge erneut — unten im Channel. Die Aktion fragt nach und sagt genau das.
  • Der Neuaufbau gilt für genau einen Channel. Die Panels einer Art in anderen Channels behalten ihren Platz, denn sie neu zu posten würde sie unten in einen Channel verschieben, nach dem niemand gefragt hat.

Fehlen dem Bot Rechte im gewählten Channel, scheitert das Veröffentlichen mit einer Warnung und sonst passiert nichts — die Ticket-Erstellung hängt nicht an Panels. Ein Speichervorgang, der das Panel eines Channels nicht aktualisieren kann, aktualisiert die übrigen trotzdem; ein einzelner falsch konfigurierter Channel friert die anderen also nie auf einem veralteten Formular ein.

Warteschlangen-Übersicht​

Die Warteschlange unterstützt diese Filter:

  • Status-Tabs
  • nicht zugewiesene Tickets
  • Tickets, die dem aktuellen Mitarbeiter zugewiesen sind
  • Teilnehmersuche
  • Bearbeiter-Suche
  • Anliegensart, inklusive der Option Keine Art für von Mitarbeitern, von der KI und vor der Einführung erstellte Tickets

Der Anliegensart-Filter und das Badge pro Zeile erscheinen erst, wenn der Server mehr als eine Art hat — bei einer einzigen würden sie nichts aussagen.

Verwende diese Filter, um Erstreaktion, zugewiesene Nachbearbeitung und spielerspezifische Untersuchungen zu trennen.

Teilnehmer- und Bearbeiter-Suche verwenden jeweils die Spielersuche. Gib mindestens zwei Zeichen ein, um die Warteschlange auf einen bestimmten Spieler einzugrenzen.

Mitarbeiter-Ticket erstellen​

Wenn admin.tickets.reply vergeben ist, können Mitarbeiter direkt aus der Warteschlange ein Ticket erstellen.

Das ist nützlich für:

  • internen Support-Follow-up
  • von Mitarbeitern gestartete Kontaktaufnahme
  • das Überführen von Discord-Support in einen nachverfolgbaren Ticketablauf

Von Mitarbeitern erstellte Tickets starten ohne Spieler-Teilnehmer, bis einer hinzugefügt wird.

Ticket-Detail​

Die Detailseite ist in drei Tabs aufgeteilt: Unterhaltung, Untersuchung und Prüfung.

Die Tabs Unterhaltung und Prüfung sind immer sichtbar. Der Tab Untersuchung wird nur bei aktiven Tickets (Offen oder In Bearbeitung) angezeigt und erfordert logs.view.

Tab Unterhaltung​

Kam das Ticket über ein Anliegensart-Formular herein, sitzt direkt über dem Nachrichtenverlauf eine Aufnahme-Karte, die jedes gefragte Feld und die Eingabe des Spielers zeigt — auch die leer gelassenen, grau als Gedankenstrich. Die Karte ist absichtlich redundant zur ersten Nachricht des Tickets: diese folgt einer vom Admin geschriebenen Vorlage, die Felder umsortieren, umformulieren oder auslassen kann, während die Karte die reine Aufnahme zeigt.

Die Karte ist in dieser Version schreibgeschützt — Anliegensart und erfasste Antworten eines Tickets lassen sich nirgends ändern — und nur im Admin sichtbar; der Spieler sieht seine eigenen Antworten schon als Eröffnungsnachricht. Von Mitarbeitern, von der KI und vor der Einführung erstellte Tickets zeigen gar keine Karte.

Der Tab Unterhaltung enthält den vollständigen Nachrichtenverlauf und die zentralen Ticket-Operationen:

  • öffentliche Antworten für spielersichtbare Kommunikation
  • interne Notizen für rein internen Kontext
  • Zuweisen und Entfernen von Bearbeitern
  • Teilnehmerverwaltung
  • Betreffbearbeitung
  • Statusänderungen
  • manueller Antwort-Wartestatus

Wichtige Abläufe:

  • die erste öffentliche Support-Antwort weist ein unzugewiesenes Ticket automatisch diesem Mitarbeiter zu
  • das Hinzufügen einer Fraktion übernimmt alle aktuellen Fraktionsmitglieder als Teilnehmer
  • interne Notizen bleiben privat in dzbot und geben ihren Inhalt nicht an Spieler weiter
  • jede Nachricht kann über das Anheften-Symbol angeheftet werden; angeheftete Nachrichten erscheinen im Tab Prüfung für einen schnellen Überblick

Antwort-Wartestatus

Mitarbeiter können den Antwort-Wartestatus aktiver Tickets manuell setzen, ohne eine Nachricht zu senden:

  • Wartet auf Support — markiert das Ticket als auf eine Mitarbeiterantwort wartend
  • Wartet auf Spieler — markiert das Ticket als auf die Antwort des Spielers wartend

Dieser Status steuert dasselbe Feld, das automatisch aktualisiert wird, wenn eine öffentliche Nachricht gesendet wird. Der manuelle Schalter ist nützlich, wenn intern an einem Ticket gearbeitet wird, ohne noch eine öffentliche Antwort zu senden, damit die Badges in der Warteschlange korrekt bleiben.

Erfordert admin.tickets.reply.

Tab Untersuchung​

Erfordert logs.view. Nur bei aktiven Tickets (Offen oder In Bearbeitung) sichtbar.

Bettet den Log-Explorer direkt in das Ticket ein, sodass Mitarbeiter In-Game-Ereignisse recherchieren können, ohne die Seite zu verlassen:

  • Logs nach Ereignistyp, Spieler, Koordinaten und Zeitraum filtern
  • die aktuelle Filterkonfiguration als benannte Abfrage am Ticket speichern
  • einzelne Log-Ereignisse mit einer optionalen Anmerkung anheften

Gespeicherte Abfragen und angeheftete Ereignisse werden am Ticket gespeichert und sind für Mitarbeiter ohne logs.view im Tab Prüfung sichtbar. Das Recht ist nur für das Ausführen neuer Abfragen und das Anheften neuer Ereignisse erforderlich.

Tab Prüfung​

Immer sichtbar. Sammelt alle gesammelten Beweise und Ergebnisse eines Tickets.

Verknüpfte Einschränkungen — erfordert restrictions.view. Zeigt alle mit diesem Ticket verknüpften Einschränkungen. Mitarbeiter mit restrictions.create können über Neue Einschränkung direkt aus dem Ticket eine Ereignis- oder Systemeinschränkung erstellen. Neue Einschränkungen öffnen sich in einem Seitenbereich, ohne die Seite zu verlassen.

Beweisdateien — am Ticket angehängte Dateien (Bilder, PDF, Video). Mitarbeiter mit admin.tickets.reply können über Beweisdatei hochladen weitere Dateien hinzufügen. Anhänge, die bei Antworten in der Unterhaltung hinzugefügt wurden, erscheinen ebenfalls hier.

Gespeicherte Abfragen — Filterkonfigurationen, die im Tab Untersuchung gespeichert wurden. Jede Abfrage kann erneut ausgeführt werden (erfordert logs.view), um aktuelle Ergebnisse in einem Modal anzuzeigen. Nicht mehr benötigte Abfragen können gelöscht werden.

Angeheftete Ereignisse — während der Untersuchung angeheftete Log-Ereignisse, angezeigt mit der bei der Anheftung hinzugefügten Anmerkung. Ereignisse können direkt in diesem Tab entfernt werden.

Angeheftete Nachrichten — Unterhaltungsnachrichten, die im Tab Unterhaltung mit dem Anheften-Symbol markiert wurden. Nachrichten können hier entfernt werden.

Verwandte Dokumentation​