Quand et comment transférer des tickets en seconde ligne ?

La gestion des incidents a tendance à devenir une tâche « nécessaire-mais-dont-on-se-passerait-bien ». Cependant, bien comprendre leur escalade (en langage ITIL : transfert d’un incident en seconde ligne) est très important et peut prévenir toute confusion dans le processus de gestion des incidents.

Puis-je résoudre ce ticket immédiatement ?

La première étape consiste à se demander « Suis-je capable de résoudre ceci moi-même ? » Si la réponse est « non », l’incident doit être transféré à quelqu’un d’autre.

Rassurez-vous : de nombreux outils permettent de répondre plus souvent à cette question par la positive. Par exemple, en implémentant et en tenant à jour une base de connaissances solide. L’idée c’est de réutiliser les réponses aux problèmes précédemment rencontrés, de partager le savoir et l’expérience de chacun, et, bien entendu, d’en donner l’accès aux autres membres de l’équipe (voire aux utilisateurs, ce qu’on appelle le Shift Left - lire notre articles sur le Shift Left. De ce fait, vous facilitez et accélérez la résolution des tickets sans devoir escalader quoique ce soit puisque même s’ils ne connaissent pas la solution, vos collègues peuvent aller puiser dans cette formidable base de données.

Partager votre savoir avec les autres évite d’escalader trop de tickets tout en augmentant le taux de résolution de problèmes. C’est déplacer le processus vers la gauche (Shift Left).

Jaugez correctement le transfert en seconde ligne

Il est également important de comprendre à qui doit être transféré l’incident. Généralement, il existe deux façons de procéder : hiérarchiquement, quand les incidents sont transférés à des supérieurs. Par exemple, quand l’incident semble représenter plus de travail que cela en a l’air, ou si certains aspects de l’incidents doivent être approuvés. Et l’escalade fonctionnelle, quand on transmet l’incident à une personne ou une équipe qui a les compétences adéquates et les connaissances nécessaires.

Dans certains outils, comme TOPdesk, on peut diviser l’incident en différentes parties afin de transférer uniquement celles qui nécessitent plus d’expertises à l’équipe compétente.

Évaluez l’impact et l’urgence clairement

Il faut également garder à l’esprit l’impact et l’urgence de l’incident. Si c’est très urgent et que la base de connaissances n’offre pas assez d’éléments pour résoudre le problème, il vaut probablement mieux laisser quelqu’un d’autre s’en charger.
Vous avez peut-être déjà entendu parler des matrices de priorités dans vos cours sur ITIL. Celles-ci permettre d’évaluer l’impact et l’urgence d’un incident afin que celui-ci soit priorisé correctement.

Faites attention de ne pas utiliser de termes trop génériques, qui peuvent porter à confusion, et donc mener à une mauvaise priorisation dans votre logiciel de service management. Soyez précis. Pour l’impact : qui est affecté ? Toute la société ? Un seul site ? Un seul département ? Un seul utilisateur ? Pour les urgences : les personnes concernées peuvent-elles encore travailler ? Partiellement ? Pas du tout ? Les termes précis permettent de mieux savoir ce que vous devez faire et quand.

Enfin, je voudrais insister sur le fait que si vous devez absolument transférer un incident, la personne qui le reçoit n’ai pas à refaire le travail de déchiffrage que vous avez fait la première fois : assurez-vous qu’elle reçoive assez d’infos et de documents pour comprendre rapidement de quoi il s’agit et perdre le moins de temps possible.

Tirez davantage profit de vos processus ITSM

Apprenez-en davantage et mariez les pratiques classiques ITIL aux processus ITSM à l’aide d’une approche centrée sur le client dans notre e-book Best Practice Service Management.