Si votre équipe gère des demandes entrantes, que ce soient des tickets d’assistance client, des problèmes de service informatique, des révisions de contrats ou des approbations internes, vous avez probablement une idée informelle de ce à quoi ressemble un délai de réponse acceptable. Un problème critique nécessite une attention dans l’heure. Une question de facturation d’un client compte plus qu’une question générale. Un ticket arrivé hier matin et encore non traité est un problème.

Vous portez tout cela dans votre tête. Tout le monde dans l’équipe aussi. Le problème, c’est que lorsque cela n’existe que dans les têtes des gens, c’est invisible sur le tableau. Un ticket qui n’a pas reçu de réponse depuis quatre heures ressemble exactement à un ticket qui vient d’arriver. Vous devez lire chaque élément pour savoir ce qui est vraiment en feu. Des choses passent entre les mailles. Et quand quelque chose est manqué, la conversation est toujours la même : « Pourquoi personne n’a signalé ça plus tôt ? »

C’est ce que le suivi SLA est censé résoudre. Et la plupart des outils l’offrent techniquement. Mais le processus de configuration a toujours été ce qui empêche les équipes de l’utiliser réellement.

Le mur de configuration

Quand vous cherchez SLA dans un outil d’entreprise typique, vous trouvez un panneau de paramètres qui suppose que vous savez déjà ce que vous faites. Heures de bureau. Chaînes d’escalade. Matrices de priorité. Règles de violation personnalisées par niveau. Workflows de notification liés. C’est vraiment puissant si vous avez un administrateur IT dédié pour tout configurer, et vraiment inutilisable si vous n’en avez pas.

Donc la plupart des équipes l’ignorent. Elles utilisent des dates d’échéance et espèrent le meilleur. Certaines construisent le suivi dans des tableurs. D’autres abandonnent et font juste un check-in matinal pour voir ce qui a attendu trop longtemps, ce qui signifie ajouter une réunion à un problème qui devrait avoir une solution technique.

Nous voulions changer ça. Non pas en rendant la configuration plus facile. En éliminant la plupart d’entre elle.

Commencer avec un modèle, pas une page blanche

La première chose que nous avons construite était une bibliothèque de modèles SLA organisée par secteur et type d’équipe. Support IT, succès client, helpdesk RH, révision juridique, installations, ingénierie logicielle, et plus encore. Chaque modèle est préchargé avec les objectifs de réponse et de résolution standard pour ce type de travail. Première réponse dans l’heure pour les problèmes critiques, 4 heures pour la priorité haute, 24 heures pour la normale. Des chiffres qui correspondent aux attentes réelles plutôt que des chiffres que vous devez rechercher et justifier vous-même.

Vous choisissez le modèle le plus proche de votre situation, ajustez ce qui ne correspond pas, et vous avez terminé la configuration. Le tout prend quelques minutes.

Cela peut sembler peu de chose, mais cela supprime la plus grande barrière : la page blanche. La plupart des équipes ne sautent pas le SLA parce qu’elles n’en veulent pas. Elles le sautent parce que partir de zéro ressemble à un projet en soi.

Une colonne. Trois choses se produisent.

Voici la partie qui surprend encore les gens quand ils la voient pour la première fois.

Vous allez sur le tableau où vous voulez suivre le SLA. Vous ajoutez la colonne SLA. C’est tout.

Gript crée automatiquement trois colonnes liées : Statut (SLA), Priorité (SLA), et le minuteur SLA lui-même. Ils sont connectés entre eux et à votre modèle. Quand vous définissez la priorité d’un ticket sur Critique, le minuteur sait qu’il a une fenêtre de réponse d’1 heure. Quand quelqu’un change le statut en Attente de l’utilisateur, l’horloge se met en pause automatiquement. Quand le statut passe à Résolu, le minuteur s’arrête et le résultat est enregistré.

Vous ne configurez rien de tout cela. C’est intégré dans la relation entre les trois colonnes.

