Comment utiliser le filtre d'accord de niveau de service (SLA) de groupe Zendesk par ID de groupe : un guide complet

Stevia Putri

Stanley Nicholas
Last edited 20 février 2026
Expert Verified
Gérer les performances de l'équipe interne dans Zendesk peut donner l'impression de tâtonner sans les bonnes mesures. Alors que les politiques d'accord de niveau de service (SLA) standard suivent la rapidité avec laquelle vous répondez aux clients, elles ne vous indiquent pas avec quelle efficacité vos équipes internes gèrent les transferts et les escalades. C'est là que les politiques d'accord de niveau de service (SLA) de groupe entrent en jeu.
Les accords de niveau de service (SLA) de groupe vous permettent de définir des objectifs spécifiques quant à la durée pendant laquelle une équipe doit posséder un ticket avant de le résoudre ou de le transmettre. La clé pour les faire fonctionner ? Filtrer par ID de groupe. Ce guide vous explique exactement comment configurer des politiques d'accord de niveau de service (SLA) de groupe avec des filtres d'ID de groupe appropriés, de la recherche de vos ID à la configuration de politiques qui favorisent réellement la responsabilisation.

Ce dont vous aurez besoin
Avant de vous lancer, assurez-vous d'avoir les bases couvertes :
- Un forfait Zendesk Enterprise ou Enterprise Plus (les accords de niveau de service (SLA) de groupe ne sont pas disponibles dans les niveaux inférieurs)
- Un accès administrateur à votre compte Zendesk
- Les ID de groupe pour les équipes que vous souhaitez suivre
- Une idée approximative des objectifs de temps de propriété qui ont du sens pour votre flux de travail
Si vous utilisez Professional ou Suite Growth, vous pouvez toujours utiliser les accords de niveau de service (SLA) standard pour les mesures destinées aux clients, telles que le délai de première réponse et le délai de résolution. Mais les accords de niveau de service (SLA) de groupe, qui suivent le temps de propriété du groupe interne, nécessitent cette mise à niveau Enterprise.
Comprendre les politiques d'accord de niveau de service (SLA) de groupe par rapport aux accords de niveau de service (SLA) standard
Les politiques d'accord de niveau de service (SLA) standard dans Zendesk mesurent les engagements envers les clients : la rapidité avec laquelle vous répondez pour la première fois, la rapidité avec laquelle vous répondez aux suivis et le temps nécessaire pour résoudre complètement un problème. Ceux-ci s'appliquent aux tickets en fonction de conditions telles que la priorité, le canal ou le type de client.
Les accords de niveau de service (SLA) de groupe fonctionnent différemment. Au lieu de suivre les temps d'attente des clients, ils mesurent les performances de l'équipe interne grâce à une seule mesure : le temps de propriété du groupe (group ownership time). Cela permet de suivre le temps pendant lequel un ticket reste avec un groupe d'agents spécifique avant que le groupe ne le résolve ou ne le réaffecte ailleurs.
Voici pourquoi c'est important. Imaginez que votre équipe de support de niveau 1 transmet les problèmes complexes au niveau 2. Vous voulez que le niveau 1 tente un dépannage initial, mais vous voulez également que les escalades se fassent rapidement. Un accord de niveau de service (SLA) de groupe peut définir un objectif tel que « Le niveau 1 doit résoudre ou escalader les tickets urgents dans les 30 minutes. » Sans cela, les tickets pourraient rester dans la file d'attente du niveau 1 pendant des heures pendant que les clients attendent.
La principale différence dans la configuration ? Les politiques d'accord de niveau de service (SLA) de groupe nécessitent un filtre group_id. Vous ne pouvez pas en créer un sans spécifier à quels groupes il s'applique. Les accords de niveau de service (SLA) standard peuvent utiliser des conditions plus larges telles que « La priorité est élevée » ou « Le canal est l'e-mail ».

