Comment configurer des automatisations d'escalade Zendesk par SLA : Un guide complet

Stevia Putri

Stanley Nicholas
Last edited 20 février 2026
Expert Verified
Les accords de niveau de service (SLA, Service Level Agreements) sont l'épine dorsale de toute opération de support sérieuse. Ils définissent des attentes claires avec les clients et donnent à votre équipe des objectifs mesurables. Mais voici le problème : que se passe-t-il lorsqu'un ticket est sur le point de violer son SLA ? Idéalement, vous souhaiteriez une escalade automatique pour alerter les bonnes personnes avant que le délai ne soit dépassé. Malheureusement, Zendesk ne rend pas cela simple.
Si vous avez recherché « automatisation d'escalade Zendesk par SLA », vous avez probablement découvert la même lacune que tout le monde. Zendesk peut vous avertir lorsqu'un SLA est violé, mais il ne peut pas déclencher nativement une automatisation basée sur « X minutes avant la violation ». C'est l'une des fonctionnalités les plus demandées dans la communauté Zendesk, avec des centaines de votes positifs sur la demande de fonctionnalité officielle.
La bonne nouvelle ? Il existe des solutions de contournement. Certaines sont natives de Zendesk, d'autres utilisent des outils tiers. Nous allons passer en revue chaque méthode afin que vous puissiez choisir celle qui convient le mieux à votre équipe. Et si vous recherchez une solution qui gère les escalades plus intelligemment, nous allons vous montrer comment nous abordons cela chez eesel AI.
Comprendre les limitations de l'automatisation SLA de Zendesk
Clarifions ce que Zendesk peut et ne peut pas faire avec les automatisations basées sur le SLA.
Zendesk propose deux types de règles métier : les déclencheurs et les automatisations. Les déclencheurs se déclenchent immédiatement lorsqu'un ticket est créé ou mis à jour. Les automatisations s'exécutent toutes les heures et peuvent agir sur des conditions basées sur le temps. Mais ni l'un ni l'autre ne peut se déclencher directement en fonction de violations spécifiques de la cible SLA.
La confusion découle souvent d'une condition appelée « Heures depuis la dernière violation de SLA ». Cela semble prometteur, mais cela vous indique seulement combien de temps s'est écoulé après qu'un SLA a déjà été violé. Cela ne peut pas vous dire « ce ticket sera violé dans 30 minutes ».
Pourquoi est-ce important ? Parce que les notifications réactives (après une violation) ne donnent pas à votre équipe le temps d'intervenir. Les escalades proactives (avant une violation) vous permettent de réaffecter, d'avertir ou de prendre des mesures pendant qu'il est encore temps de respecter l'engagement.
La demande de fonctionnalité officielle pour les déclencheurs d'automatisation basés sur le SLA est active depuis des années. La réponse de Zendesk a été cohérente : utilisez les solutions de contournement disponibles. C'est donc ce que nous allons aborder.
Nous adoptons une approche différente chez eesel. Plutôt que de lutter avec les déclencheurs d'automatisation basés sur le temps, notre coéquipier IA apprend vos règles d'escalade en langage clair. Vous lui dites simplement des choses comme « escalader les tickets des clients Enterprise s'ils n'ont pas reçu de réponse dans les 2 heures » et il s'occupe du reste. Aucun flux de travail complexe n'est nécessaire.
Prérequis pour les automatisations d'escalade SLA
Avant de configurer un flux de travail d'escalade, assurez-vous d'avoir les éléments suivants :
Exigences du plan Zendesk
- Zendesk Suite Professional (115 $/agent/mois) ou supérieur pour les politiques SLA
- Zendesk Suite Enterprise (169 $/agent/mois) pour les SLA de groupe
- Le plan Support Team (19 $/agent/mois) comprend les automatisations et les déclencheurs, mais pas les fonctionnalités SLA
Permissions et connaissances
- Accès administrateur à Zendesk (seuls les administrateurs peuvent créer des règles métier)
- Compréhension de la différence entre les déclencheurs et les automatisations
- Connaissance de la matrice d'escalade de votre équipe (qui doit être averti quand)
Intégrations facultatives
- Espace de travail Slack (pour les canaux de notification)
- Compte PagerDuty (pour l'escalade de garde)
- Compte n8n (pour les flux de travail avancés, à partir de 20 $/mois)
Testez tout d'abord dans un environnement de bac à sable. Zendesk propose des environnements de bac à sable sur les plans Enterprise, ou vous pouvez créer une vue de test pour surveiller les effets de l'automatisation avant de la déployer dans votre file d'attente principale.
Méthode 1 : Flux de travail d'escalade basé sur les groupes
Il s'agit de la solution de contournement native la plus fiable. Au lieu de se déclencher sur « SLA sur le point d'être violé », nous utilisons une combinaison d'automatisations et de déclencheurs pour déplacer les tickets vers un groupe d'escalade lorsque les conditions de temps sont remplies.
Étape 1 : Créer des politiques SLA
Tout d'abord, configurez les politiques SLA que vous souhaitez appliquer.
Accédez à Centre d'administration → Objets et règles → Règles métier → Accords de niveau de service. Cliquez sur « Créer une politique » et définissez vos cibles.
Principales décisions que vous devrez prendre :
- Quelles mesures suivre (Délai de première réponse, Délai de prochaine réponse ou Délai de résolution)
- Délais cibles pour chaque niveau de priorité (Urgent, Élevé, Normal, Faible)
- Heures ouvrables vs heures calendaires

Les heures ouvrables ne comptent que pendant votre horaire défini. Les heures calendaires comptent 24 h/24 et 7 j/7. La plupart des équipes utilisent les heures ouvrables pour le délai de première réponse et les heures calendaires pour le délai de résolution, mais cela dépend de vos engagements envers les clients.
Une fois vos politiques SLA actives, Zendesk commencera à suivre les cibles sur les tickets correspondants. Vous pouvez voir les badges SLA dans les vues de tickets et les pages de tickets individuelles.
Étape 2 : Créer le groupe « SLA violés »
Ensuite, créez un groupe dédié aux tickets escaladés.
Accédez à Centre d'administration → Personnes → Groupes et cliquez sur « Ajouter un groupe ». Nommez-le quelque chose de clair comme « SLA violés » ou « Escalades - Risque SLA ». Attribuez des agents qui traitent les problèmes escaladés. Il doit s'agir de votre personnel de support senior ou de vos chefs d'équipe.
Le groupe n'a pas besoin de beaucoup de membres. Son objectif est de signaler visuellement les tickets et d'activer les notifications basées sur les déclencheurs. Vous pouvez avoir aussi peu qu'un seul agent dans ce groupe si cette personne gère toutes les escalades.
Étape 3 : Configurer l'automatisation
Créez maintenant l'automatisation qui déplace les tickets vers votre groupe d'escalade.
Accédez à Centre d'administration → Objets et règles → Règles métier → Automatisations. Cliquez sur « Ajouter une automatisation ».
Conditions à définir :
- « Heures depuis la mise à jour du demandeur » est supérieur à X (définissez cela en fonction de votre seuil de risque)
- Le statut est Ouvert (n'escaladez pas les tickets En attente ou En suspens)
- Le ticket n'est pas dans le groupe « SLA violés » (empêche la réexécution)
Actions à entreprendre :
- Ajouter la balise « sla_breach_risk » (pour le suivi)
- Changer le groupe en « SLA violés »

Cette automatisation s'exécute toutes les heures. Lorsqu'elle trouve des tickets correspondant à vos conditions, elle les déplace vers le groupe d'escalade. La limitation ? Vous utilisez « heures depuis la mise à jour » comme proxy pour « approche de la violation du SLA », ce qui n'est pas exact. Mais c'est ce qui se rapproche le plus de ce que vous pouvez obtenir avec les outils Zendesk natifs.
Étape 4 : Créer le déclencheur pour les notifications
Enfin, configurez un déclencheur pour avertir les personnes lorsque les tickets entrent dans le groupe d'escalade.
Accédez à Centre d'administration → Objets et règles → Règles métier → Déclencheurs. Cliquez sur « Ajouter un déclencheur ».
Conditions :
- Groupe changé en « SLA violés »
- Les balises contiennent « sla_breach_risk »
Actions :
- Envoyer un e-mail au groupe « SLA violés » (avertit les agents affectés)
- Facultatif : Avertir la cible (Webhook Slack ou PagerDuty)
- Ajouter une note interne : « Ce ticket a été escaladé en raison de l'approche de la violation du SLA »
Testez ce flux de travail en profondeur. Créez un ticket de test, laissez-le reposer et vérifiez que l'automatisation le déplace et que le déclencheur envoie des notifications. Ajustez le seuil « heures depuis la mise à jour » jusqu'à ce qu'il attrape les tickets au bon moment.
Méthode 2 : Surveillance proactive du SLA avec n8n
Pour les équipes ayant besoin d'un contrôle plus précis, n8n offre une alternative puissante. n8n est une plateforme d'automatisation de flux de travail qui peut interroger l'API Zendesk toutes les heures, calculer les pourcentages exacts de SLA et déclencher des notifications à des seuils précis.
Voici comment cela fonctionne :
Le flux de travail s'exécute toutes les heures. Il récupère tous les tickets ouverts de Zendesk via l'API, y compris leurs horodatages created_at et sla_due. Pour chaque ticket, il calcule le pourcentage de temps SLA écoulé à l'aide de cette formule : percentElapsed = (1 - remaining/total) × 100.
À 75 % écoulé, il envoie un avertissement à votre canal Slack. À 90 % écoulé, il met à jour la priorité du ticket à « Élevée » dans Zendesk et alerte l'équipe pour une action immédiate. Tous les événements sont consignés dans Google Sheets pour la création de rapports de conformité.
Les plans hébergés de n8n commencent à 20 $/mois pour 2 500 exécutions. Chaque exécution compte comme une exécution complète du flux de travail, quel que soit le nombre de tickets qu'elle traite. Pour la plupart des équipes de support, cela signifie que vous pouvez surveiller des centaines de tickets toutes les heures sur le plan Starter.
Le principal avantage par rapport aux solutions de contournement natives de Zendesk ? La précision. Vous êtes averti à exactement 75 % et 90 % du SLA écoulé, pas « quelque temps après X heures ». Le compromis est la complexité. Vous devez configurer et maintenir le flux de travail, gérer les informations d'identification de l'API et surveiller l'instance n8n.
Choisissez cette méthode si :
- Vous avez du personnel d'exploitation ou technique dédié
- La précision du SLA est essentielle pour votre entreprise
- Vous avez besoin de journaux d'audit pour la conformité
Tenez-vous-en aux solutions de contournement natives de Zendesk si :
- Vous préférez la simplicité à la précision
- Vous n'avez pas de ressources techniques
- La granularité horaire est suffisante
Utilisation des SLA de groupe pour le suivi interne des escalades
Si vous êtes sur Zendesk Enterprise (169 $/agent/mois), vous avez accès aux SLA de groupe. Ceux-ci mesurent la responsabilité interne de l'équipe, également connue sous le nom d'accords de niveau opérationnel (OLA, Operational Level Agreements).
Alors que les SLA standard suivent les engagements envers les clients, les SLA de groupe suivent combien de temps les tickets restent avec les équipes internes. Ils mesurent le Délai de propriété du groupe : le temps écoulé entre le moment où un ticket est attribué à un groupe et le moment où il est réattribué ou résolu.

Les SLA de groupe sont utiles pour les flux de travail multi-départementaux. Par exemple :
- Les équipes informatiques suivent combien de temps les tickets restent avec l'équipe d'infrastructure
- Les équipes financières mesurent les délais d'approbation
- Les équipes de produits surveillent combien de temps les escalades restent avec l'ingénierie
La configuration des SLA de groupe est similaire aux SLA standard. Accédez à Centre d'administration → Objets et règles → Règles métier → Accords de niveau de service, puis sélectionnez l'onglet « SLA de groupe ». Créez une politique, sélectionnez les groupes cibles et définissez les délais cibles de propriété.
Limitations importantes :
- Les SLA de groupe ne peuvent pas faire la distinction entre l'attribution et l'escalade. Ils mesurent simplement le temps passé avec le groupe.
- Ils se réinitialisent lorsque les tickets sont réattribués. Si un ticket passe de l'équipe A à l'équipe B et revient à l'équipe A, l'équipe A obtient un nouveau chronomètre de propriété.
- Ils ne déclenchent pas d'automatisations. Vous avez toujours besoin de la solution de contournement basée sur les groupes décrite précédemment pour les notifications.
Les SLA de groupe fonctionnent mieux pour la création de rapports et la responsabilité post-hoc, pas pour les déclencheurs d'escalade en temps réel.
Solutions et intégrations tierces
Plusieurs outils tiers peuvent combler les lacunes d'escalade SLA de Zendesk. Voici une comparaison :
| Solution | Approche | Tarification | Idéal pour |
|---|---|---|---|
| SweetHawk Suite | Applications Zendesk natives | 12 $/agent/mois | Les équipes souhaitant une fonctionnalité Zendesk native |
| Flux de travail n8n | Automatisation basée sur l'API | 20-800 $/mois | Les équipes techniques ayant besoin d'une logique personnalisée |
| PagerDuty | Escalade de garde | 25-49 $/utilisateur/mois | Les équipes avec des rotations de garde |
| eesel AI | Règles d'escalade basées sur l'IA | 299-799 $/mois | Les équipes souhaitant des règles intelligentes en langage clair |
SweetHawk Suite
SweetHawk fabrique les applications Zendesk les plus populaires pour l'automatisation des flux de travail. Leur application Timers (2 $/agent/mois) et la SweetHawk Suite complète (12 $/agent/mois) ajoutent une application SLA améliorée directement dans Zendesk.

Contrairement à Zendesk natif, les applications SweetHawk peuvent créer des règles basées sur le temps plus sophistiquées. Elles sont conçues exclusivement pour Zendesk, donc la configuration prend quelques minutes et l'interface est native. SweetHawk est approuvé par plus de 12 000 organisations, dont Amazon, eBay et Twilio.
Intégration PagerDuty
Si votre processus d'escalade implique de réveiller des ingénieurs de garde, PagerDuty s'intègre directement à Zendesk. Lorsque les tickets violent le SLA ou remplissent certaines conditions, PagerDuty peut envoyer un message à l'équipe de garde par téléphone, SMS ou notification push.

Les plans PagerDuty commencent à 25 $/utilisateur/mois pour le niveau Professional, qui comprend l'intégration de Slack et Microsoft Teams, les pages d'état externes et l'automatisation de base. Le niveau Business (49 $/utilisateur/mois) ajoute des champs personnalisés, des flux de travail avancés et l'intégration de ServiceNow.
eesel AI
Nous pensons différemment aux escalades. Au lieu de créer des règles d'automatisation complexes, vous embauchez un coéquipier IA qui apprend vos politiques d'escalade en langage clair.

Voici comment cela fonctionne : vous connectez notre IA à votre service d'assistance et vous lui indiquez vos règles. « Escalader immédiatement les litiges de facturation de plus de 1 000 $ à l'équipe des finances. » « Si le ticket d'un client VIP n'a pas reçu de réponse dans les 30 minutes, avertir le gestionnaire de compte. » Notre IA gère la surveillance et l'escalade automatiquement.
Avant de passer en direct, vous pouvez simuler notre IA sur des milliers de tickets passés pour vérifier qu'elle comprend correctement vos règles. Une fois en direct, elle apprend des corrections. Si une escalade n'était pas nécessaire, dites-le nous et nous nous ajusterons.
Notre Agent IA gère jusqu'à 81 % des tickets de manière autonome dans les déploiements matures, en escaladant uniquement ce que vous définissez. Le produit Triage IA balise, achemine et hiérarchise les tickets en fonction du contenu, pas seulement du temps écoulé.
| Méthode | Complexité de la configuration | Précision | Idéal pour |
|---|---|---|---|
| Solution de contournement Zendesk native | Faible | Moyenne | Besoins d'escalade simples |
| Flux de travail n8n | Élevée | Élevée | Équipes techniques avec des ressources de développement |
| Applications SweetHawk | Faible | Élevée | Expérience native de Zendesk |
| PagerDuty | Moyenne | Élevée | Gestion des incidents de garde |
| eesel AI | Faible | Très élevée | Escalade intelligente basée sur des règles |
Bonnes pratiques pour la gestion des escalades SLA
Quelle que soit la méthode que vous choisissez, suivez ces pratiques pour que vos escalades restent efficaces :
Définissez des cibles SLA réalistes avant d'automatiser. Si votre équipe manque systématiquement les SLA, l'escalade plus agressive n'aidera pas. Corrigez d'abord la cause profonde.
Utilisez des vues basées sur le SLA pour la surveillance manuelle. Créez des vues triées par « Prochaine violation du SLA » par ordre croissant. Les agents peuvent voir les tickets à risque en un coup d'œil, même sans automatisation.
Testez d'abord dans le bac à sable. Zendesk Enterprise comprend des environnements de bac à sable. Testez votre logique d'automatisation là-bas avant d'affecter de vrais tickets.
Documentez votre matrice d'escalade. Écrivez qui est averti quand et pour quels types de tickets. Cela évite la confusion et assure la couverture pendant les vacances ou le roulement du personnel.
Surveillez les taux d'escalade. Si 50 % des tickets sont escaladés, vos seuils sont trop agressifs. Si aucun n'est escaladé, vos SLA peuvent être trop indulgents. Visez un petit pourcentage exploitable.
Tenez les clients informés. Les escalades automatisées ne doivent pas être invisibles. Utilisez des déclencheurs pour envoyer des mises à jour comme « Votre ticket a été escaladé à notre équipe senior pour une résolution plus rapide. »
Examinez et ajustez trimestriellement. Les besoins en SLA changent à mesure que votre équipe et votre produit évoluent. Planifiez des examens trimestriels de vos politiques et règles d'automatisation.
Créez des flux de travail d'escalade plus intelligents avec l'IA
Les limitations natives de Zendesk concernant les automatisations basées sur le SLA sont bien connues et bien documentées. Les solutions de contournement que nous avons abordées (flux de travail basés sur les groupes, intégrations n8n, SLA de groupe et applications tierces) résolvent chacune une partie du problème, mais elles nécessitent toutes des compromis entre la simplicité et la précision.
Nous pensons que la gestion des escalades devrait être plus simple. Au lieu de configurer des flux de travail complexes, vous devriez être en mesure de définir des règles d'escalade de la même manière que vous les expliqueriez à un nouveau membre de l'équipe : en langage clair.
Avec notre IA, vous pouvez :
- Définir les règles d'escalade naturellement : « Toujours escalader les tickets des clients Enterprise après 2 heures »
- Simuler sur les tickets passés avant de passer en direct pour vérifier que les règles fonctionnent
- Commencer par l'IA qui rédige des réponses pour examen, puis passer à la gestion autonome complète
- Gérer les tickets de routine de bout en bout, en escaladant uniquement ce qui nécessite réellement l'attention humaine
Notre approche ne consiste pas à ajouter une autre couche d'automatisation. Il s'agit d'apporter de l'intelligence à votre processus d'escalade. Notre IA apprend votre entreprise à partir de vos tickets passés, de vos macros et de votre centre d'aide. Elle comprend le contexte, pas seulement les horodatages.
Si vous en avez assez de lutter avec les solutions de contournement de Zendesk et que vous voulez voir comment l'IA peut gérer les escalades plus intelligemment, essayez eesel AI ou réservez une démonstration pour la voir en action sur votre historique de tickets réel. Consultez notre guide sur l'agent IA pour le service d'assistance pour en savoir plus sur la gestion intelligente des tickets, ou lisez l'article sur les escalades d'agent IA Zendesk pour en savoir plus sur les flux de travail d'escalade plus intelligents.
Foire aux questions
Partager cet article

Article by
Stevia Putri
Stevia Putri is a marketing generalist at eesel AI, where she helps turn powerful AI tools into stories that resonate. She’s driven by curiosity, clarity, and the human side of technology.


