Configuration des modules
SLA
Engagements de temps sur les tickets et tâches — mesurer, surveiller et escalader lorsque les délais menacent de rompre.
Mis à jour le 23 janv. 2026
Configuration · Modules · 4.4
Un SLA (Service Level Agreement) est un engagement de temps sur un ticket ou une tâche. Le module SLA enregistre ce que vous promettez, à quels cas il s’applique, et suit si l’engagement est tenu — avec un compteur qui ne tourne que pendant les heures ouvrées.
Pourquoi cela compte pour le business
« Promesses non mesurables »
Time-to-first-response et time-to-resolution explicités — reportables au mois.
« L'attente côté client compte »
Des conditions mettent en pause le compteur à certains statuts — mesure équitable.
« Le compteur tourne hors heures de bureau »
Un calendrier est attaché au SLA → le compteur ne tourne qu'en heures ouvrées.
« Escaladé trop tard »
Séquence de notifications sur le pourcentage de SLA → rappel, manager, comité de pilotage automatiquement.
Quatre aspects de chaque SLA
| Aspect | Ce qu'il fixe |
|---|---|
| Classe | Time to first response ou time to resolution. Deux stratégies de mesure différentes. |
| Critères | Quand le SLA s'applique : organisation, classification, priorité, type (ticket/tâche), modèle, kind. |
| Délai cible | Délai maximum autorisé en heures/minutes + le calendrier qui définit les heures ouvrées. |
| Conditions | Quand le compteur démarre, est mis en pause ou s'arrête (par ex. le statut « En attente du client » met en pause). |
La combinaison classe + critères est unique — créer exactement la même configuration deux fois déclenche une erreur.
Deux classes de SLA
Time to first response
À quelle vitesse quelqu'un répond au ticket ? S'arrête dès que la première réponse est donnée.
Time to resolution
À quelle vitesse c'est résolu ? S'arrête au statut de complétion.
Comportement en cas de changement
Quand quelque chose change sur un ticket (organisation, priorité, classification), Gfacility revérifie si un SLA correspond. Un nouveau SLA devient actif, ou un existant est masqué si plus aucun critère ne correspond.
Quand la configuration SLA elle-même change, les SLA déjà actifs restent intacts — l’ancien continue de tourner jusqu’à la clôture du ticket. Ce n’est qu’au changement de quelque chose sur le ticket que Gfacility réévalue.
Quelles décisions allez-vous prendre ?
Quels niveaux de priorité ?
Critique · haut · normal · bas — chacun avec sa propre cible. Trop de niveaux = complexité inutile.
Heures ouvrées ou 24/7 ?
Quel calendrier attachez-vous ? Un calendrier par équipe de service suffit généralement.
Quels statuts mettent en pause ?
« En attente du client », « En attente » — sinon les attentes externes continuent et vous échouez injustement.
SLA sur ticket ou tâche ?
Les deux sont possibles, mais choisissez selon le cas — sinon vous reportez en double.