Étape 1 : Trouvez vos ID de groupe Zendesk
Vous ne pouvez pas configurer les accords de niveau de service (SLA) de groupe sans connaître vos ID de groupe. Voici trois façons de les trouver.
Méthode 1 : Via l'URL du Centre d'administration (la plus simple)
Accédez à Centre d'administration > Personnes > Groupes. Vous verrez une liste de tous vos groupes d'agents. Cliquez sur n'importe quel groupe pour ouvrir sa page de modification. Regardez l'URL dans votre navigateur : l'ID de groupe est le nombre à la fin.
https://your-subdomain.zendesk.com/admin/people/teams/groups/10001/edit
Dans cet exemple, l'ID de groupe est 10001.
Méthode 2 : Via l'API Groupes
Si vous devez récupérer tous les ID de groupe par programmation, utilisez le point de terminaison Liste des groupes :
GET /api/v2/groups.json
Cela renvoie une réponse JSON avec tous les groupes et leurs ID. Vous aurez besoin d'un jeton API et des informations d'identification appropriées pour y accéder.
Méthode 3 : Exporter depuis le Centre d'administration
Certains forfaits Zendesk permettent d'exporter les données de groupe depuis le Centre d'administration. Consultez Centre d'administration > Personnes > Groupes pour une option d'exportation si vous avez besoin d'une feuille de calcul de tous les groupes et ID.
Conseil de pro : Créez un document de référence partagé avec les noms et les ID de groupe. Votre équipe aura besoin de ces ID non seulement pour les accords de niveau de service (SLA) de groupe, mais aussi pour les déclencheurs, les automatismes et les intégrations API.
Étape 2 : Créez une politique d'accord de niveau de service (SLA) de groupe avec un filtre d'ID de groupe
Passons maintenant à la configuration proprement dite. Voici comment créer une politique d'accord de niveau de service (SLA) de groupe qui filtre par ID de groupe.
- Accédez à Centre d'administration > Objets et règles > Règles de gestion > Politiques d'accord de niveau de service (SLA)
- Cliquez sur Créer une politique et sélectionnez Accord de niveau de service (SLA) de groupe (pas Accord de niveau de service (SLA) standard)
- Donnez à votre politique un nom clair comme « Accord de niveau de service (SLA) d'escalade de niveau 1 » ou « Objectif de réponse de l'équipe financière »
- Définissez les conditions de filtre à l'aide de votre ID de groupe
Le filtre est l'endroit où la magie opère. Les politiques d'accord de niveau de service (SLA) de groupe nécessitent au moins une condition avec le champ « group_id ». Voici la structure JSON :
{
"filter": {
"all": [
{ "field": "group_id", "operator": "includes", "value": [10001] }
]
}
}
Opérateurs disponibles :
includes(comprend) : le groupe affecté au ticket correspond à n'importe quel groupe dans votre tableau de valeursnot_includes(ne comprend pas) : le ticket n'est affecté à aucun des groupes dans votre tableau de valeurs
Vous pouvez inclure plusieurs ID de groupe dans le tableau de valeurs :
{ "field": "group_id", "operator": "includes", "value": [10001, 10002, 10003] }
Cela applique le même accord de niveau de service (SLA) de groupe à plusieurs équipes associées, comme tous les groupes régionaux de niveau 1.
- Définissez la position de votre politique. Les accords de niveau de service (SLA) de groupe s'appliquent de haut en bas, et la première politique correspondante l'emporte. Placez les politiques plus spécifiques (comme les accords de niveau de service (SLA) de groupe VIP) au-dessus des politiques générales.

Étape 3 : Configurez les objectifs d'accord de niveau de service (SLA) de groupe
Une fois le filtre défini, il est temps de définir ce que vous mesurez réellement. Les accords de niveau de service (SLA) de groupe n'offrent qu'une seule mesure : group_ownership_time (temps de propriété du groupe).
Cette mesure mesure le temps écoulé entre le moment où un ticket est affecté à un groupe et le moment où ce groupe résout le ticket ou le réaffecte à un autre groupe. L'horloge s'arrête si le ticket est réaffecté en dehors du groupe et reprend s'il revient.
Pour chaque niveau de priorité (faible, normale, élevée, urgente), définissez un objectif en minutes. Tenez compte de ces exemples d'objectifs :
| Priorité | Objectif | Cas d'utilisation |
|---|---|---|
| Urgent | 10 minutes | Problèmes critiques nécessitant une escalade immédiate |
| Élevée | 30 minutes | Problèmes importants nécessitant un triage rapide |
| Normale | 2 heures | Flux de travail de support standard |
| Faible | 8 heures | Demandes non urgentes, éléments en attente |
Heures ouvrables ou heures calendaires : Décidez si l'horloge fonctionne 24 h/24 et 7 j/7 ou uniquement pendant vos heures d'ouverture. Pour les transferts internes, les heures calendaires sont souvent plus logiques afin que les équipes ne puissent pas « attendre » l'accord de niveau de service (SLA) pendant la nuit. Pour les engagements envers les clients, les heures ouvrables sont généralement plus équitables.
Pour configurer les objectifs via l'API :
{
"policy_metrics": [
{
"priority": "urgent",
"metric": "group_ownership_time",
"target": 600,
"business_hours": false
},
{
"priority": "normal",
"metric": "group_ownership_time",
"target": 7200,
"business_hours": false
}
]
}