Ce que le tableau vous dit vraiment

Une fois la colonne SLA en marche, votre tableau communique d’une manière qu’il ne pouvait pas avant. Vous pouvez voir d’un coup d’oeil quels tickets sont nouveaux et non traités, lesquels attendent le client, et lesquels ont déjà dépassé leur fenêtre. La cellule SLA montre un minuteur en direct et une barre codée par couleur en bas. Foncé signifie que l’horloge tourne encore. Rouge signifie que la fenêtre est dépassée.

La colonne Priorité (SLA) gère la logique de l’objectif applicable. Un ticket critique (P1) a une fenêtre plus serrée qu’un ticket haute priorité (P2). Le même tableau peut gérer les deux en même temps, et le système fait la différence sans que vous fassiez quoi que ce soit de plus.

La colonne Statut (SLA) est séparée de votre statut de tâche habituel, et c’est intentionnel. Quand un ticket passe en Attente de l’utilisateur, l’horloge se met en pause. Ce temps ne devrait pas compter dans votre objectif de réponse. Quand il est Fermé, il est complètement hors de la file. Ces états ont une signification spécifique dans le contexte SLA, et les trois colonnes travaillent ensemble pour les suivre correctement.

Budget d’erreurs et Détecteur de Pastèque

Le budget d’erreurs vient de l’ingénierie de fiabilité des logiciels. Il représente la marge qu’il vous reste avant de manquer votre objectif SLA pour la période. Si vous vous engagez à résoudre 95% des tickets dans les délais et que vous êtes actuellement à 91,2%, votre budget d’erreurs vous indique combien de manques supplémentaires vous pouvez absorber avant de tomber en dessous de ce seuil. Les équipes avec un budget sain peuvent prendre plus de volume. Les équipes proches de zéro doivent soit ralentir soit ajouter de la capacité. La plupart des équipes n’ont pas de visibilité là-dessus jusqu’à ce qu’il soit trop tard. Nous le mettons en avant.

Le Détecteur de Pastèque est différent. Le nom vient d’une expression courante en business : vert à l’extérieur, rouge à l’intérieur. Une métrique pastèque est une où les chiffres ont l’air bien mais la réalité sous-jacente est différente.

Dans le contexte SLA, la situation pastèque classique est celle-ci : votre score montre 96% des tickets résolus dans les délais, mais votre satisfaction client est basse. Ce qui se passe généralement c’est que les équipes optimisent pour la métrique rapportée. Si la métrique est « avons-nous techniquement fermé ça en 4 heures », les gens trouvent des moyens de techniquement fermer les choses en 4 heures, même quand le problème réel n’est pas résolu.

Le Détecteur de Pastèque signale cet écart. Quand votre score SLA est élevé mais que les signaux de satisfaction sont bas, nous le signalons comme un avertissement. Pas comme une accusation, et pas comme une réponse définitive sur ce qui a mal tourné. Juste comme un signal qui mérite attention.

Pas pour les départements IT. Pour tout le monde.

Nous avons construit ça pour les équipes support d’abord, parce que c’est le cas d’usage évident. Mais certaines des équipes qui en ont le plus profité n’étaient pas du tout des équipes support.

Files de demandes IT internes. Révision de contrats juridiques. Workflows d’approbation financière. Partout où des demandes arrivent et où quelqu’un doit répondre dans un délai défini, le suivi SLA aide. Et parce que Gript vous permet de voir plusieurs tableaux ensemble sur la page analytique, vous pouvez voir comment le SLA se passe dans différentes équipes et projets depuis un seul endroit.

L’objectif n’a jamais été de construire quelque chose pour les spécialistes SLA. C’était de le faire fonctionner pour l’équipe qui sait qu’elle a besoin de suivi des délais de réponse, a regardé les outils existants, et a fermé l’onglet du navigateur. Choisissez un modèle, ajoutez une colonne, commencez à mesurer.

C’est tout.