Les politiques SLA du support client, expliquées

Un accord de niveau de service (SLA, service level agreement) est un engagement sur la rapidité avec laquelle vous répondez aux demandes et les résolvez. Une politique SLA est la façon dont votre helpdesk fait respecter cet engagement sur chaque ticket. La plupart des politiques ont les mêmes composantes :

• Conditions : les tickets auxquels la politique s'applique, par exemple selon le client, le canal ou le type de demande
• Objectifs : les délais maximaux pour la première réponse, les réponses suivantes et la résolution, généralement définis par priorité
• Heures : si le chronomètre compte en heures ouvrées ou en heures calendaires
• Règles de pause : les statuts qui arrêtent le chronomètre
• Actions en cas de dépassement : rappels avant qu'un objectif ne soit manqué et escalades après

L'ordre compte quand vous avez plusieurs politiques. Zendesk exécute d'abord les déclencheurs, puis compare le ticket à ses politiques SLA en parcourant la liste de haut en bas et applique la première dont les conditions sont remplies. Placez les politiques spécifiques, comme celle des clients grands comptes, au-dessus des politiques générales. Zendesk exige aussi que la priorité du ticket soit définie dans le champ de priorité système par défaut ; un champ de priorité personnalisé ne correspondra à aucune politique.

Zendesk définit le next reply time comme le temps entre le plus ancien commentaire client sans réponse et le commentaire public suivant d'un agent. Il propose aussi un indicateur periodic update, qui mesure le temps entre les commentaires publics des agents. Pour la résolution, Zendesk dispose de trois indicateurs et recommande de n'en choisir qu'un par politique : requester wait time (temps passé en New, Open et On-hold), agent work time (temps passé en New et Open) et total resolution time (tout le cycle de vie, de la création jusqu'à la résolution du ticket).

Freshdesk définit des objectifs first response, every response et resolution par priorité dans chaque politique SLA. Dans Jira Service Management, chaque SLA est un minuteur nommé : vous définissez quand il démarre, se met en pause et s'arrête, puis vous ajoutez des objectifs qui utilisent JQL pour choisir les demandes concernées, avec des délais cibles écrits sous la forme 4h 30m.

Les heures ouvrées ne comptent que le temps compris dans vos horaires de travail ; les heures calendaires comptent chaque heure de chaque jour. Zendesk vous permet de choisir heures ouvrées ou calendaires pour chaque priorité d'une politique. Freshdesk demande si chaque SLA doit utiliser les horaires d'ouverture que vous avez définis ou les heures calendaires (24x7). Jira Service Management associe à chaque objectif un calendrier, avec un fuseau horaire, des jours et des heures ouvrés, et des jours fériés.

Un objectif de 4 heures ouvrées sur un ticket créé tard le vendredi peut n'arriver à échéance que le lundi. C'est juste pour votre équipe, mais ce n'est pas ce que vit le client : utilisez donc les heures calendaires pour toute priorité où vous promettez une couverture jour et nuit.

La pause est l'autre moitié du sujet. Le temps passé à attendre le client ne devrait généralement pas compter contre vous, et chaque outil le gère différemment :

• Zendesk : le requester wait time se met en pause en Pending ; l'agent work time se met en pause en Pending et On-hold ; le total resolution time ne se met en pause sur aucun changement de statut jusqu'à la résolution du ticket.
• Freshdesk : le statut Pending met en pause les minuteurs SLA, et vous pouvez désactiver le minuteur SLA pour n'importe quel statut, y compris des statuts personnalisés comme Waiting on Third Party. Les tickets dont le minuteur est désactivé apparaissent comme On Hold, et quand le client répond, le ticket repasse en Open et le chronomètre reprend.
• Jira Service Management : un SLA peut avoir des conditions de pause, par exemple pendant que vous attendez la réponse du client, en plus de ses conditions de démarrage et d'arrêt.

Un SLA n'est utile que si quelqu'un agit avant qu'il ne soit manqué. Prévoyez un avertissement avant l'échéance et une escalade après :

• Zendesk : créez une automatisation avec la condition « Hours until next SLA breach » pour prévenir une équipe ou une personne quand un ticket approche du dépassement. Les automatisations s'exécutent une fois par heure : l'alerte peut donc arriver jusqu'à une heure avant ou après le seuil, jamais au moment exact. L'exemple de Zendesk ajoute un tag dans la même automatisation pour qu'elle ne se déclenche qu'une fois par ticket.
• Freshdesk : chaque politique SLA peut envoyer aux agents un rappel de 5 minutes à 4 heures avant l'échéance d'un objectif de première réponse ou de résolution, et escalader en cas de non-respect vers l'agent assigné ou d'autres personnes de votre choix, comme un chef d'équipe. Les deux se règlent dans Admin > Workflows > SLA Policies.
• Tout outil : envoyez les alertes de dépassement là où votre équipe regarde vraiment, comme un canal Slack, et pas seulement par e-mail.

• Zendesk : créez des politiques SLA avec des conditions et des objectifs par priorité, choisissez heures ouvrées ou calendaires pour chaque priorité, et ordonnez la liste pour que les politiques spécifiques viennent en premier. Ajoutez une automatisation pour les alertes de dépassement imminent.
• Freshdesk : dans Admin > Workflows > SLA Policies, définissez des objectifs first response, every response et resolution par priorité, choisissez heures ouvrées ou calendaires, puis ajoutez des rappels et des escalades. Décidez dans les paramètres de statut des tickets quels statuts désactivent le minuteur SLA.
• Jira Service Management : créez chaque SLA avec des conditions de démarrage, de pause et d'arrêt. Plusieurs conditions de démarrage se combinent avec OR, et le SLA s'arrête dès qu'une condition d'arrêt est remplie. Ajoutez ensuite des objectifs qui sélectionnent les demandes en JQL, définissez un délai cible et choisissez un calendrier.

Quel que soit l'outil, commencez par une politique et quelques priorités, faites-la tourner quelques semaines, puis comparez les délais réels de première réponse et de résolution aux objectifs avant de les resserrer.

TascaLab met en place l'automatisation liée aux SLA sur Zendesk, Freshdesk et Jira : un routage qui définit la priorité pour que la bonne politique s'applique, des alertes de dépassement vers Slack et des rapports SLA planifiés. Les tarifs ponctuels concernés sont Ticket Routing & Categorization (690 €), Automated Reports (620 €) et Custom Automation (à partir de 1 070 €). Les projets comprennent une documentation de base, 30 jours de support après le lancement et aucun frais caché, et la plupart prennent 1 à 3 semaines. Commencez par un appel Health Check gratuit de 30 minutes.