SLA, calendrier et escalades

Tu mets en place les délais sous « Settings → SLA ». La page elle-même t'indique en haut quand aucune politique n'est active. Une politique a trois parties : un nom, les conditions et les objectifs. Les nouvelles politiques sont volontairement créées inactives, pour que tu puisses finir de les configurer avant qu'elles ne fassent quoi que ce soit.

Les conditions sont « Team », « Priority », « Main category » et « Subcategory ». Vide signifie « Any », c'est-à-dire « s'applique à tout », et non « ne s'applique à rien ». Si plusieurs politiques correspondent, celle qui a le plus petit numéro sous « Order » l'emporte ; c'est pourquoi la politique étroite est en haut et la générale en dessous.

Les deux champs de catégorie sont regroupés par équipe, parce que les catégories appartiennent à une équipe, mais on te les propose toutes, y compris celles des autres équipes. C'est voulu : lors d'une transmission, le ticket bouge, la catégorie non. Un ticket que le helpdesk a transmis à l'équipe réseau porte encore la classification du helpdesk, et une politique peut viser précisément cela. Une fois une catégorie principale choisie, le champ en dessous ne propose que les sous-catégories qui lui sont liées ; une paire qui ne peut pas exister sur un ticket est refusée à l'enregistrement.

Chaque politique a deux objectifs. « Time to first response » se termine avec la première réponse publique d'un agent ; un accusé de réception automatique et une note interne ne comptent explicitement pas. « Time to resolution » se termine dès que le ticket atteint un statut qui compte comme résolu (lequel, tu le règles sous « Settings → General → Status »). Les deux objectifs ont leurs propres minutes, leur propre calendrier et leur propre réaction à un dépassement.

Sur le ticket, les délais se trouvent à droite dans la carte « Details », et en dessous « Show deadline history » : un journal qui consigne chaque étape, démarré, en pause, repris, tenu, manqué, chacune avec un motif et le temps de travail consommé. Seuls les agents et les administrateurs le voient ; pour les clients, il n'est pas consultable.

Si quelqu'un change plus tard la priorité ou l'équipe, l'horloge passe à la politique qui correspond alors : le temps de travail consommé jusque-là est arrêté avec l'ancien calendrier, et ensuite les nouvelles valeurs s'appliquent. Si plus aucune politique ne correspond, l'horloge s'arrête sans verdict : elle ne compte ni comme tenue ni comme dépassée.

Si aucune politique ne correspondait à la création du ticket, l'horloge démarre la première fois qu'une politique correspond après un changement, par exemple une priorité plus élevée. Elle compte à partir de ce moment. L'horloge de la première réponse ne démarre que si personne n'a encore répondu.

De nouvelles horloges ne naissent que lorsqu'un ticket est rouvert. Les autres changements de statut ne créent pas de nouvelles horloges.

Un calendrier dit quand l'horloge tourne. Il a un nom, son propre fuseau horaire et un nombre libre de plages par jour de la semaine ; une pause de midi est simplement un jour à deux plages. Une plage peut passer minuit ; il apparaît alors « ends next day » à côté.

Le calendrier qui s'applique à une équipe se règle sur l'équipe (« Settings → Teams »). Sur l'objectif isolé d'une politique, tu peux le remplacer : « From the team » prend celui de l'équipe, ou tu en choisis un autre. C'est exactement ce qui produit le cas habituel : les pannes comptent 24 heures sur 24, tout le reste seulement pendant les heures de bureau.

Ce qui est compté, c'est le temps qui s'écoule réellement à l'intérieur de la plage, pas la différence entre deux lectures de l'horloge. Au changement d'heure, cela fait une différence : une journée continue en octobre a 25 heures, une équipe de nuit de 22 h à 6 h en fait sept au printemps au lieu de huit. Une plage de bureau de 9 h à 17 h n'est jamais concernée, parce que dans l'Union européenne le changement se fait la nuit.

Si aucun calendrier avec des heures d'ouverture ne peut être trouvé, aucun délai n'est créé : mieux vaut aucun qu'un délai deviné. Sur le ticket, une remarque apparaît à la place d'une date.

Sous chaque calendrier se trouve la liste « Closed days ». Un clic sur « Import holidays (.ics) » prend un fichier de calendrier et rapporte ensuite quatre nombres : combien de jours ont été repris, combien remplacés, combien illisibles et combien étaient déjà là. Tu peux aussi saisir des jours isolés à la main.

Le symbole ↻ derrière un jour signifie « se répète chaque année ». Il n'est correct que pour les dates fixes : le 3 octobre tombe à la même date chaque année, le Vendredi saint et le lundi de Pentecôte dépendent de la date de Pâques et se déplacent. Les fêtes mobiles figurent donc dans la liste avec leur date concrète pour chaque année ; sur l'image, « Good Friday » sans le symbole.

Un jour de fermeture avale toute la plage de ce jour, y compris la partie qui déborde sur le jour suivant. Et quand un calendrier ne connaît aucun jour de fermeture pour les douze prochains mois, la page le dit explicitement ; sinon, le système compte en silence à travers les jours fériés et produit des délais faux.

