​

Support-Kanäle und Meldungen

​

Allgemeiner Support

• Identifikationspflicht: Auch bei scheinbar banalen Fragen (z.B. “Wie ändere ich mein Passwort?”) musst du zur Absicherung immer den exakten Panel-Namen und die hinterlegte E-Mail-Adresse abfragen. Dies verhindert Social Engineering Versuche.
• Wissensdatenbank als Primärquelle: Bevor du Dustin oder Jannik direkt kontaktierst, musst du prüfen, ob das Anliegen bereits in den Dokumenten für Billing oder Technik abgedeckt ist. Ein Großteil der Fragen lässt sich durch aufmerksames Lesen dieser Docs sofort klären.
• Discord-Interaktion: Fragen zu Discord-Rängen, Server-Rollen oder allgemeinen Community-Themen werden nicht im Support-Ticket gelöst, sofern sie keine direkten Auswirkungen auf das Hosting haben. Verweise den Kunden freundlich auf die öffentlich einsehbaren Kanäle für das Regelwerk oder die FAQ.
• Umgang mit Unwissenheit: Wenn du die Antwort auf eine allgemeine Frage nicht kennst, rate niemals. Antworte stattdessen: “Ich informiere mich kurz über den aktuellen Stand zu diesem Thema und gebe dir sofort Rückmeldung.” Nutze die Zeit, um intern im Team-Chat nachzufragen.

​

Suggestions (Vorschläge)

• Trennung von Support und Feedback: Erkläre dem Kunden, dass Tickets primär für Probleme gedacht sind. Für allgemeine Vorschläge haben wir dedizierte Kanäle.
• Kanal-Verweis: Weise den Kunden darauf hin, dass Vorschläge im öffentlichen Feedback-Kanal gepostet werden sollten. Dies hat den Vorteil, dass andere Nutzer darüber abstimmen können, was Dustin und Jannik eine bessere Übersicht über die Wünsche der Community gibt.
• Dokumentationspflicht bei Ticket-Vorschlägen: Sollte ein Kunde darauf bestehen, seinen Vorschlag im Ticket zu lassen, notiere dir die Kernaspekte (Was soll geändert werden? Warum? Welchen Vorteil hat der Kunde davon?).
• Erwartungsmanagement: Gib niemals eine Zusage für die Umsetzung eines Features. Antworte neutral: “Vielen Dank für deine Idee. Ich habe die Details aufgenommen und leite sie zur Prüfung an Dustin und Jannik weiter. Ob und wann dies umgesetzt wird, entscheidet die Administration nach einer internen Analyse.”

​

User Reports (Meldungen)

• Strenge Beweispflicht: Ein Report ohne verwertbare Beweise wird umgehend abgelehnt. Der Kunde muss Beweise in Form von ungeschnittenen Videoclips, vollständigen Screenshots oder Log-Auszügen vorlegen.
• Datenerhebung:
  • Exakter Discord-Name und die eindeutige User-ID (via Entwicklermodus) des Beschuldigten.
  • Exakter Zeitpunkt des Vorfalls (Datum und Uhrzeit).
  • Eine sachliche Beschreibung des Verstoßes ohne emotionale Wertung durch den Support.
• Vertraulichkeitsgebot: Die Anonymität des Meldenden ist zu jedem Zeitpunkt zu wahren. Gib niemals Informationen über die Identität des Beschwerdeführers an den Beschuldigten weiter, um Racheaktionen oder weiteres Mobbing zu verhindern.
• Keine eigenmächtigen Sanktionen: Support-Mitarbeiter sprechen keine Banns oder Verwarnungen aufgrund von User-Reports aus. Nach der vollständigen Beweisaufnahme wird das Ticket intern an die Administration (Dustin/Jannik) eskaliert. Nur diese entscheiden über die Konsequenzen.

​

Bug-Reports (Fehlerberichte)

​

Detailliertes Severity-System (Schweregrade)

​

Standardisierter Ablauf der Fehleraufnahme

1. Exakte Fehlerbeschreibung: Was hat der Kunde getan und was ist genau passiert? (Fehlermeldung im Wortlaut anfordern).
2. Schritte zur Reproduktion: Erstelle eine Liste von Aktionen, die man nacheinander ausführen muss, um den Fehler erneut zu provozieren. Ein Fehler, der nicht reproduzierbar ist, kann nur schwer behoben werden.
3. Technische Umgebung: Welchen Browser nutzt der Kunde? (Chrome, Firefox, etc.). Tritt der Fehler auch nach dem Löschen des Cache oder im Inkognito-Modus auf?
4. Nachweise und Logs: Fordere Screenshots oder, falls der Fehler im Browser auftritt, einen Screenshot der “Console” (erreichbar über F12) an. Rote Fehlermeldungen in der Konsole sind für Dustin und Jannik extrem hilfreich.