Ce que votre métier calcule et que les autres ne calculent pas
La charge de support n’est pas proportionnelle au nombre de clients, elle est proportionnelle au nombre de questions déjà répondues ailleurs. Une part importante des tickets a une réponse écrite quelque part : dans la documentation, dans un ticket clos six mois plus tôt, dans un message d’un collègue. Le coût n’est pas de répondre, il est de retrouver — et ce coût est payé par la personne la plus chère disponible au moment où le client insiste.
Ensuite, le support d’un éditeur mélange deux natures de demandes que rien ne distingue à l’arrivée : celles qui relèvent de l’usage, et celles qui révèlent un défaut du produit. Les premières se règlent par une réponse, les secondes doivent devenir un élément de la feuille de route. Un outil de ticketing qui ne fait pas ce tri renvoie tout vers l’équipe technique et transforme les développeurs en première ligne.
Enfin, la version compte. La même question n’a pas la même réponse selon la version installée, l’option activée ou le mode de déploiement du client. Une base de connaissance qui ignore cette dimension produit des réponses justes en général et fausses en particulier, ce qui coûte plus cher qu’une absence de réponse.
Ce qui se contourne à la main chez la plupart des éditeurs
Rien d’exotique : ce sont les frottements normaux d’une équipe qui grandit plus vite que ses outils internes.
- La même question revient chaque semaine et reçoit une réponse réécrite chaque semaine.
- La connaissance utile est dans les tickets clos, où personne ne va la chercher.
- Un développeur est interrompu pour une question qui n’avait rien de technique.
- La documentation existe mais ne correspond plus à la version installée chez le client.
- Le client relance par mail parce qu’il n’a aucun moyen de voir où en est sa demande.
- Personne ne sait quelle fonctionnalité génère le plus de tickets.