La dispute la plus fréquente au sujet des délais est celle-ci : le ticket attend depuis trois jours la réponse du client, et l'horloge continue de tourner. C'est pourquoi chaque objectif a l'interrupteur « Pause while waiting for the requester », individuellement et non pour toute la politique.

C'est le statut qui décide si tu attends : sous « Settings → General → Status », chaque statut porte une marque indiquant s'il compte comme « en attente du demandeur ». Avec l'interrupteur activé, le délai se repose tant que le ticket est dans un tel statut. L'horloge murale continue de tourner, c'est pourquoi la liste affiche « Paused » au lieu d'un temps restant, et l'historique des délais contient « Paused » et « Resumed » avec leurs heures. Le temps d'attente ne compte pas non plus si le ticket est résolu directement depuis un tel statut.

Pour la première réponse, tu laisses en général l'interrupteur désactivé : tu dois la première réponse quoi qu'on attende. Pour la résolution, il est en général activé. L'image montre exactement ce réglage.

Dès qu'une politique est active, la liste des tickets reçoit la colonne « Deadline ». Elle montre le temps restant du prochain délai ouvert (« 14h 53m »). Une fois qu'aucun délai du ticket ne court plus, le verdict s'y affiche : la pastille « In time » pour un délai tenu, le « Breached » rouge pour un délai manqué. Un ticket sans aucune horloge reçoit un tiret neutre, et c'est voulu : un ticket antérieur à la politique n'est pas un échec.

Si aucune politique n'est active, la colonne est absente ; elle ne reste pas là, vide. La même chose vaut pour le filtre : sous « Filter », la case « Breached only » n'apparaît que s'il y a des délais.

Un ticket a deux horloges mais la colonne n'a qu'une place : elle montre le délai OUVERT le plus urgent. Si la première réponse a été manquée et que la résolution court encore, la colonne montre le temps restant de la résolution avec un « ! » rouge à côté. Cette marque dit qu'un délai de ce ticket a déjà été dépassé, et c'est exactement ainsi que le filtre « Breached only » le trouve, parce qu'il demande n'importe quel délai dépassé, y compris un délai terminé depuis longtemps. Lequel des deux a été touché est écrit dans le ticket lui-même.

Tu peux aussi trier dessus : sous le même titre « Deadline » se trouve un champ avec « Due soonest first » et « Due latest first ». Les tickets sans horloge en cours finissent toujours en dernier ; ils ne sont pas les moins urgents, ils ne sont simplement pas concernés. Le tri par délai l'emporte sur le tri par « Updated at » : aucune liste ne peut satisfaire deux ordres à la fois.

Par objectif, tu règles sous « When breached » ce qui se passe en cas de dépassement : « Record only » se contente de le consigner, « Notify assignee and observers » envoie un message à la personne responsable et aux observateurs (pas à toute l'équipe), « Hand over to another team » transmet le ticket. Pour la transmission, tu dois choisir une équipe cible ; une politique sans équipe cible est refusée à l'enregistrement, parce qu'elle aurait l'air configurée et ne ferait rien.

L'action s'exécute exactement une fois par horloge. Sans ce verrou, un redémarrage du serveur renverrait le même message. La marque « déjà fait » est posée même quand l'envoi a échoué : un message qui n'est pas arrivé vaut mieux qu'une boucle qui en envoie un nouveau chaque minute.

Le dépassement lui-même est daté du moment où l'échéance est tombée, pas du passage de vérification ; sinon, les rapports dépendraient du rythme du service de contrôle. Et il se mesure au temps de travail consommé : une horloge en pause ne peut pas être dépassée, même quand l'échéance est passée depuis longtemps.

La transmission remet le statut sur « Open ». Les lignes d'historique qui s'y rapportent sont internes ; le client ne voit sur le ticket que le nouveau statut et la nouvelle équipe.

Sous « Reports », tu choisis la période et tu appuies sur « Generate report » ; sans ce clic, la page reste vide. Le rapport contient ensuite le bloc « Service level agreements » avec une ligne par objectif : tenus, dépassés, encore en cours, taux atteint et temps moyen consommé.

Le comptage se fait par objectif, pas par ticket ; c'est aussi écrit sous le tableau. Un ticket qui a les deux objectifs apparaît donc deux fois, une fois dans chaque ligne.

Le taux atteint ne compte que les horloges tranchées. Celles qui courent n'ont pas leur place au dénominateur, sinon tout SLA fraîchement activé aurait l'air catastrophique au début et s'améliorerait tout seul. S'il n'y a pas encore une seule horloge tranchée, un tiret apparaît, et non « 0 % ».

Si tu travailles avec des incidents collectifs, il y a une ligne supplémentaire « Achieved without group incidents » : un seul incident collectif avec cent tickets rattachés fausserait sinon le taux dans les deux sens. Elle laisse de côté chaque ticket lié à un incident collectif.

Dans ce bloc, les agents ne voient que leurs propres équipes. Sans Professional, le bloc n'apparaît que s'il existe des données de délais antérieures ; il reste alors lisible.