Qu'est-ce que le délai de résolution ?

Le délai de résolution (TTR) ou le délai moyen de résolution (MTTR) fait référence à la durée moyenne nécessaire pour résoudre un cas ou un ticket de service client une fois qu'il a été ouvert. Lorsqu'un client ou un utilisateur contacte votre équipe en raison d'un problème qu'il rencontre avec votre service, il est important de minimiser le MTTR afin de garantir la meilleure expérience possible avec un temps d'arrêt minimal. Par exemple, supposons qu'un client appelle pour signaler un problème qu'il rencontre avec votre produit. L'horloge TTR démarre dès que cette interaction a lieu et s'arrête une fois qu'une résolution a été trouvée. Plus le délai de résolution est court, plus le client est satisfait.
Le TTR peut être calculé pour différents employés et différentes catégories d'incidents afin de montrer les tendances ainsi que les éventuels domaines d'amélioration. L'objectif doit toujours être de minimiser le temps nécessaire à la résolution d'un problème afin que les clients puissent utiliser correctement votre service avec le moins de perturbations possible.

« Comment pouvons-nous réduire le temps de résolution des incidents ? Nos chiffres MTTR nous font baisser ! »

Si vous vous posez cette question à cor et à cri, vous n'êtes pas le seul. Il s'agit d'un problème de support chronique. Comment réduire le temps de résolution des incidents ? Il s'avère qu'il existe des mesures très efficaces et très judicieuses que vous pouvez prendre. Nous allons les examiner dans cet article.

Des mesures, des mesures, des mesures

Tout d’abord, il est important de comprendre la manière dont les mesures sont utilisées pour évaluer la résolution des incidents et de décider quels aspects de ces mesures comptent le plus pour vous.

La mesure la plus basique du temps de résolution est bien sûr MTTR (temps moyen de résolution) C'est l'une de ces mesures que la haute direction a tendance à apprécier parce qu'elle condense tout en un chiffre simple et agréable. Malheureusement, c'est aussi l'un de ces chiffres qui peuvent s'avérer être aussi simple, en extrayant les informations importantes et en ne laissant qu'une moyenne presque dénuée de sens.

Le MTTR global (qui couvre la réponse à tous les incidents) est une mesure fiable si les données ne sont pas influencées par trop de valeurs aberrantes et si elles sont basées sur un large spectre d'incidents qui s'inscrivent parfaitement dans une courbe en forme de cloche. En revanche, s'il existe deux ensembles distincts d'incidents, représentant deux types de problèmes différents avec des temps de résolution très différents, le MTTR peut être trompeur. Étant donné que les courbes larges en forme de cloche incluent souvent des valeurs aberrantes anormales, le MTTR global à l'échelle du système peut ne pas être une bonne mesure du tout.

Si vous avez le choix en matière de mesures, quelles sont les alternatives au MTTR global ? Voici quelques recommandations :

• Des MTTR distincts pour chaque classe d'incident : Si vous pouvez définir des classes spécifiques d'incidents, vous pouvez utiliser des MTTR distincts pour chaque classe. Cela peut être très utile si les incidents concernés se divisent naturellement en classes distinctes. Mais ne cédez pas à la tentation de concevoir des classes d'incidents artificiellement juste pour pouvoir disposer de bons chiffres MTTR à présenter lors de la prochaine réunion.
• Pourcentage résolu : Vous pouvez également consulter le pourcentage de problèmes résolus dans un délai donné ou le pourcentage de problèmes non résolus après un délai défini. Cela vous permet de mesurer le temps de résolution par rapport à un objectif et d'ajuster les pratiques de gestion des incidents afin d'atteindre cet objectif.
• Nombre total d'incidents et durée cumulée des incidents : Pour que les chiffres du MTTR ou du délai de résolution cible aient un sens, vous devez prendre en compte le nombre total d'incidents et le temps cumulé des incidents pour une période donnée. Pourquoi ? Examinons le tableau A ci-dessous. Vous avez deux services informatiques différents qui surveillent et mesurent les incidents de la même manière. En se basant strictement sur le pourcentage d'incidents dépassant le temps cible et le MTTR, le service informatique B est clairement le gagnant. Si vous ne prenez pas en compte le nombre total d'incidents réels et les temps cumulés, il est trop facile de se retrouver à comparer des statistiques erronées.

