Configurer un système de tickets Discord : ce qu'il faut régler avant le premier clic

Un système de tickets résout un problème concret : le support ne se fait plus dans des salons publics, où tout le monde lit et où personne n'est responsable, mais dans un salon privé entre la personne qui a un problème et ton équipe.

La partie technique prend dix minutes. Si les systèmes de tickets finissent pourtant souvent dans le chaos, cela tient à quatre décisions qu'il vaut mieux prendre à l'avance.

Décision 1 : combien de catégories

L'erreur la plus fréquente est de trop découper. Un serveur démarre avec huit catégories parce qu'elles semblent toutes logiques d'une manière ou d'une autre : Général, Technique, Candidature, Plainte, Partenariat, Bug, Achat, Autre.

Le résultat est prévisible. Les membres choisissent la mauvaise catégorie, ton équipe doit déplacer des tickets, et six des huit ne reçoivent de toute façon jamais rien.

Commence avec deux ou trois. Un bon découpage suit qui est responsable, pas le sujet :

• Support général pour tout ce à quoi répond ton équipe de support
• Candidatures pour tout ce que voit la direction de l'équipe
• Signalements pour tout ce que voit la modération

Si une catégorie déborde régulièrement au bout de trois mois, divise-la. L'inverse, retirer une catégorie morte, est plus désagréable, parce qu'il faut alors déplacer des tickets.

Décision 2 : ce que tu demandes à l'ouverture

La plupart des systèmes peuvent afficher un petit formulaire avant la création du ticket. Cela évite la première série de questions de suivi, mais ajoute de la friction.

La règle de base : ne demande que ce dont ton équipe a besoin pour commencer. Tout le reste ressort dans la conversation.

Bien :

De quoi s'agit-il ? (obligatoire, paragraphe) Qu'as-tu déjà essayé ? (facultatif, paragraphe)

Mal :

Nom, âge, heure, système d'exploitation, ID Discord, règlement lu (oui/non), lien de capture d'écran, urgence de 1 à 5

Discord autorise de toute façon au maximum cinq champs par formulaire. Utilise-en deux.

Décision 3 : qui voit quel ticket

C'est le point que tu regrettes sur le long terme si tu te trompes.

Un système de tickets attribue les permissions de salon par catégorie. La question n'est donc pas « qui fait partie de l'équipe » mais « qui a le droit de lire les candidatures ». Si ton équipe de support a accès à la catégorie des candidatures, quinze personnes lisent quand quelqu'un postule. C'est rarement voulu.

Définis les rôles par catégorie, pas globalement. Dans AlphaCloud, c'est le champ rôles de support de chaque catégorie de tickets.

Décision 4 : ce qu'il advient des tickets fermés

Un serveur avec un support actif produit vite des centaines de salons de tickets. Il y a trois approches habituelles :

Approche	Avantage	Inconvénient
Le salon reste, déplacé dans une catégorie d'archives	Tout reste lisible	Discord autorise au maximum 500 salons par serveur
Le salon est supprimé	Propre	L'historique est perdu
Le salon est supprimé, une transcription est créée d'abord	Les deux	Il faut un système qui sache le faire

La troisième est la bonne dès que ton support fonctionne régulièrement. Une transcription est une copie consultable de la conversation qui reste disponible longtemps après la disparition du salon. Tu en as besoin au plus tard lors de la première dispute sur ce qui aurait été promis dans un ticket.

AlphaCloud stocke les transcriptions sur leur propre site, pièces jointes comprises. L'important est que les pièces jointes soient enregistrées à la fermeture, parce que les liens d'images de Discord cessent de fonctionner une fois le salon supprimé.

La configuration elle-même

Une fois les quatre points réglés, le reste est de la mécanique :

1. Crée une catégorie Discord dans laquelle apparaîtront les salons de tickets
2. Crée les catégories dans le bot et définis les rôles de support
3. En option, une ou deux questions par catégorie
4. Publie un panneau dans un salon, depuis lequel les membres ouvrent leurs tickets
5. Définis un salon de logs

Ensuite, ouvre absolument un ticket toi-même et parcours-le une fois. C'est là que tu remarques que l'équipe ne voit pas du tout la nouvelle catégorie, ou que le message de bienvenue est encore le texte par défaut.

Deux choses qui valent la peine d'être ajoutées plus tard

Les évaluations. Après la fermeture, le système peut demander une note. C'est moins utile pour les statistiques que pour le cas où quelqu'un donne une étoile et écrit pourquoi. Ce retour, tu ne l'obtiens jamais autrement.

La fermeture automatique. Les tickets où personne n'a écrit depuis des jours encombrent la vue d'ensemble. Un minuteur qui ferme après 48 heures de silence, en demandant une fois avant, garde la liste propre sans que personne n'ait à faire le ménage.

Ce qu'un système de tickets ne résout pas

Il ne rend pas le support plus rapide. Il le rend seulement retrouvable, attribué et lisible après coup.

Si personne ne répond, aucun système n'aide. Ce qui aide : une notification à l'équipe quand un ticket s'ouvre, et une indication honnête dans le panneau sur le délai actuel. Les deux demandent nettement moins de travail que de s'excuser ensuite pour le silence.