Le coût du tri manuel
Dans la plupart des services support, la première action sur une demande entrante n'est pas de la résoudre : c'est de la lire, de comprendre de quoi elle parle, de décider si elle est urgente, et de l'envoyer à la bonne personne. Cette opération ne produit aucune valeur pour le client, et elle occupe une part significative du temps de niveau 1.
S'y ajoutent les doublons, la même panne signalée par trois personnes, et les demandes mal orientées, qui font un aller-retour complet avant d'atterrir au bon endroit.
Ce que fait le système sur chaque demande entrante
- Catégorisation selon votre propre arborescence, pas une taxonomie générique.
- Estimation de la priorité à partir du contenu, du contrat client et de l'historique de l'équipement ou du compte concerné.
- Routage vers l'équipe ou la file compétente.
- Détection des doublons et rattachement à un incident déjà ouvert.
- Extraction des informations manquantes : si la demande n'a pas de numéro de série ou de version, le système le signale avant que quelqu'un n'ouvre le ticket.
- Proposition de réponse lorsque des tickets similaires ont déjà été résolus, avec le lien vers ces tickets.
Le technicien garde la main : le système propose, il ne ferme rien tout seul. C'est un choix de conception, pas une limite technique : un routage automatique erroné et silencieux coûte plus cher que le tri manuel qu'il remplace.
Intégration aux outils déjà en place
Le système se branche sur l'outil de gestion de tickets que vous utilisez déjà. Aucune migration n'est nécessaire, et c'est une condition que nous posons : un projet qui suppose de changer d'outil de ticketing n'est plus un projet d'automatisation, c'est un projet de refonte.
Nous intervenons couramment sur les outils de gestion de services les plus répandus en France, y compris les solutions libres largement déployées dans les PME et les ESN, ainsi que sur les suites commerciales et les boîtes mail partagées qui font encore office de file d'attente dans beaucoup d'organisations.
L'intégration se fait par les interfaces de programmation existantes, en lecture et en écriture d'attributs. Rien n'est modifié dans la base de l'outil.
Ce que le tri automatique ne fait pas
- Il ne résout pas les tickets. Il les prépare. La déflexion, c'est-à-dire répondre à la place d'un humain, est une décision distincte, qui suppose une campagne de mesure sévère avant d'être activée.
- Il ne corrige pas une arborescence de catégories incohérente. Si vos catégories se recouvrent, il reproduira le flou. C'est un sujet de cadrage.
- Il ne remplace pas le niveau 1. Il lui retire la partie mécanique de son travail.
Comment on sait que ça marche
Comme pour toute livraison, le système est remis avec sa campagne de mesure. Sur du tri, elle porte sur un échantillon de tickets réels déjà traités, dont on connaît la catégorie, la priorité et l'équipe finales.
Le rapport donne le taux de catégorisation correcte, le taux de routage correct, le taux de doublons détectés, et surtout la liste des erreurs. Un mauvais routage sur une catégorie sensible se traite en restreignant le périmètre, pas en espérant que ça s'arrange.
Questions fréquentes
Faut-il changer d'outil de ticketing ?
Non, et nous refusons les projets qui l'exigeraient. Le système se branche par les interfaces de programmation de l'outil que vous utilisez déjà, en lecture et en écriture d'attributs, sans modifier sa base.
Le système peut-il répondre au client à notre place ?
Techniquement oui, mais ce n'est pas ce que nous recommandons en premier déploiement. La réponse automatique suppose un taux d'exactitude mesuré et élevé sur la catégorie concernée. On commence par le tri, on mesure, puis on ouvre la réponse automatique sur les seules catégories où les chiffres le permettent.
Combien de tickets faut-il pour que ce soit rentable ?
L'ordre de grandeur se situe autour de quelques dizaines de demandes par jour. En dessous, le temps de tri manuel reste inférieur au coût du projet, et nous vous le dirons au cadrage.
Que se passe-t-il si le système se trompe de catégorie ?
Le ticket part au mauvais endroit et quelqu'un le réoriente, exactement comme aujourd'hui. C'est pourquoi le système propose sans fermer, et pourquoi le taux d'erreur par catégorie est mesuré et remis avant la mise en service.