Étape 4 : Ajoutez des colonnes d'accord de niveau de service (SLA) de groupe à vos vues
La création de politiques n'est que la moitié de la bataille. Vos agents doivent voir ces accords de niveau de service (SLA) en action. Voici comment ajouter le suivi des accords de niveau de service (SLA) de groupe à vos vues de tickets.
- Accédez à Centre d'administration > Objets et règles > Vues
- Modifiez une vue existante ou créez-en une nouvelle
- Dans la section Options de formatage, cliquez sur Ajouter une colonne
- Sélectionnez Accord de niveau de service (SLA) de groupe dans la liste des colonnes (cette colonne est distincte de la colonne d'accord de niveau de service (SLA) standard)
- Définissez Trier par > Accord de niveau de service (SLA) de groupe dans l'ordre Croissant
Trier par accord de niveau de service (SLA) de groupe dans l'ordre croissant signifie que les tickets les plus proches de la violation apparaissent en premier. Cela aide les agents à hiérarchiser leur file d'attente en fonction des délais internes, et pas seulement du temps de création du ticket.
Meilleure pratique : Créez des vues dédiées pour chaque groupe qui affiche sa colonne d'accord de niveau de service (SLA) de groupe. Les agents de niveau 1 doivent voir les objectifs d'accord de niveau de service (SLA) de groupe du niveau 1. Les tickets escaladés qui atterrissent au niveau 2 doivent afficher les objectifs du niveau 2.
Remarque : L'accord de niveau de service (SLA) de groupe et l'accord de niveau de service (SLA) standard sont des colonnes distinctes. Vous ne pouvez pas trier par les deux simultanément, alors choisissez la mesure qui compte le plus pour chaque vue spécifique.

Étape 5 : Configurez des automatismes pour les violations d'accord de niveau de service (SLA) de groupe
Les vues aident les agents à surveiller les accords de niveau de service (SLA), mais les automatismes peuvent agir lorsque les seuils sont atteints. Voici comment créer des automatismes autour des violations d'accord de niveau de service (SLA) de groupe.
Zendesk offre deux conditions d'automatismes pour les accords de niveau de service (SLA) de groupe :
- Heures avant la prochaine violation de l'accord de niveau de service (SLA) de groupe : utilisez ceci pour éviter les violations
- Heures depuis la dernière violation de l'accord de niveau de service (SLA) de groupe : utilisez ceci pour rattraper les tickets violés
Flux de travail d'automatismes courants :
- Escalade VIP : Si le ticket d'un client VIP est à 30 minutes de la violation de l'accord de niveau de service (SLA) de groupe, informez un canal Slack et réaffectez-le à un agent senior
- Augmentation de la priorité : Si un ticket d'e-mail viole l'objectif d'accord de niveau de service (SLA) de groupe, augmentez automatiquement sa priorité pour garantir une affectation plus rapide
- Alerte du responsable : Si un ticket viole l'accord de niveau de service (SLA) de groupe de plus d'une heure, envoyez un e-mail au responsable du support avec les détails du ticket
Limitation importante : Vous ne pouvez pas créer de déclencheurs basés sur l'état de violation de l'accord de niveau de service (SLA) ou de l'accord de niveau de service (SLA) de groupe. Seuls les automatismes (règles basées sur le temps) peuvent référencer les accords de niveau de service (SLA). Cela signifie que vous ne pouvez pas déclencher immédiatement des actions au moment où un accord de niveau de service (SLA) est violé ; vous devez utiliser des conditions d'automatismes basées sur le temps.
Utilisation de l'API pour gérer les politiques d'accord de niveau de service (SLA) de groupe
Pour les équipes qui gèrent plusieurs accords de niveau de service (SLA) de groupe ou qui s'intègrent à des outils externes, l'API offre un contrôle programmatique complet.
Répertorier toutes les politiques d'accord de niveau de service (SLA) de groupe :
curl https://your-subdomain.zendesk.com/api/v2/group_slas/policies \
-H "Content-Type: application/json" \
-u email@example.com/token:API_TOKEN
Créer une politique :
curl https://your-subdomain.zendesk.com/api/v2/group_slas/policies \
-H "Content-Type: application/json" \
-X POST \
-d '{
"group_sla_policy": {
"title": "Tier 1 Escalation",
"filter": {
"all": [{ "field": "group_id", "operator": "includes", "value": [10001] }]
},
"policy_metrics": [
{ "priority": "urgent", "metric": "group_ownership_time", "target": 600, "business_hours": false }
]
}
}' \
-u email@example.com/token:API_TOKEN
Récupérer les définitions de filtre :
curl https://your-subdomain.zendesk.com/api/v2/group_slas/policies/definitions \
-H "Content-Type: application/json" \
-u email@example.com/token:API_TOKEN
Le point de terminaison des définitions renvoie tous les champs et opérateurs de filtre disponibles, ce qui est utile si vous créez une intégration personnalisée.
Problèmes courants et dépannage
Même avec une configuration appropriée, les accords de niveau de service (SLA) de groupe peuvent se comporter de manière inattendue. Voici les problèmes les plus courants et comment les résoudre.
La colonne d'accord de niveau de service (SLA) de groupe n'apparaît pas dans les vues Cela signifie presque toujours que vous n'avez pas de forfait Enterprise. Vérifiez votre niveau d'abonnement dans Centre d'administration > Compte. Les accords de niveau de service (SLA) de groupe sont réservés à Enterprise.
La politique ne s'applique pas aux tickets Vérifiez votre valeur group_id. L'ID dans l'URL lorsque vous affichez un groupe dans le Centre d'administration est correct. Vérifiez également que les tickets sont réellement affectés à ce groupe via des déclencheurs ou une affectation manuelle.
Confusion entre la propriété et l'escalade Les accords de niveau de service (SLA) de groupe mesurent le temps total pendant lequel un groupe possède un ticket, qu'il l'ait reçu lors de la création ou via une escalade d'une autre équipe. Cela signifie que l'horloge d'accord de niveau de service (SLA) de groupe du niveau 2 démarre lorsqu'il reçoit le ticket escaladé, et non lorsque le client vous a contacté pour la première fois. Certains administrateurs créent des groupes distincts comme « Niveau 2 escaladé » avec des objectifs différents.
Escalades externes non suivies Les accords de niveau de service (SLA) de groupe ne fonctionnent qu'au sein de Zendesk. Si vous escaladez vers une équipe via Jira, Slack ou Side Conversations, ce temps n'est pas mesuré. Envisagez d'utiliser des champs personnalisés ou des notes internes pour suivre les transferts externes.
Problèmes d'ordre des politiques N'oubliez pas que les accords de niveau de service (SLA) de groupe s'appliquent de haut en bas, la première correspondance l'emporte. Si vous avez une politique générale « Tous les groupes de support » en haut, elle bloquera les politiques plus spécifiques en dessous.
Rationalisez votre flux de travail de support avec eesel AI
Les accords de niveau de service (SLA) de groupe vous donnent une structure pour suivre les performances internes, mais la structure ne fonctionne que si vos équipes peuvent réellement atteindre ces objectifs de manière cohérente. C'est là que l'assistance de l'IA devient précieuse.
Nous avons créé eesel AI pour qu'il fonctionne avec des outils comme Zendesk, en gérant le travail répétitif qui ralentit les équipes et rend les accords de niveau de service (SLA) plus difficiles à atteindre. Voici comment il complète votre cadre d'accord de niveau de service (SLA) de groupe :
Routage automatisé des tickets : eesel AI peut trier les tickets entrants et les acheminer immédiatement vers le bon groupe. Au lieu que les tickets restent dans une file d'attente générale en attendant une affectation manuelle, ils atterrissent instantanément dans la file d'attente de la bonne équipe, ce qui leur donne toute la fenêtre d'accord de niveau de service (SLA) de groupe pour travailler.
Réponses initiales plus rapides : Lorsque eesel AI gère le support de première ligne, il répond aux clients en quelques secondes. Cela donne à vos équipes humaines le temps de travailler dans leurs fenêtres d'accord de niveau de service (SLA) de groupe pour les problèmes complexes, sans que les clients ne se sentent ignorés.
Qualité de transfert cohérente : eesel AI résume le contexte du ticket lors de l'escalade, de sorte que lorsqu'un ticket passe du niveau 1 au niveau 2 (déclenchant cette horloge d'accord de niveau de service (SLA) de groupe), l'agent récepteur a tout ce dont il a besoin pour commencer à travailler immédiatement.
Nous nous intégrons directement à Zendesk, en nous formant sur vos anciens tickets, macros et contenu du centre d'aide afin que l'IA ressemble à votre équipe. Vous pouvez simuler des réponses sur les tickets historiques avant de passer en direct, en vous assurant que la qualité reste élevée même lorsque le volume augmente.
Si vous mettez en œuvre des accords de niveau de service (SLA) de groupe pour améliorer la responsabilisation interne, réfléchissez à ce qui se passe lorsque l'IA gère le travail de routine. Vos équipes ont plus de bande passante pour se concentrer sur les problèmes complexes où les accords de niveau de service (SLA) de groupe comptent vraiment.

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.


