Conditions de filtre des politiques SLA Zendesk : Un guide complet
Stevia Putri
Stanley Nicholas
Last edited 20 février 2026
Expert Verified
Se tromper dans vos politiques SLA dans Zendesk signifie soit noyer votre équipe sous des objectifs inatteignables, soit laisser passer des tickets critiques. Les deux scénarios se terminent de la même manière : des clients frustrés et des agents stressés.
Les conditions de filtre que vous définissez pour chaque politique SLA déterminent à quels tickets s’appliquent les accords de niveau de service. Si vous faites bien les choses, votre équipe a des objectifs clairs et réalisables. Si vous vous trompez, vous promettez trop ou vous ne livrez pas assez.
Ce guide vous explique tout ce que vous devez savoir sur les conditions de filtre des politiques SLA Zendesk. Vous découvrirez les types de conditions disponibles, comment les structurer pour différents scénarios et les meilleures pratiques pour que vos SLA travaillent pour vous plutôt que contre vous.
Que sont les conditions de filtre des politiques SLA Zendesk ?
Les conditions de filtre des politiques SLA sont les règles qui déterminent à quels tickets s’applique un accord de niveau de service particulier. Considérez-les comme les gardiens : lorsqu’un ticket correspond aux conditions, la politique SLA s’active et commence à suivre ses objectifs.
Chaque condition de filtre dans Zendesk suit la même structure : un champ à vérifier, un opérateur avec lequel comparer et une valeur à faire correspondre. Voici à quoi cela ressemble :
{ "field": "type", "operator": "is", "value": "incident" }
Les filtres sont organisés en deux tableaux logiques :
| Tableau | Logique | Ce que cela signifie |
|---|---|---|
| all | AND | Chaque condition de ce tableau doit être vraie pour que le ticket corresponde |
| any | OR | Au moins une condition de ce tableau doit être vraie pour que le ticket corresponde |
L’ordre de vos politiques SLA est important. Zendesk les évalue de haut en bas et applique la première politique dont les conditions correspondent. Cela signifie que vos politiques les plus spécifiques doivent se trouver en haut, avec des politiques de rattrapage plus larges en bas.
Les mesures de politique définissent ce que vous mesurez réellement : premier délai de réponse, prochain délai de réponse, délai de résolution, etc. Chaque mesure peut avoir des objectifs différents en fonction de la priorité du ticket. Vous pouvez également choisir de ne compter que les heures ouvrables ou les heures calendaires 24 heures sur 24.
Types de conditions de filtre des politiques SLA Zendesk disponibles
Zendesk offre une vaste gamme de conditions pour cibler les tickets. Celles-ci se répartissent en deux catégories : les conditions partagées entre les règles de gestion (déclencheurs, automatisations, vues et SLA) et les conditions spécifiques aux politiques SLA. Pour des détails techniques complets, consultez la Référence des conditions Zendesk.
Conditions partagées
Ces conditions fonctionnent sur les politiques SLA, les déclencheurs, les automatisations et les vues :
| Champ | Opérateurs | Ce qu’il filtre |
|---|---|---|
| group_id | is, is_not | Tickets attribués à des groupes d’agents spécifiques |
| assignee_id | is, is_not | Tickets attribués à des agents spécifiques |
| requester_id | is, is_not | Tickets provenant de demandeurs spécifiques |
| organization_id | is, is_not | Tickets provenant d’organisations spécifiques |
| current_tags | includes, not_includes | Tickets avec ou sans balises spécifiques |
| via_id | is, is_not | Tickets créés via des canaux spécifiques |
| recipient | - | L’adresse e-mail à laquelle le ticket a été envoyé |
| custom_fields_{id} | is, is_not | Valeurs de champ de ticket personnalisé |
Conditions spécifiques aux SLA
Ces conditions ne sont disponibles que dans les filtres de politique SLA :
| Champ | Opérateurs | Ce qu’il filtre |
|---|---|---|
| ticket_type_id | is, is_not | Question (1), Incident (2), Problème (3) ou Tâche (4) |
| current_via_id | is, is_not | Canal utilisé pour la mise à jour la plus récente |
| exact_created_at | less_than, greater_than, etc. | Horodatage de la création du ticket |
| custom_status_id | is, is_not | Valeurs d’état de ticket personnalisé |
La distinction entre via_id et current_via_id mérite d’être notée. La condition via_id vérifie comment le ticket a été créé à l’origine, tandis que current_via_id vérifie comment la mise à jour la plus récente a été effectuée. Cela est important si vous souhaitez faire la distinction entre les tickets qui ont commencé par e-mail et ceux qui sont passés au chat, par exemple.
Comment créer des conditions de filtre de politique SLA Zendesk efficaces
La création de politiques SLA qui fonctionnent réellement nécessite une planification. Voici une approche pratique.
Étape 1 : Planifiez la structure de votre politique
Avant de toucher à Zendesk, cartographiez votre structure de support :
- Quels segments de clientèle ont besoin de délais de réponse différents ? (VIP, entreprise, niveau gratuit)
- Quels canaux ont des attentes différentes ? (chat contre e-mail)
- Les différents types de tickets justifient-ils des traitements différents ? (incidents contre questions)
- Quelles équipes gèrent quels types de travail ?
Cette cartographie devient la structure de votre politique. Chaque combinaison unique reçoit sa propre politique.
Étape 2 : Accédez au générateur de politiques SLA
Dans votre Centre d’administration Zendesk, accédez à Objets et règles > Règles de gestion > Accords de niveau de service. Cliquez sur Créer une politique pour commencer à créer. Pour des instructions de configuration détaillées, consultez la documentation officielle de la politique SLA Zendesk.
Étape 3 : Configurez vos conditions de filtre
Commencez par les conditions « Toutes ». Ce sont vos critères obligatoires. Par exemple, si cette politique s’applique uniquement aux clients VIP, ajoutez : Organisation est « Clients VIP ».
Ajoutez ensuite des conditions « Toutes » pour les critères facultatifs. Vous voudrez peut-être que la politique s’applique si le ticket est marqué « urgent » OU provient d’une organisation spécifique.
Les combinaisons de conditions courantes comprennent le filtrage basé sur l’organisation pour les SLA de niveau client, le filtrage basé sur le groupe pour les SLA internes spécifiques à l’équipe, le filtrage basé sur le canal pour différentes attentes de réponse et le filtrage basé sur les balises pour un routage flexible.
Étape 4 : Configurez vos mesures de politique
Choisissez les mesures à suivre pour cette politique :
| Mesure | Idéal pour |
|---|---|
| Premier délai de réponse | Accusé de réception initial du client |
| Prochain délai de réponse | Réactivité de la conversation en cours |
| Délai d’attente du demandeur | Délai d’attente total du client |
| Délai de résolution total | Résolution complète du problème |
| Délai de mise à jour périodique | Tenir les clients informés pendant les longues enquêtes |
Définissez des objectifs pour chaque niveau de priorité. Un point de départ courant est :
| Priorité | Première réponse | Prochaine réponse |
|---|---|---|
| Urgent | 15 minutes | 30 minutes |
| Élevée | 1 heure | 2 heures |
| Normale | 4 heures | 8 heures |
| Faible | 24 heures | 48 heures |
Choisissez les heures ouvrables si votre équipe n’offre pas de support 24 heures sur 24, 7 jours sur 7. Cela garantit que vous ne comptez que le temps où les agents sont réellement disponibles pour travailler.
Exemples courants de conditions de filtre de politique SLA Zendesk
La théorie est utile, mais des exemples concrets facilitent la mise en œuvre. Voici quatre scénarios courants.
Exemple 1 : Politique client VIP
Pour les clients ayant des contrats de support premium :
Toutes les conditions :
- Organisation est « Clients VIP » OU Les balises incluent « support-premium »
Mesures :
| Priorité | Première réponse | Prochaine réponse |
|---|---|---|
| Urgent | 15 minutes | 30 minutes |
| Élevée | 30 minutes | 1 heure |
| Normale | 1 heure | 2 heures |
Placez cette politique en haut de votre liste afin que les tickets VIP soient interceptés avant vos politiques générales.
Exemple 2 : Politiques spécifiques au canal
Différents canaux ont des attentes différentes. Une conversation par chat exige une réponse plus rapide qu’un e-mail.
Politique de messagerie (Toutes les conditions) :
- Via est « Chat » OU Via est « Messagerie »
Politique de messagerie électronique (Toutes les conditions) :
- Via est « E-mail »
Définissez vos objectifs de messagerie de manière plus agressive que l’e-mail. Les clients s’attendent à une réponse quasi instantanée par chat, mais sont plus patients avec l’e-mail.
Exemple 3 : SLA d’équipe interne avec les SLA de groupe
Les SLA de groupe suivent les performances de l’équipe interne plutôt que les mesures axées sur le client. Ils sont disponibles sur les plans Enterprise uniquement.
Filtre SLA de groupe :
- Groupe est « Support de niveau 2 »
La seule mesure disponible pour les SLA de groupe est le temps d’appartenance au groupe, qui mesure combien de temps un ticket reste avec ce groupe avant d’être résolu ou réattribué.
Exemple 4 : Chemin d’escalade pour les incidents
Les incidents critiques nécessitent un suivi strict :
Toutes les conditions :
- Priorité est « Urgent » ET Type est « Incident »
Ajoutez des objectifs de mise à jour périodique pour vous assurer que les clients reçoivent des mises à jour de progression même avant la résolution.
Meilleures pratiques et dépannage pour les conditions de filtre de politique SLA Zendesk
Même les politiques SLA bien planifiées peuvent rencontrer des problèmes. Voici comment éviter les pièges courants.
Ordre des politiques
L’erreur la plus courante est un mauvais ordre des politiques. N’oubliez pas : Zendesk applique la première politique correspondante et cesse de chercher. Si vous avez une politique spécifique pour les clients VIP, elle doit apparaître avant votre politique générale « tous les tickets ».
Ordre recommandé :
- Politiques client VIP/entreprise
- Politiques de canal spécifiques (chat, téléphone)
- Politiques de type de ticket spécifiques (incidents)
- Politiques générales (de rattrapage)
Un ordre approprié garantit que les bons tickets obtiennent les bons niveaux de service.
Utilisation de déclencheurs avec les SLA
Un modèle efficace consiste à utiliser des déclencheurs pour définir la priorité du ticket avant l’évaluation du SLA. Cela simplifie vos conditions SLA.
Par exemple, créez un déclencheur qui définit la priorité sur « Urgent » si :
- L’objet contient « panne » OU
- L’organisation est « Clients VIP »
Ensuite, vos politiques SLA peuvent simplement filtrer par priorité plutôt que de gérer des combinaisons de conditions complexes.
Test avant la mise en service
Testez toujours les nouvelles politiques SLA avec des exemples de tickets avant de les activer. Vérifiez que :
- Les bons tickets correspondent aux bonnes politiques
- Les politiques s’appliquent dans le bon ordre
- Les objectifs sont réalistes en fonction des données historiques
Problèmes courants et solutions
| Problème | Cause probable | Solution |
|---|---|---|
| La politique ne s’applique pas | Ordre incorrect ou erreur de logique | Vérifiez que les politiques plus spécifiques apparaissent en premier ; vérifiez la logique ET/OU |
| Plusieurs politiques semblent s’appliquer | Seule la première correspondance compte | Examinez l’ordre ; déterminez si les conditions sont trop larges |
| L’horloge SLA semble incorrecte | Erreur de configuration des heures ouvrables | Vérifiez l’attribution de l’horaire et les paramètres des heures ouvrables |
| Conflits SLA de groupe | Confusion entre les SLA réguliers et les SLA de groupe | N’oubliez pas qu’ils suivent séparément ; les SLA de groupe ne mesurent que le temps d’appartenance |
Pour des conseils de dépannage supplémentaires, consultez ces meilleures pratiques en matière de politique SLA.
Gestion des SLA à grande échelle avec l’IA
À mesure que vos opérations de support se développent, la gestion manuelle des politiques SLA devient plus difficile. Vous devez surveiller les performances, repérer les tendances et ajuster les objectifs en fonction des données réelles.
C’est là que les outils basés sur l’IA peuvent vous aider. Chez eesel AI, nous sommes spécialisés dans l’amélioration de l’efficacité des opérations de support grâce à l’automatisation intelligente.
Notre IA peut analyser le contenu de votre ticket et suggérer automatiquement des ajustements de priorité avant l’évaluation du SLA. Au lieu de s’appuyer uniquement sur des déclencheurs manuels, l’IA lit le contexte du ticket pour identifier les signaux d’urgence qui pourraient être manqués.
Pour les équipes qui ont du mal avec les violations de SLA, notre plateforme fournit des alertes proactives avant que les objectifs ne soient manqués, et non après. Cela donne aux agents le temps de prioriser les bons tickets plutôt que de réagir aux violations.
Nous nous intégrons directement à Zendesk, de sorte que vos politiques SLA existantes continuent de fonctionner tandis que la couche d’IA ajoute de l’intelligence par-dessus. Si vous souhaitez explorer comment l’IA peut optimiser votre gestion des SLA, vous pouvez en savoir plus sur nos capacités d’agent IA.
Tirer le meilleur parti de vos SLA Zendesk
Les politiques SLA bien configurées transforment le fonctionnement de votre équipe de support. Elles remplacent les instructions vagues « répondre rapidement » par des objectifs clairs et mesurables. Elles donnent à la direction une visibilité sur les performances. Et elles définissent les attentes des clients que votre équipe peut constamment satisfaire.
Les conditions de filtre que vous définissez sont le fondement. Prenez le temps de les planifier correctement, de les tester minutieusement et de les examiner régulièrement en fonction des données de performance.
Si vous cherchez à faire progresser vos opérations de support, réfléchissez à la façon dont l’IA peut augmenter votre configuration Zendesk existante. Nous avons créé eesel AI pour aider les équipes à gérer des volumes de support croissants sans augmenter proportionnellement les effectifs. Vous pouvez essayer eesel gratuitement ou réserver une démonstration pour voir comment cela fonctionne avec votre flux de travail spécifique.
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.
