Intro : La classification automatique des tickets réduit le tri si les catégories restent actionnables et si les cas ambigus sont revus.
Un ticket support contient souvent un symptôme, un produit et une urgence exprimée de façon différente. Une IA peut proposer une catégorie, une équipe et une priorité. Elle doit conserver le texte d’origine et permettre une correction rapide.
Définir les catégories
Chaque catégorie doit conduire à une action. « Accès », « facturation » et « incident technique » sont plus utiles que des thèmes généraux. Écrivez des exemples et des exclusions pour chaque classe.
Ajoutez une file de revue pour les messages qui combinent plusieurs sujets. Forcer une seule catégorie crée des erreurs silencieuses. Le motif de la revue doit être visible.
Préparer les données
Nettoyez les doublons de tickets et séparez les messages automatiques des demandes réelles. Les exemples doivent couvrir les langues, les signatures et les formulations courantes de l’équipe. Retirez les données inutiles avant les tests.
Conservez un jeu de contrôle séparé. Il sert à vérifier les règles après une modification et évite de mesurer le système uniquement sur les exemples qui ont servi à le régler.
Séparer tri et action
Le classifieur peut proposer une file, mais il ne doit pas modifier un abonnement ou envoyer une réponse sans contrôle. Les droits du compte doivent rester limités à la lecture et à la création d’une tâche de tri.
Une action externe passe par une étape distincte. L’agent voit la catégorie proposée, la source, les règles déclenchées et l’action qui suivra. Une approbation est nécessaire pour les cas sensibles.
Mesurer
Mesurez la précision par catégorie, le taux de revue, le temps de tri et les tickets mal orientés. Un bon score général peut cacher une catégorie critique très faible.
Analysez les corrections répétées. Elles indiquent souvent une définition trop large, un exemple absent ou un changement dans le produit. Modifiez une règle à la fois et comparez avec le jeu de contrôle.
Respecter les accès
Les tickets peuvent contenir des coordonnées, des captures ou des informations contractuelles. La recherche et les journaux doivent appliquer les droits de l’équipe. Microsoft documente l’importance du filtrage au niveau du document pour limiter les résultats aux utilisateurs autorisés dans son guide d’accès.
Définissez une durée de conservation pour les textes et les pièces jointes. Les métriques agrégées peuvent rester plus longtemps que le contenu détaillé.
Une classification utile rend la file plus claire et laisse les décisions importantes à l’équipe. Les catégories, les exemples et la revue des exceptions doivent évoluer ensemble.
Sources
+Une revue mensuelle compare les tickets classés avec les réponses effectivement apportées. Elle montre si deux catégories demandent finalement la même action ou si une file reçoit des demandes qui devraient être orientées ailleurs. Le responsable peut simplifier la taxonomie au lieu d’ajouter une nouvelle classe à chaque cas particulier. Les changements sont testés sur des tickets conservés à cette fin.
Les indicateurs doivent distinguer le temps de tri et le temps de résolution. La classification peut être correcte alors que la file manque de capacité. Cette séparation évite de corriger le modèle pour un problème d’organisation. +## Mettre en place la revue
La première semaine, faites fonctionner le classement en mode suggestion. Le ticket reste dans sa file habituelle et l’équipe compare la proposition avec la destination qu’elle aurait choisie. Notez les erreurs de catégorie, de priorité et d’équipe séparément. Cette distinction évite de modifier le modèle alors que le problème vient parfois de la liste des files.
Les catégories doivent rester stables pendant la mesure. Si plusieurs personnes changent leurs noms ou leurs définitions en même temps, les résultats deviennent difficiles à comparer. Organisez une courte revue avec le support et le responsable du produit. Ils peuvent décider qu’une catégorie doit être séparée, fusionnée ou supprimée.
Prévoyez un traitement des tickets qui demandent plusieurs équipes. Une file principale peut garder la responsabilité tandis que des sous-tâches sont créées après validation. Le système conserve les liens entre le ticket parent et les tâches, afin que la réponse au client reste coordonnée.
Protéger la continuité
Une panne du service de classification ne doit pas bloquer la réception. Les tickets continuent d’être enregistrés et rejoignent une file manuelle. Lorsque le service revient, le workflow traite seulement les tickets encore sans catégorie.
Les responsables doivent pouvoir désactiver une règle ou revenir à la version précédente. L’historique indique la version qui a classé chaque ticket. Cette information rend les corrections possibles sans perdre le contexte de l’incident.
+Ajoutez une revue hebdomadaire des tickets mal classés. Le responsable compare la demande originale, la catégorie proposée et la file réellement choisie. Il peut modifier la définition d’une catégorie ou ajouter un exemple. Les changements sont versionnés et testés avant publication.
Conservez aussi les tickets qui ont été réassignés plusieurs fois. Ils signalent une frontière mal définie entre équipes. Une règle d’escalade peut alors compléter la classification et éviter des transferts répétés.