Avant de recruter au support, regardez votre triage
Quand la file de tickets n’arrête pas de grossir, recruter paraît évident. C’est rarement la première chose à essayer.
Le scénario est connu. La file de tickets grossit plus vite que l’équipe. Les délais de réponse dérivent. Les meilleurs passent leurs journées sur des réinitialisations de mot de passe et des bugs signalés en double. Quelqu’un ouvre une demande de recrutement.
Parfois, c’est la bonne décision. Mais recruter dans un flux cassé, c’est surtout ajouter des personnes coincées dans le même flux. Et chacune met plus de temps à être opérationnelle. Avant d’ajouter de la capacité, ça vaut le coup de regarder où part la capacité actuelle.
Savoir ce qui arrive vraiment
Commencez par l’entrant. Prenez un échantillon représentatif de tickets récents (quelques centaines suffisent en général) et catégorisez-les à la main. Pas selon les tags choisis dans l’urgence par les agents : selon ce dont le client avait réellement besoin.
On cherche quelques signaux :
- Des questions récurrentes auxquelles une documentation, un texte dans le produit ou un meilleur message d’erreur pourrait répondre.
- Des bugs signalés de nombreuses fois par des clients différents, chacun traité comme un ticket séparé.
- Des tickets qui ne devraient pas exister : des demandes causées par un parcours confus, une option self-service manquante, ou une page de statut que personne ne met à jour.
- Du travail qui n’est pas du support : des demandes de fonctionnalités, des questions commerciales, des tâches d’engineering garées dans la file support.
Chacun libère de la capacité sans recruter personne.
Router dès le premier contact
Le deuxième endroit où la capacité fuit, c’est le routage. Si chaque ticket arrive dans une boîte partagée et est pris par qui est libre, vos profils les plus expérimentés traitent des tickets simples, et les tickets difficiles rebondissent jusqu’à ce qu’un senior s’en saisisse.
Un modèle à niveaux règle ça, à condition de rester simple :
| Niveau | Traite | Escalade quand |
|---|---|---|
| L1 | Questions connues, problèmes de compte, tout ce qui a une réponse documentée | La réponse n’est pas documentée, ou le problème demande une investigation |
| L2 | Investigation, reproduction, contournements, triage des bugs | Un changement de code ou d’infrastructure est nécessaire |
| Engineering | Corrections, avec un responsable clair par zone produit | Aucun |
Les règles qui comptent plus que les niveaux eux-mêmes : des critères d’escalade clairs, un responsable nommé côté engineering pour chaque zone, et une boucle de retour pour que chaque escalade qui aurait pu être résolue plus bas devienne de la documentation ou de la formation.
Rendre les passages à l’engineering peu coûteux
Les escalades vers l’engineering, c’est là que les tickets vont attendre. En général parce que le passage coûte cher des deux côtés : le support ne sait pas de quelles informations l’engineering a besoin, et l’engineering ne sait pas quelles escalades sont urgentes.
Mettez-vous d’accord sur un court modèle d’escalade : impact, étapes de reproduction, identifiants de compte ou de requête, ce qui a déjà été tenté. Fixez aussi une échelle de sévérité que les deux équipes utilisent de la même façon. Puis donnez aux escalades un SLA visible, pour que tout le monde voie combien de temps ça attend. Personne n’est sanctionné pour autant.
Ensuite, dimensionner l’équipe
Une fois l’entrant assaini et le routage en place, le dimensionnement devient une vraie question, avec de vraies données : volume par catégorie, temps de traitement par niveau, plages de couverture réellement nécessaires. C’est un modèle que vous pouvez défendre, plutôt qu’une impression que l’équipe se noie.
Parfois, la réponse reste « recruter ». Mais cette fois, on recrute dans un flux qui fonctionne, et la nouvelle personne peut faire le travail pour lequel elle a été embauchée.