Deskhero
Français
Essayer gratuitement

← Back to articles

Automatiser les rappels SLA avant les dépassements

Automatiser les rappels SLA avant les dépassements

Les rappels automatisés de SLA doivent faire apparaître un ticket alors qu’il est encore temps d’agir, puis rendre un ticket en retard impossible à manquer. La configuration appropriée dépend du service d’assistance. Certaines plateformes proposent des alertes natives de proximité d’échéance et de violation, tandis qu’un workflow personnalisé peut nécessiter des vérifications planifiées et des étapes d’escalade explicites.

Commencez par l’horloge, pas par la notification :

  • Définissez des objectifs distincts pour la première réponse et la résolution.
  • Décidez si les objectifs utilisent le temps calendaire ou les heures ouvrées.
  • Choisissez les statuts de ticket qui mettent en pause l’horloge de résolution.

Conseil de pro : Testez chaque état de SLA avec des tickets d’exemple avant de vous fier aux alertes en production. Incluez des cas proches de l’échéance, en violation, en pause, réassignés et déjà terminés.

Points clés à retenir

Des rappels fiables commencent par des échéances précises. Le moment des alertes, leurs destinataires et les procédures d’escalade viennent après la validation de la politique elle-même.

Point Détails
Définir les deux horloges Suivez séparément la première réponse et la résolution, car elles se terminent lors d’événements différents.
Respecter le temps de travail Utilisez un calendrier professionnel lorsque les nuits et les week-ends ne doivent pas être comptabilisés dans l’objectif.
Configurer les statuts de pause Mettez en pause l’objectif de résolution lorsque le ticket attend une réponse du client ou d’une autre partie externe.
Choisir soigneusement les destinataires Assurez-vous que les alertes de proximité d’échéance et de violation parviennent à une personne capable d’agir sur le ticket.
Tester avant le déploiement Vérifiez les échéances, le comportement des pauses et la distribution des notifications avec des tickets contrôlés.
Utiliser d’abord les fonctionnalités SLA natives Un service d’assistance doté de politiques, calendriers professionnels, alertes, filtres et rapports intégrés évite un workflow d’interrogation distinct.

Documents de référence et guides à consulter ensuite

Pour un exemple propre à une plateforme, consultez la documentation de Jira sur les suivis automatisés. Elle décrit à la fois les règles planifiées et une approche fondée sur les seuils de SLA, avec notamment la recommandation de tester d’abord sur un périmètre de recherche réduit avant de l’élargir.

Table des matières

Créer une automatisation de rappels SLA étape par étape

Notez précisément ce que mesure chaque SLA avant de configurer une alerte. Un objectif de première réponse et un objectif de résolution correspondent à deux horloges différentes. Décidez quel événement de ticket démarre chaque horloge, quel événement la termine et si l’échéance suit le temps calendaire ou un calendrier professionnel.

Configurez ensuite le parcours du rappel.

  1. Définissez la politique. Associez les groupes et les priorités aux objectifs de première réponse et de résolution. Prévoyez une politique générale pour les tickets qui ne correspondent à aucune règle plus spécifique.
  2. Définissez le calendrier de travail. Ajoutez les heures d’ouverture et le fuseau horaire qui s’appliquent à l’objectif. Si l’engagement est continu, utilisez le temps calendaire.
  3. Configurez le comportement des pauses. Sélectionnez les statuts qui arrêtent l’horloge de résolution lorsque l’équipe attend des informations. Vérifiez si l’horloge de première réponse peut être mise en pause, car de nombreux systèmes la traitent différemment.
  4. Activez les notifications. Décidez qui reçoit les états de proximité d’échéance et de violation, ainsi que les canaux pris en charge par le service d’assistance.
  5. Ajoutez une réponse opérationnelle. Documentez ce que le destinataire doit faire, par exemple répondre, modifier la priorité, réassigner le ticket ou solliciter un responsable. La notification et l’action corrective ne doivent pas nécessairement relever de la même règle technique.

Si le service d’assistance ne propose pas de seuils SLA natifs, un workflow planifié peut examiner les tickets ouverts et comparer leurs échéances à l’heure actuelle. Un exemple d’interrogation toutes les 15 minutes est documenté par LOW/CODE, mais l’intervalle approprié dépend de l’objectif le plus court, des limites de l’API, des heures ouvrées et du délai que l’équipe peut tolérer. Enregistrez un état d’alerte afin que les exécutions suivantes ne renvoient pas la même notification.

Choisir des seuils qui n’entraînent pas une fatigue liée aux alertes

