Délais de support : alerter avant que le SLA saute

Un engagement de délai de réponse, ce qu’on appelle un SLA (Service Level Agreement, accord de niveau de service), tient en une ligne de contrat : « réponse sous quatre heures ouvrées pour un incident bloquant ». Le tenir est une autre affaire. Les tickets arrivent par vagues, certains tombent dans une file que personne ne regarde, d’autres attendent une réponse d’un collègue. Le délai saute sans que personne ne l’ait décidé.

Les outils de support affichent souvent l’âge des tickets. Ils préviennent moins bien avant qu’il soit trop tard. Cet article fait partie du cocon Workflows n8n : ce que chaque service peut automatiser, rubrique support.

Pourquoi les délais sautent

Les délais sautent rarement parce qu’un agent refuse de répondre. Ils sautent pour des raisons d’organisation. Un ticket arrive en dehors des heures, et le lendemain matin il est sous trente autres. Un agent part en congé avec des tickets assignés. Une question attend la réponse d’un expert d’un autre service, qui n’a pas vu la demande. Le ticket n’a pas de propriétaire, chacun pense qu’un autre s’en occupe.

Chacune de ces causes laisse un signal lisible : un ticket non assigné, un ticket dont l’agent est absent, un ticket en attente interne depuis longtemps. Le workflow les lit avant que le client ne s’en plaigne.

Les paliers d’alerte

1. Ticket sans propriétaire

   Alerte immédiate au responsable de la file.

2. À mi-délai

   Un rappel discret à l’agent assigné.

3. Peu avant l’échéance

   Une alerte à l’agent et à son responsable.

4. Délai dépassé

   Le ticket monte au responsable, et le client reçoit un message honnête sur le délai.

Les seuils se règlent par niveau de priorité. Un incident bloquant n’a pas le même délai qu’une question de facturation. Le workflow lit la priorité du ticket, le contrat du client si les délais varient selon les clients, et applique le bon calendrier.

Le déclencheur planifié de n8n fait tourner ce contrôle à intervalle court pendant les heures de support. Les heures ouvrées, les fuseaux horaires et les jours fériés entrent dans le calcul : un délai de quatre heures ouvrées posé un vendredi soir ne tombe pas le samedi.

Une alerte qui aide, pas qui accuse

La manière dont l’alerte est reçue compte. Une équipe de support qui vit chaque alerte comme un reproche apprend à fermer des tickets trop vite, pour sortir du compteur. Une alerte qui arrive tôt, chez l’agent d’abord, avec une proposition de réassignation quand il est absent, aide à tenir la promesse sans tension.

Ce que le workflow ne fait pas

Il ne répond pas au client à la place de l’agent. Une réponse automatique « nous avons bien reçu votre demande » est utile à l’arrivée du ticket. Elle n’en est pas une sur le fond, et l’envoyer pour arrêter le compteur reviendrait à tricher avec le contrat. Le tri des tickets entrants et la proposition de réponse par l’IA sont un autre sujet, traité dans Automatiser le support client : l’IA trie, l’humain relit. Les deux se complètent : un ticket bien trié arrive plus vite à la bonne personne, et l’alerte veille à ce qu’il ne reste pas en attente.

Le rapport du mois

Une fois par mois, le workflow produit un relevé simple : tickets traités dans le délai, tickets en retard, et pour ces derniers la cause enregistrée (non assigné, attente interne, absence, pic de charge). Ce relevé dit où agir. Une majorité de retards en « attente interne » appelle une règle avec les autres services, pas un effort de plus du support.

Ces causes se croisent utilement avec les retours des clients. Les commentaires de l’enquête de satisfaction disent si les retards sont ressentis, et sur quels sujets.

Pour surveiller vos délais de support avec vos priorités et vos contrats, notre offre d’automatisation n8n part de votre outil de support et des engagements que vous avez pris.

Questions fréquentes

Sources

1. Schedule Trigger, documentation n8n (nouvel onglet)docs.n8n.io