Een Discord ticketsysteem instellen: wat je regelt voor de eerste klik

Een ticketsysteem lost één concreet probleem op: support gebeurt niet meer in openbare kanalen, waar iedereen meeleest en niemand verantwoordelijk is, maar in een privékanaal tussen de persoon met het probleem en je team.

Het technische deel kost tien minuten. Dat ticketsystemen toch vaak in chaos eindigen, komt neer op vier beslissingen die je het best vooraf neemt.

Beslissing 1: hoeveel categorieën

De meest gemaakte fout is te fijn opsplitsen. Een server begint met acht categorieën, omdat ze allemaal op de een of andere manier zinnig klinken: Algemeen, Technisch, Aanmelding, Klacht, Partnerschap, Bug, Aankoop, Overig.

Het resultaat is voorspelbaar. Leden kiezen de verkeerde categorie, je team moet tickets verplaatsen, en zes van de acht krijgen toch nooit iets binnen.

Begin met twee of drie. Een goede indeling volgt wie verantwoordelijk is, niet waar het over gaat:

• Algemene support voor alles wat je supportteam beantwoordt
• Aanmeldingen voor alles wat de teamleiding ziet
• Meldingen voor alles wat de moderatie ziet

Loopt een categorie na drie maanden regelmatig over, splits hem dan op. De andere richting, een dode categorie opheffen, is onaangenamer, omdat je dan tickets moet verplaatsen.

Beslissing 2: wat je bij het openen vraagt

De meeste systemen kunnen een klein formulier tonen voordat het ticket wordt aangemaakt. Dat bespaart de eerste ronde vervolgvragen, maar voegt drempel toe.

De vuistregel: vraag alleen wat je team nodig heeft om te beginnen. Al het andere komt in het gesprek wel naar boven.

Goed:

Waar gaat het om? (verplicht, alinea) Wat heb je al geprobeerd? (optioneel, alinea)

Slecht:

Naam, leeftijd, tijdstip, besturingssysteem, Discord ID, regels gelezen (ja/nee), link naar screenshot, urgentie van 1 tot 5

Discord staat sowieso maximaal vijf velden per formulier toe. Gebruik er twee.

Beslissing 3: wie welk ticket ziet

Dit is het punt waar je op lange termijn spijt van hebt als je het fout doet.

Een ticketsysteem kent kanaalmachtigingen toe per categorie. De vraag is dus niet "wie zit in het team", maar "wie mag aanmeldingen lezen". Heeft je supportteam toegang tot de categorie voor aanmeldingen, dan lezen vijftien mensen mee als iemand zich aanmeldt. Dat is zelden de bedoeling.

Stel de rollen per categorie in, niet globaal. In AlphaCloud is dat het veld supportrollen in elke ticketcategorie.

Beslissing 4: wat er met gesloten tickets gebeurt

Een server met actieve support produceert snel honderden ticketkanalen. Er zijn drie gebruikelijke aanpakken:

Aanpak	Voordeel	Nadeel
Kanaal blijft, verplaatst naar een archiefcategorie	Alles leesbaar	Discord staat maximaal 500 kanalen per server toe
Kanaal wordt verwijderd	Overzichtelijk	De geschiedenis is weg
Kanaal wordt verwijderd, eerst wordt een transcript gemaakt	Allebei	Vraagt een systeem dat het kan

De derde is de juiste zodra je support regelmatig draait. Een transcript is een doorzoekbare kopie van het gesprek die er nog lang is nadat het kanaal weg is. Je hebt hem uiterlijk nodig bij de eerste discussie over wat er in een ticket zogenaamd beloofd is.

AlphaCloud slaat transcripts op een eigen site op, bijlagen inbegrepen. Belangrijk is dat bijlagen bij het sluiten worden opgeslagen, omdat de afbeeldingslinks van Discord niet meer werken zodra het kanaal is verwijderd.

Het instellen zelf

Als de vier punten geregeld zijn, is de rest mechaniek:

1. Maak een Discord categorie aan waarin de ticketkanalen verschijnen
2. Maak de categorieën aan in de bot en stel de supportrollen in
3. Optioneel één of twee vragen per categorie
4. Plaats een panel in een kanaal waar leden vanuit openen
5. Stel een logkanaal in

Daarna in elk geval zelf een ticket openen en het één keer doorlopen. Daar merk je dat het team de nieuwe categorie helemaal niet kan zien, of dat het welkomstbericht nog de opvultekst is.

Twee dingen die het later toevoegen waard zijn

Beoordelingen. Na het sluiten kan het systeem om een beoordeling vragen. Dat is minder nuttig voor de statistiek dan voor dat ene geval waarin iemand één ster geeft en schrijft waarom. Die feedback krijg je anders nooit.

Automatisch sluiten. Tickets waarin al dagen niemand heeft geschreven, verstoppen het overzicht. Een timer die na 48 uur stilte sluit, en vooraf één keer vraagt, houdt de lijst schoon zonder dat iemand hoeft op te ruimen.

Wat een ticketsysteem niet oplost

Het maakt support niet sneller. Het maakt support alleen vindbaar, toegewezen en achteraf leesbaar.

Als niemand antwoordt, helpt geen enkel systeem. Wat wel helpt: een melding aan het team als er een ticket opengaat, en een eerlijke opmerking in het panel over hoe lang het momenteel duurt. Beide zijn flink minder werk dan achteraf je excuses aanbieden voor stilte.