Un avertissement utile laisse au destinataire suffisamment de temps pour répondre. Un seuil en pourcentage peut fonctionner dans un système personnalisé, mais une fenêtre d’avertissement fixe est souvent plus facile à comprendre entre des politiques de durées différentes.

  • Dans les temps avec marge : Gardez le ticket visible dans les vues normales de la file sans envoyer d’avertissement.
  • Échéance imminente : Prévenez l’utilisateur ou le groupe responsable tant que l’objectif peut encore être respecté.
  • Violation : Marquez le ticket comme étant en retard et suivez le processus d’escalade documenté par l’équipe.

Ne copiez pas un seuil universel de 80 % sans vérifier les objectifs sous-jacents. Pour un objectif d’une heure, il ne laisse que 12 minutes, tandis que pour un objectif de trois jours, il laisse plus d’une demi-journée. Mesurez le temps d’action dont l’équipe a réellement besoin.

Les rappels répétés créent rapidement du bruit. Les alertes natives du service d’assistance doivent notifier lors d’un changement d’état plutôt qu’à chaque actualisation d’écran. Un workflow d’interrogation personnalisé doit enregistrer l’envoi de la notification de proximité d’échéance ou de violation et ne réinitialiser cet état que lorsque la politique redémarre réellement.

Choisir des seuils qui n’entraînent pas une fatigue liée aux alertes : schéma général

Ce que les alertes SLA doivent dire et où elles doivent être envoyées

Une alerte doit identifier le ticket, afficher l’échéance et rendre la réponse attendue claire. Évitez d’ajouter des données client dont le destinataire n’a pas besoin.

  • ID et lien du ticket afin que le destinataire puisse ouvrir la bonne conversation.
  • Type d’objectif, par exemple première réponse ou résolution.
  • Échéance ou durée du retard dans un fuseau horaire dépourvu d’ambiguïté.
  • Statut actuel, priorité, groupe et personne assignée lorsque ces champs influencent la responsabilité.
  • Une seule prochaine étape, comme répondre, réassigner le ticket ou demander à un responsable de l’examiner.

Utilisez les canaux que l’équipe d’assistance surveille déjà. Les notifications intégrées à l’application et par e-mail sont souvent suffisantes lorsqu’elles parviennent de manière fiable à la personne assignée ou au groupe responsable. Si un système distinct de radiomessagerie ou de messagerie est nécessaire, vérifiez que le service d’assistance prend en charge l’intégration avant de concevoir le processus autour de celle-ci.

Conseil de pro : Affichez une échéance ou un compte à rebours précis. Une heure concrète est plus facile à prioriser qu’un avertissement vague.

Ce que les alertes SLA doivent dire et où elles doivent être envoyées : schéma général

Maintenir la précision des minuteurs SLA grâce aux statuts de pause

La fiabilité d’un rappel dépend de celle de son horloge. Les objectifs de résolution sont généralement mis en pause lorsqu’un ticket attend une réponse du client, mais les statuts exacts doivent correspondre au workflow réel de l’équipe.

  • Sélectionnez des statuts de pause explicites et documentez la raison pour laquelle chacun arrête l’horloge.
  • Reprenez le décompte lorsque le ticket quitte un statut de pause.
  • Testez les tickets qui entrent et sortent plusieurs fois d’un statut de pause.
  • Vérifiez si les objectifs de première réponse et de résolution suivent les mêmes règles de pause.

Les calendriers professionnels résolvent un problème différent. Ils excluent les heures de fermeture de l’objectif lui-même, tandis que les statuts de pause excluent le temps en fonction de l’état du ticket. Configurez et testez les deux. Un week-end ne doit pas être comptabilisé dans un objectif calculé selon les heures ouvrées, et un ticket en semaine qui attend une réponse du client doit rester en pause même lorsque l’équipe est ouverte.

Tester et ajuster l’automatisation avant de lui faire confiance

Utilisez des tickets contrôlés pour tester l’ensemble du cycle de vie. Les données historiques peuvent aider à identifier des objectifs réalistes, mais un test en situation réelle est préférable pour vérifier la distribution des notifications et les changements d’échéance.

  1. Couvrez chaque politique. Créez un ticket de test pour chaque combinaison de groupe et de priorité pouvant sélectionner une politique SLA différente.
  2. Utilisez temporairement des objectifs courts. Confirmez les états de proximité d’échéance et de violation sans attendre des heures ou des jours, puis rétablissez les valeurs réelles.
  3. Testez les statuts de pause. Mettez en pause et reprenez l’horloge de résolution, puis vérifiez que l’échéance évolue comme prévu.
  4. Vérifiez les destinataires. Testez un ticket assigné et un ticket non assigné afin que les bonnes personnes reçoivent chaque notification.
  5. Examinez l’historique. Vérifiez que le ticket indique la politique appliquée et le moment où chaque horloge a été respectée ou manquée.