Tableau A : Gestion des incidents et MTTR

Gardez vos chiffres bas

Quelle que soit la manière dont vous mesurez le temps de résolution, la seule constante est la nécessité (généralement accompagnée de pressions de la part de la haute direction) de maintenir ce délai à un niveau bas. Que pouvez-vous faire ?

Il existe plusieurs mesures que vous pouvez prendre et qui, mises en œuvre ensemble, peuvent avoir un impact positif. Vous trouverez ci-dessous six mesures essentielles que vous devez commencer à mettre en œuvre dès maintenant :

1. Utilisez un système de gestion des incidents rapide et précis.
   Une réponse commence par votre système de gestion des incidents. Comment votre équipe d'intervention reçoit-elle les alertes ? Reçoit-elle des appels téléphoniques et des messages électroniques des utilisateurs finaux pendant les heures normales de bureau ? Ce type de système convient aux problèmes de faible priorité et aux demandes de fonctionnalités. Vous avez besoin d'un système d'incident automatisé qui avertira immédiatement les responsables de l'équipe d'intervention appropriés en utilisant des options de communication globales multicanaux (appels téléphoniques, SMS, e-mail ou tout autre système de communication à réponse rapide) lorsqu'un incident est détecté ou signalé. Les incidents doivent être acheminés vers les responsables d'équipe appropriés pour éviter toute confusion ou tout malentendu sur la personne responsable de la gestion de l'incident.
2. Réduisez le bruit des alertes et filtrez les non-alertes.
   Filtrez et limitez le bruit des alertes dès le début, afin que les équipes d'intervention ne soient pas accablées par des incidents de faible priorité ou, pire encore, par des incidents non prioritaires qui n'ont pas été filtrés avant l'intervention. Ces fonctions doivent être intégrées à votre système d'alerte et de répartition et, dans une large mesure, elles peuvent être automatisées.
3. Gardez les délais d’accusé de réception des incidents courts.
   Cela implique à la fois le système d'alerte et les équipes d'intervention. Si aucun accusé de réception n'est émis après un délai défini (et très court), l'incident doit automatiquement être transmis à un deuxième membre de l'équipe, puis à un troisième, etc. Si aucun membre de l'équipe n'a reconnu l'incident, celui-ci doit être transmis à une deuxième équipe (ou à la direction informatique). Les incidents ne doivent pas être laissés en suspens indéfiniment, sans accusé de réception.
4. Établissez des priorités dès le départ .
   Définissez clairement les priorités en fonction de facteurs tels que la gravité et l'étendue de l'incident, les systèmes affectés et leur impact sur les opérations de l'entreprise. Cela peut avoir un effet mitigé sur votre MTTR, mais si vous commencez par une compréhension claire des incidents qui nécessitent le plus d'attention et de ceux qui peuvent attendre, vous réduirez le temps perdu et, en fin de compte, le temps de résolution.
5. Utilisez la collaboration en temps réel.
   Faites appel à des équipes spécialisées et à des ressources d'assistance à des moments cruciaux de la résolution d'un incident si nécessaire. Une collaboration en temps réel sur les supports appropriés (qui peuvent inclure un VPN et une vidéo en direct, ainsi que du texte et de la voix) peut faire la différence entre une résolution rapide et immédiate et l'attente d'un message électronique le jour ouvrable suivant.
6. Mettre en place des équipes d’intervention avec des rôles clairs.
   La réponse aux incidents ne doit jamais être ponctuelle. Chaque équipe doit avoir un responsable et tous les membres de l'équipe doivent être au clair sur les responsabilités de chacun. La communication, à la fois au sein de l'équipe et entre les parties prenantes extérieures à l'équipe, doit être claire et ouverte.

Il existe de nombreuses autres mesures que vous pouvez mettre en œuvre pour réduire le temps de réponse. Par exemple, pour les grandes organisations, un système de commandement formel avec des exercices d'intervention peut être approprié. En suivant les directives énumérées ci-dessus, vous devriez toutefois être en mesure de réduire les temps de réponse de votre équipe informatique à un niveau qui ne vous fera pas crier au ciel.