Créez un outil de suivi des SLA qui calcule les échéances des tickets, met les compteurs en pause pendant les réponses des clients et présente les violations de service par équipe.
Les équipes des opérations clients ne manquent presque jamais un SLA parce qu'une personne ignore une date. Les échéances changent, les tickets passent d'une équipe à l'autre et les réponses des clients peuvent interrompre le travail pendant plusieurs jours. Une feuille de calcul avec une seule colonne d'échéance ne tient pas longtemps, sauf si quelqu'un la met à jour après chaque changement.
Le premier problème vient du fait que l'on traite chaque objectif SLA comme une seule échéance. Le délai de première réponse mesure la rapidité avec laquelle un agent accuse réception d'une nouvelle demande. Le délai de résolution mesure le temps dont l'équipe dispose pour la résoudre. Un ticket peut respecter son délai de réponse en 15 minutes et dépasser son délai de résolution trois jours plus tard. Une seule échéance ne permet pas de voir quel engagement n'a pas été tenu.
La responsabilité pose un autre problème. Un agent peut répondre, un spécialiste peut enquêter et un responsable peut approuver la solution. Si personne ne gère le compteur SLA actif, chacun peut penser que quelqu'un d'autre le surveille. Le ticket reste dans une file jusqu'à l'expiration du délai.
Prenons un problème d'accès à un compte signalé à 10 h. L'agent répond à 10 h 12, ce qui respecte un délai de réponse de 30 minutes, puis demande une capture d'écran à 10 h 20. Le client répond le lendemain après-midi. Si l'outil compte cette attente dans le délai de résolution, il fait porter au support la responsabilité d'un temps dont il ne pouvait pas se servir. S'il met le compteur en pause sans le relancer, le résultat est faux dans l'autre sens.
Un outil de suivi doit donner à chaque ticket un dossier opérationnel partagé avec le responsable, l'équipe, la priorité, les échéances de réponse et de résolution, l'état du compteur, la raison de la pause et l'historique des changements. Les agents peuvent ainsi se concentrer sur les tâches proches d'une violation, tandis que les responsables identifient les retards liés aux effectifs, aux transferts ou à l'attente du client.
Les feuilles manuelles peuvent convenir à une petite file stable. Dès que les échéances dépendent de la priorité, des heures ouvrées, des réaffectations et des pauses, l'outil doit appliquer des règles cohérentes.
Chaque ticket doit contenir assez d'informations pour expliquer qui en est responsable, quel engagement s'applique et si le compteur doit continuer à tourner. Commencez par les éléments de base : client ou compte, priorité, équipe assignée, responsable du ticket et statut actuel.
Ajoutez ensuite les champs qui déterminent l'échéance :
Séparez la première réponse de la résolution complète. Une équipe peut promettre une première réponse sous quatre heures ouvrées tout en se donnant deux jours ouvrés pour résoudre le problème. Une seule échéance permettrait à une réponse rapide de masquer un ticket toujours non résolu.
Ne demandez pas aux agents de sélectionner manuellement « en violation ». Calculez cet état à partir de l'heure actuelle, de l'échéance, du statut du ticket et des pauses valides. Par exemple, un ticket dépasse son SLA de résolution lorsque son échéance est passée, qu'il reste ouvert et que le compteur est actif.
AppMaster peut centraliser cette logique. Son Data Designer permet de modéliser les champs des tickets, tandis qu'un Business Process visuel peut calculer les échéances et l'état de violation chaque fois qu'un agent crée ou met à jour un ticket.
Des règles claires rendent les résultats SLA équitables. Définissez l'objectif associé à chaque catégorie de ticket avant de créer les formules ou les rapports. Sinon, deux agents peuvent traiter la même demande différemment et le nombre de violations perd toute sa valeur.
La plupart des équipes font varier les délais selon la priorité, l'offre du client et le type de demande. Gardez une première version simple. Par exemple, les incidents urgents en production peuvent exiger une première réponse sous une heure, les problèmes d'accès des clients abonnés sous quatre heures ouvrées et les questions courantes sous deux jours ouvrés.
Rédigez chaque règle en termes simples. « Un problème de facturation hautement prioritaire pour un client premium doit recevoir une première réponse sous deux heures ouvrées » indique précisément les données à stocker : priorité, offre, type de demande, heure de création et heure de première réponse.
Décidez si les délais fonctionnent 24 heures sur 24 ou uniquement pendant les heures de support. Si le support fonctionne du lundi au vendredi de 9 h à 17 h, un ticket reçu vendredi à 16 h 30 avec un délai de deux heures doit arriver à échéance lundi à 10 h 30, et non vendredi soir.
Documentez les jours travaillés, les heures de support, le fuseau horaire, les jours fériés et tout calendrier distinct pour les incidents 24 h/24 et 7 j/7. Utilisez si possible un calendrier nommé par règle. Les équipes dont les clients se trouvent dans plusieurs pays peuvent avoir besoin de calendriers régionaux, mais créer un calendrier pour chaque client ajoute une maintenance inutile.
Choisissez exactement le moment où le compteur démarre. Les nouveaux tickets commencent souvent lorsque le système les reçoit. Les tickets rouverts nécessitent une règle distincte : conserver le temps restant, redémarrer le compteur initial ou commencer un nouvel objectif. Choisissez une méthode et appliquez-la de façon cohérente.
Confiez les changements de règles à une personne ou à un petit groupe. Les agents peuvent corriger les données d'un ticket, mais ils ne doivent pas modifier les délais pour faire disparaître une violation. Stockez la version de la règle dans chaque enregistrement et notez les exceptions approuvées avec leur motif et leur date.
Une application AppMaster peut centraliser les règles dans un espace d'administration et appliquer la règle correspondante lorsqu'un ticket entre dans le système. Les formules dispersées dans plusieurs feuilles de calcul sont ainsi remplacées par un compteur cohérent.
Gardez la première version suffisamment simple pour qu'un responsable des opérations puisse examiner un ticket et comprendre pourquoi son échéance a changé.
Commencez par une table des tickets contenant un identifiant, un sujet, un client, une priorité, un statut, l'heure de création, l'heure de première réponse, l'heure de résolution, les échéances, le responsable assigné et l'équipe responsable. Chaque ticket doit avoir un responsable et une équipe actuels, même lorsque plusieurs personnes y ajoutent des commentaires.
Créez des enregistrements distincts pour les équipes et les règles SLA. Un enregistrement d'équipe peut contenir son nom et son calendrier d'heures ouvrées. Chaque règle doit indiquer les tickets concernés, ses objectifs de réponse et de résolution, son type de compteur et si l'attente du client met le compteur en pause.
Ajoutez un enregistrement des jours fériés avec la date, l'équipe ou le lieu concerné et une courte description. Stockez tous les horodatages dans un même fuseau, généralement UTC, puis affichez l'heure locale dans l'interface si nécessaire. Les fuseaux mélangés provoquent des erreurs autour des week-ends et des changements d'heure saisonniers.
Conservez un historique des statuts au lieu d'écraser les données passées. Chaque entrée doit contenir l'identifiant du ticket, l'ancien et le nouveau statut, l'heure de l'événement et la personne ou la règle à l'origine du changement. Enregistrez des événements comme « En attente du client », « Réponse du client », « Assigné » et « Résolu ».
Cet historique explique les changements d'échéance. Si une échéance passe du mardi matin au mardi après-midi, un responsable peut voir que l'équipe a suspendu le SLA pendant trois heures en attendant le client. Le Data Designer visuel d'AppMaster peut modéliser ces enregistrements liés, et son Business Process Editor peut mettre à jour les échéances après les changements de statut.
Démarrez le compteur lors d'un événement clairement défini, par exemple lorsque le système reçoit un ticket de support. Ne le démarrez pas simplement parce que quelqu'un consulte le ticket. Enregistrez l'heure de départ afin que tous les calculs suivants utilisent le même point de référence.
Sélectionnez ensuite la règle SLA correspondant à l'offre du client, au type de ticket, à la priorité ou à la région. Calculez ensuite l'échéance :
Les heures ouvrées rendent ce calcul moins évident qu'il n'y paraît. Si un SLA de quatre heures commence à 16 h et que le support fonctionne de 9 h à 17 h, il reste une heure pour cette journée. Le ticket arrive à échéance à midi le jour ouvré suivant, et non à 20 h.
Lorsqu'un ticket change de priorité, conservez l'heure de départ initiale et appliquez la règle d'escalade documentée. Certaines équipes appliquent le délai urgent depuis le début du ticket, tandis que d'autres démarrent un nouvel objectif au moment de l'escalade. Les deux méthodes peuvent fonctionner si tout le monde suit la même règle.
Affichez à la fois l'échéance exacte et le temps restant. Des libellés comme « 2 h 15 restantes », « échéance dans 1 jour » et « en retard de 35 min » permettent aux agents de parcourir une file plus rapidement que des horodatages. Utilisez un état neutre pour les tickets dans les délais, un avertissement à l'approche de l'échéance et un état de violation explicite une fois celle-ci dépassée.
Mettez le compteur en pause uniquement lorsque l'équipe ne peut pas faire avancer le ticket sans le client. Les raisons courantes sont l'attente d'informations, d'une confirmation, d'un accès, d'une validation ou de fichiers. Un retard interne, comme l'attente d'un collègue, ne doit pas suspendre le SLA.
Utilisez un ensemble court et clair de statuts :
Lorsqu'un agent sélectionne l'un de ces statuts, enregistrez l'heure exacte et la raison de la pause. Notez aussi le message ou l'événement qui a demandé la réponse du client. Les superviseurs pourront ainsi vérifier que la pause était justifiée.
Lorsque le client répond, relancez le compteur à l'heure de sa réponse. Ajoutez la durée d'attente au champ total paused time, puis recalculez le temps restant selon les règles d'heures ouvrées. Une attente client de 90 minutes repousse l'échéance de 90 minutes, sous réserve des heures de fermeture.
Affichez le temps passé en pause dans la vue du ticket. Les agents doivent savoir si un ticket attend depuis 15 minutes ou trois jours, et les superviseurs doivent pouvoir repérer les tickets qui reviennent souvent à un statut d'attente.
Limitez les motifs de pause à ceux autorisés par la règle SLA. Exigez un événement de demande au client avant d'accepter une pause. Dans AppMaster, un Business Process peut vérifier le nouveau statut, enregistrer l'heure de début de la pause et refuser les changements non valides avant la mise à jour de l'enregistrement SLA.
Un e-mail automatique du type « nous avons reçu votre message » ne doit pas relancer le compteur. Utilisez un message entrant du client ou une réponse confirmée par un agent, et conservez tout l'historique des pauses avec le ticket.
Un client envoie une question de facturation mardi à 10 h : « Pourquoi ma facture affiche-t-elle deux prélèvements ? » L'outil crée le ticket B-184, l'attribue au Support et applique la règle SLA de facturation. L'équipe dispose de quatre heures ouvrées pour fournir une première réponse utile et de huit heures ouvrées pour résoudre le problème.
Le support fonctionne du lundi au vendredi, de 9 h à 17 h. À 10 h 35, un agent confirme que l'équipe vérifie le compte. Le compteur de première réponse s'arrête après 35 minutes, avec 3 h 25 restantes. Le ticket respecte son objectif de première réponse.
À 11 h, l'agent a besoin d'un numéro de facture et marque le ticket « En attente du client ». Le compteur de résolution se met en pause après une heure de travail actif. L'outil enregistre le début et le motif de la pause.
Le client répond à 15 h 30. L'outil ajoute les 4 h 30 d'attente à l'échéance. L'échéance de résolution initiale était fixée à mardi 18 h. La nouvelle échéance devient donc mercredi à 14 h 30, après le report du temps restant au prochain jour ouvré.
Un agent résout le problème mercredi à 15 h 10. Le ticket a 40 minutes de retard. Il compte comme une résolution en retard pour le Support, tandis que sa première réponse reste dans les délais.
Un rapport de violations doit présenter clairement cette distinction : le Support a reçu un ticket de facturation, respecté l'objectif de première réponse, dépassé le délai de résolution de 40 minutes et passé 4 h 30 à attendre le client. L'âge total du ticket raconterait une histoire erronée.
Un ticket dépasse son SLA lorsque l'échéance est passée avant que l'action requise ait lieu. Utilisez l'échéance ajustée après les pauses valides dues à l'attente du client.
Séparez les tickets ouverts en retard des tickets résolus tardivement. Les tickets ouverts en retard nécessitent une intervention immédiate. Les tickets résolus tardivement servent aux rapports de performance. Les réunir masque le travail urgent et rend le rapport moins utile.
Pour chaque période, regroupez les résultats selon l'équipe qui possédait le ticket au moment du dépassement. Filtrez par règle, priorité et période. Une équipe de facturation soumise à une règle de réponse de quatre heures ne doit pas être comparée directement à une équipe d'escalade technique soumise à une règle de résolution de deux jours ouvrés.
Utilisez les volumes avec les taux :
Un taux de violation de 50 % n'a pas la même signification s'il provient d'un ticket en retard sur deux plutôt que de 50 tickets en retard sur 100. Examinez les tendances avec le détail des tickets. Des violations fréquentes sur les tickets hautement prioritaires peuvent signaler un problème de règles d'escalade ou de transferts plutôt qu'une charge de travail globale excessive.
Un rapport utile permet à un responsable d'ouvrir la liste des tickets en retard, de voir la règle et la priorité, puis de vérifier le responsable au moment de la violation. Il doit faciliter l'analyse du travail à corriger, et non récompenser les équipes qui ferment les tickets trop tôt.
Les agents ont besoin d'une courte liste de travail, pas d'un rapport rempli d'anciens tickets. Chaque ticket ouvert doit afficher le responsable, l'équipe, la priorité, l'échéance, l'état du compteur et le temps restant. Enregistrez immédiatement les changements de responsable lorsqu'un ticket passe d'une équipe à l'autre.
Utilisez des libellés de compteur simples. « Actif » signifie que l'équipe est responsable de la prochaine action. « En pause - en attente du client » signifie que le compteur est arrêté. Affichez séparément le temps actif et le temps en pause afin que les utilisateurs comprennent pourquoi un ticket est resté ouvert plusieurs jours.
Une vue agent peut inclure les tickets arrivant à échéance dans les quatre prochaines heures, les tickets en retard, les tickets en attente d'une réponse client et les tickets réassignés aujourd'hui. Envoyez des avertissements avant l'échéance. Un délai de réponse de quatre heures nécessite des alertes plus précoces qu'un délai de résolution de trois jours.
Les responsables ont besoin d'une autre vue. Un rapport hebdomadaire peut regrouper les tickets en retard par équipe et afficher le nombre de violations, le pourcentage respecté, le retard moyen et les tickets toujours ouverts après leur échéance. Ajoutez le responsable et la dernière mise à jour à chaque élément en retard.
Conservez un audit des changements de règles. Si l'équipe des opérations fait passer un objectif de huit à douze heures, notez qui l'a modifié, quand et quels nouveaux tickets utilisent cette règle. Les résultats historiques doivent conserver la règle applicable au démarrage de chaque ticket.
AppMaster permet aux équipes de créer des vues web distinctes pour les agents et les responsables, tout en conservant les mêmes données de tickets et les mêmes règles métier derrière ces deux vues.
Des graphiques bien présentés peuvent tout de même raconter une histoire fausse lorsque les règles sous-jacentes sont incorrectes.
Ne faites pas les calculs en heures calendaires lorsque l'accord prévoit des heures ouvrées. Un ticket ouvert vendredi à 16 h 30 avec un délai de réponse de huit heures ouvrées ne dépasse pas son SLA samedi à 0 h 30. Comptez uniquement les heures travaillées et les jours fériés définis par la règle.
Apportez la même attention aux pauses. Un statut « en attente du client » ne doit suspendre un SLA que lorsque l'équipe a envoyé une demande claire et ne peut pas avancer sans réponse. Mettre chaque ticket portant ce libellé en pause masque les retards qui relèvent de l'équipe.
Conservez les dates qui expliquent chaque résultat : l'échéance initiale, la règle utilisée, chaque début et chaque fin de pause, le motif de la pause, l'échéance ajustée, l'heure de résolution et la personne qui a fermé le ticket. Sans cet historique, personne ne peut vérifier pourquoi un ticket apparaît comme traité à temps.
Utilisez une règle unique de responsabilité dans les rapports par équipe. Si le Support réattribue un ticket à la Facturation, ne comptez pas la même violation pour les deux équipes. Vous pouvez attribuer le résultat à l'équipe qui possédait le ticket au moment du dépassement et présenter les transferts séparément.
Exigez un horodatage de résolution avant de fermer un ticket. Un statut fermé ne prouve pas à quel moment le travail s'est terminé. Par exemple, si un ticket passe du Support à la Facturation à 14 h et dépasse son délai à 15 h, la Facturation est responsable de la violation selon la règle du responsable au moment du dépassement. Le rapport peut toujours afficher le transfert précédent du Support sans ajouter une deuxième violation.
Examinez chaque règle SLA avant que les agents ne dépendent de l'outil. Chaque règle doit définir un objectif clair, comme une première réponse sous quatre heures ou une résolution sous deux jours ouvrés, ainsi que le calendrier applicable. Définissez une règle par défaut pour les tickets qui ne correspondent à aucune règle de client, d'offre ou de priorité.
Testez les horaires difficiles, et pas seulement les cas ordinaires :
Comparez les totaux du tableau de bord avec la liste de tickets correspondante. Si un rapport indique que l'équipe A compte 12 violations, filtrez les enregistrements et recomptez-les. Cette vérification permet de détecter les doublons, les équipes manquantes et les tickets rouverts comptés deux fois.
Définissez les droits d'accès avant la mise en production. Les agents doivent mettre à jour les tickets qu'ils traitent, les responsables ont besoin des rapports de leur équipe et les administrateurs doivent contrôler les paramètres des règles. Dans AppMaster, testez chaque rôle avec un compte distinct afin qu'un responsable n'ait pas besoin d'un accès administrateur pour consulter les rapports de violations SLA.
Commencez avec un type de ticket et une règle SLA. Une équipe support peut débuter avec les demandes standard envoyées par e-mail et un objectif de première réponse sous 24 heures. Cela suffit pour tester les échéances, les pauses autorisées et les enregistrements de violations.
Demandez à quelques membres des opérations clients de traiter de vrais tickets dans le workflow, notamment un cas normal, un cas d'attente client et un délai dépassé. Recueillez des retours précis. Les agents peuvent avoir besoin de statuts distincts pour l'attente d'un client et l'attente d'une autre équipe. Les responsables peuvent constater qu'un libellé générique « en pause » ne fournit pas assez d'informations.
Lorsque la feuille de calcul limite le processus, créez l'outil de suivi comme application no-code dans AppMaster. Vous pouvez créer des formulaires de tickets, définir la logique des compteurs dans le Business Process Editor visuel et donner aux agents et aux responsables des tableaux de bord distincts. AppMaster peut générer le backend, l'application web et l'application mobile native lorsque l'outil doit fonctionner au-delà d'un tableau partagé.
Restez modeste au début pour les rapports : tickets ouverts, tickets proches d'une violation, tickets en pause et violations par équipe. Comparez des échéances d'exemple avec des vérifications manuelles, examinez les tickets en violation et leurs périodes de pause, puis ne changez qu'une règle à la fois avant de la tester à nouveau. Lorsque les équipes font confiance aux calculs, ajoutez un autre type de ticket ou une autre règle de priorité et répétez les mêmes vérifications.
Pourquoi suivre séparément la première réponse et la résolution ?Suivez la première réponse et la résolution comme deux engagements distincts. Une réponse rapide peut respecter le délai de réponse alors que le ticket dépasse toujours son délai de résolution.
Quand un compteur SLA doit-il démarrer ?Démarrez le compteur lorsque votre système reçoit le ticket, puis appliquez la règle SLA correspondant à sa priorité, son offre, son type ou sa région. Enregistrez cette heure de départ afin que les mises à jour suivantes utilisent le même point de référence.
Comment calculer les échéances SLA pendant les heures ouvrées ?Comptez uniquement les heures de support prévues par la règle. Par exemple, si le support ferme à 17 h et qu'un délai de deux heures commence à 16 h 30, les 90 minutes restantes sont reportées au prochain jour ouvré.
Quand une équipe peut-elle mettre un compteur SLA en pause ?Mettez le compteur en pause uniquement lorsque l'équipe attend quelque chose du client pour pouvoir continuer, par exemple un accès, une validation, des fichiers ou des informations demandées. Ne mettez pas le compteur en pause pour les files d'attente internes, les transferts ou les problèmes d'effectif.
Que doit-il se passer lorsqu'un client répond à un ticket en pause ?Enregistrez l'heure de début de la pause, une raison précise et la demande au client qui l'a déclenchée. Lorsque le client envoie une réponse utile, relancez le compteur et conservez tout l'historique de la pause dans le ticket.
Quelle équipe est responsable d'une violation SLA après le transfert d'un ticket ?Attribuez un responsable actuel et une équipe responsable à chaque ticket. Pour les rapports par équipe, comptez la violation pour l'équipe qui détenait le ticket au moment du dépassement, puis présentez séparément les transferts précédents.
Que doivent voir les agents dans un outil de suivi des SLA ?Affichez l'échéance exacte, le temps restant, l'état du compteur, le responsable, l'équipe et la priorité. Les agents ont aussi intérêt à disposer de files courtes pour les tickets bientôt à échéance, en retard et en attente d'une réponse client.
Quelles métriques SLA les responsables doivent-ils suivre ?Séparez les tickets ouverts en retard des tickets résolus tardivement. Présentez le nombre total de tickets soumis à un SLA, les résolutions dans les délais, les tickets ouverts en retard, les résolutions tardives et le taux de violation. Donnez ensuite aux responsables accès aux tickets concernés.
Comment tester un outil de suivi des SLA avant son lancement ?Testez les tickets créés juste avant la fermeture, avant les week-ends et les jours fériés, après une attente client et lors d'un transfert d'équipe. Fermez aussi un ticket après son échéance et vérifiez que l'outil enregistre une seule violation avec la bonne règle.
Puis-je créer un outil de suivi des SLA sans écrire de code ?Oui. AppMaster vous permet de modéliser les tickets, les règles, les équipes, les jours fériés et l'historique des statuts dans son Data Designer. Vous pouvez utiliser des processus métier visuels pour calculer les échéances, gérer les pauses autorisées et créer des vues distinctes pour les agents et les responsables à partir des mêmes données.
14 juil. 2026
8 min
13 juil. 202611 min
08 juil. 20266 minExpérimentez avec AppMaster avec un plan gratuit.
Lorsque vous serez prêt, vous pourrez choisir l'abonnement approprié.