Après le lancement, examinez les avertissements erronés et les transmissions manquées. Si les alertes sont précises mais restent ignorées, le problème peut venir de la responsabilité ou des effectifs plutôt que du moment choisi pour les seuils.

Comment Deskhero gère les rappels SLA

Deskhero dispose de politiques SLA dédiées. Elles sont distinctes de ses règles générales d’automatisation, qui ne sont ni planifiées ni basées sur le temps.

  • Les propriétaires et les administrateurs peuvent classer les politiques SLA correspondant aux groupes et aux priorités des tickets. La première politique correspondante définit les objectifs de première réponse et de résolution.
  • Chaque politique peut utiliser un calendrier professionnel hebdomadaire nommé avec son propre fuseau horaire, ou compter le temps calendaire.
  • L’horloge de résolution se met en pause dans les statuts sélectionnés dans l’espace de travail. L’horloge de première réponse ne se met pas en pause.
  • Deskhero marque un ticket comme à risque pendant les 60 dernières minutes précédant sa prochaine échéance et le marque comme étant en violation une fois l’échéance dépassée.
  • Une vérification en arrière-plan s’exécute toutes les cinq minutes et envoie des notifications intégrées à l’application ainsi qu’un récapitulatif par e-mail à la personne assignée, ou aux membres du groupe lorsque le ticket n’est pas assigné. Les utilisateurs peuvent contrôler les canaux de notification SLA par groupe.

La liste des tickets comprend une colonne SLA et des filtres SLA, le tableau de bord met en évidence les tickets à risque et en violation, et la chronologie du ticket enregistre les événements liés à la politique et aux horloges. La section Statistics fournit des vues du respect des SLA une fois le workflow activé.

Que suivre une fois vos alertes activées

La première question est de savoir si les rappels empêchent les violations. Comparez les tickets à risque au nombre de tickets qui manquent ensuite l’objectif, puis examinez les cas que les avertissements n’ont pas permis de récupérer.

Suivez séparément le respect des objectifs de première réponse et de résolution. Examinez également le nombre de tickets dont l’échéance se situe actuellement dans la fenêtre d’avertissement, le nombre de tickets déjà en violation et les politiques ou combinaisons groupe-priorité qui génèrent le plus de manquements.

Associez les pourcentages à leur contexte opérationnel. Un pourcentage global élevé peut masquer une file qui enfreint régulièrement les objectifs. Une baisse soudaine peut refléter une modification du calendrier professionnel, l’ajout d’une nouvelle priorité ou une lacune dans la répartition des responsabilités plutôt qu’un ralentissement du travail.

Gérer les SLA qui se chevauchent sans collisions d’alertes

Un ticket peut avoir à la fois un objectif de première réponse et un objectif de résolution. Traitez-les comme deux horloges distinctes, car une réponse ne termine que la première. L’objectif de résolution continue jusqu’à ce que le ticket atteigne l’événement qui le valide.

L’interface du ticket doit afficher l’échéance en suspens la plus proche tout en conservant les détails des deux objectifs. Les filtres et les rapports doivent également distinguer la première réponse de la résolution afin qu’un indicateur satisfaisant ne masque pas les problèmes de l’autre.

Lorsque les clients ont des engagements différents, utilisez des politiques distinctes correspondant à des champs de ticket stables comme le groupe et la priorité. Classez les politiques spécifiques avant la politique générale, puis testez un ticket avec chaque combinaison pertinente. Évitez d’inventer des niveaux de contrat cachés que les utilisateurs ne peuvent ni voir ni vérifier sur le ticket.

Rester prêt pour les audits lorsque les SLA fonctionnent automatiquement

Conservez une trace de la politique appliquée, des échéances calculées et du moment où chaque horloge a été respectée ou manquée. Si une modification de groupe, de priorité ou de calendrier entraîne le recalcul d’une échéance, cette modification doit également être traçable.

Documentez les changements de politique en dehors de la boîte de réception des notifications. Indiquez qui a approuvé la modification, quand elle a pris effet et si elle s’applique aux tickets existants. Cela facilite les réponses aux questions ultérieures des clients et évite de modifier silencieusement la signification d’un rapport SLA.

Pour les contrôles contractuels, vérifiez le comportement de la plateforme au lieu de supposer que chaque événement visible constitue un journal d’audit. La chronologie des tickets de Deskhero enregistre l’application de la politique SLA et les résultats des horloges, tandis que sa section Statistics fournit les données de respect des objectifs. Les organisations soumises à des exigences formelles de conservation doivent vérifier que ces enregistrements répondent à leurs propres obligations.

Rédiger des messages SLA pour les utilisateurs, les responsables et les clients

Les alertes internes et les mises à jour destinées aux clients ont des objectifs différents. Concentrez chacune sur ce que son lecteur peut faire ensuite.

Les alertes destinées aux utilisateurs doivent commencer par le lien du ticket, le type d’objectif, l’échéance et l’action immédiate. Évitez un paragraphe de contexte sur la politique lorsque l’utilisateur doit traiter le ticket.

Les analyses destinées aux responsables doivent faire apparaître les tendances par groupe, priorité ou politique. Un ticket manqué nécessite une action, tandis que des manquements répétés nécessitent une décision concernant les effectifs ou le processus.

Les communications destinées aux clients doivent être précises et exactes. Si l’équipe prévoit un retard, une mise à jour relue par un humain peut indiquer une date réaliste pour le prochain contact. N’exposez pas les libellés d’alerte internes et ne promettez pas un délai de résolution que l’équipe ne peut pas tenir.

Connecter l’automatisation des SLA aux outils que vous utilisez déjà

Commencez par les fonctions SLA natives lorsqu’elles couvrent les politiques, calendriers, états de pause, alertes, filtres et rapports requis. Les échéances natives restent généralement mieux synchronisées avec les changements de tickets qu’un tableur parallèle.

Lorsque la prise en charge native est limitée, les équipes ont utilisé des extensions communautaires et des solutions de contournement documentées sur les forums. Examinez l’état de la maintenance et la compatibilité des versions avant de dépendre de cette approche.

Un workflow distinct peut être pertinent lorsque plusieurs systèmes doivent alimenter un même canal d’escalade. Définissez d’abord la source de vérité. Des calculs SLA dupliqués dans un service d’assistance et une couche d’intégration peuvent diverger, notamment concernant les fuseaux horaires, les heures ouvrées, les statuts de pause et les réassignations.

Point de vue éditorial : l’alerte n’est pas l’objectif, c’est l’action

Une notification de proximité d’échéance n’est utile que lorsque la responsabilité est claire. Le destinataire a besoin de l’autorisation, du contexte et du temps nécessaires pour faire avancer le ticket.

La précision du minuteur passe en premier. Un calendrier professionnel ou une configuration de pause incorrects produisent des alertes assurées mais trompeuses. Corrigez le calcul de l’échéance avant d’ajuster le texte du message ou d’ajouter des canaux.

Procédez dans cet ordre : objectifs de la politique, calendriers professionnels, comportement des pauses, destinataires des notifications, réponse opérationnelle et rapports. Cette séquence maintient le rappel associé à une échéance comprise par tous.

Activez vos rappels SLA sans projet de migration

Deskhero se connecte à Gmail ou Microsoft 365 avec une synchronisation bidirectionnelle, afin que les équipes puissent conserver leur adresse d’assistance existante tout en ajoutant la gestion partagée des tickets et les politiques SLA.

Deskhero

Configurez les objectifs de première réponse et de résolution par groupe et par priorité, ajoutez si nécessaire un calendrier professionnel hebdomadaire et choisissez les statuts qui mettent la résolution en pause. Deskhero affiche ensuite la prochaine échéance, met en évidence les tickets dus dans l’heure, avertit les utilisateurs responsables et enregistre les résultats SLA.

L’essai gratuit de 30 jours ne nécessite pas de carte bancaire. Connectez une boîte aux lettres, configurez un petit ensemble de politiques et testez l’intégralité du cycle de vie SLA avant d’étendre la configuration à d’autres groupes.

Sources

FAQ

Quelle est la différence entre un SLA, un SLO et un SLI ?

Un SLA est un engagement de service entre plusieurs parties. Un SLO est un objectif de performance pour un service, souvent utilisé en interne afin de respecter cet engagement. Un SLI est la valeur mesurée utilisée pour évaluer l’objectif.

Qu’est-ce qui constitue une alerte de violation SLA ?

Une alerte de violation indique qu’une échéance de première réponse ou de résolution encore ouverte est dépassée. Une alerte de proximité d’échéance est différente, car l’équipe a encore le temps de respecter l’objectif.

Que signifie un SLA de 4 heures ?

Cela signifie que l’action désignée par la politique, comme la première réponse ou la résolution, doit être effectuée dans les quatre heures calculées selon cette politique. L’horloge peut utiliser le temps calendaire ou un calendrier professionnel.

En quoi un SLA diffère-t-il d’un KPI ?

Un SLA énonce un engagement de service. Un KPI mesure la performance et peut servir à suivre de nombreux objectifs qui ne sont pas des échéances contractuelles.

Deskhero peut-il automatiser les rappels SLA sans code personnalisé ?

Oui. Deskhero intègre des politiques SLA, une fenêtre d’avertissement fixe avant échéance, la détection des violations, des notifications intégrées à l’application et par e-mail, des filtres de tickets, des vues de tableau de bord et des rapports SLA. Ces fonctions sont distinctes de ses règles générales d’automatisation.