Politique multi-SLA Zendesk par ticket : comment configurer et optimiser

Si vous gérez une équipe d'assistance occupée, vous vous êtes probablement déjà demandé : puis-je appliquer différents SLA au même ticket selon la situation ? Peut-être souhaitez-vous un SLA plus rapide pour les clients VIP, tout en ayant besoin d'objectifs différents selon le canal utilisé. La réponse courte est que Zendesk limite chaque ticket à une seule politique SLA standard active et une seule politique SLA de groupe à un moment donné. Mais cela ne signifie pas que vous n'avez pas d'options. Vous devez simplement comprendre comment le système fonctionne.

Ce guide explique exactement comment fonctionne l'architecture des politiques SLA de Zendesk, pourquoi la limitation à une seule politique existe, et présente des stratégies éprouvées pour organiser vos politiques afin de gérer des scénarios d'assistance complexes. Que vous configuriez des SLA pour la première fois ou que vous cherchiez à comprendre pourquoi la mauvaise politique s'applique à vos tickets, vous trouverez ici des réponses pratiques.

Qu'est-ce que le suivi SLA de Zendesk ?

Avant de plonger dans les politiques multiples, clarifions de quoi nous parlons. Un SLA (Service Level Agreement ou Accord de niveau de service) dans Zendesk est essentiellement un minuteur attaché à une promesse. Il spécifie la rapidité avec laquelle votre équipe s'engage à répondre et à résoudre les problèmes des clients.

Le suivi SLA de Zendesk vous offre un moyen structuré de définir ces engagements et de mesurer si vous les respectez. La plateforme propose plusieurs indicateurs que vous pouvez suivre :

Chaque indicateur sert un objectif différent, et la plupart des équipes commencent par le Délai de première réponse et le Délai de résolution totale avant d'ajouter de la complexité.

Un ticket Zendesk peut-il avoir plusieurs politiques SLA ?

Voici la réponse directe : non, un seul ticket ne peut pas avoir plusieurs politiques SLA standard actives simultanément. À tout moment, un ticket peut avoir exactement une politique SLA standard et, si vous disposez d'un forfait Enterprise, une politique SLA de groupe.

Il ne s'agit pas d'un bug ou d'un oubli. C'est un choix de conception délibéré qui évite les objectifs conflictuels. Imaginez si une politique disait « répondre sous 1 heure » et une autre « répondre sous 4 heures » — laquelle Zendesk devrait-il suivre ? Plutôt que d'essayer de concilier des exigences contradictoires, Zendesk applique la première politique correspondante et s'arrête là.

L'expression clé est « à un moment donné ». La politique SLA d'un ticket peut changer au cours de son cycle de vie si les conditions changent. Par exemple, si la priorité d'un ticket est escaladée de Normale à Urgente, et que vos politiques ont des objectifs différents pour chaque priorité, le ticket adoptera les objectifs « Urgente » à partir de ce moment-là. Mais il n'aura toujours pas plusieurs politiques actives à la fois.

C'est là que la compréhension du système d'ordonnancement des politiques de Zendesk devient critique.

Comment Zendesk détermine quelle politique SLA s'applique

Lorsqu'un ticket est créé ou mis à jour, Zendesk suit une séquence spécifique :

1. Les déclencheurs s'exécutent en premier — Toutes les règles d'automatisation qui définissent des champs, attribuent des tickets ou ajoutent des balises s'exécutent avant l'évaluation du SLA.
2. Les politiques SLA sont vérifiées — En commençant par le haut de votre liste de politiques, Zendesk recherche la première politique dont les conditions correspondent au ticket.
3. La première correspondance l'emporte — Dès qu'une politique correspondante est trouvée, elle est appliquée et la recherche s'arrête.
4. Les SLA de groupe sont évalués séparément — Le même processus s'applique pour les SLA de groupe si vous êtes sur un forfait Enterprise.

Cette évaluation de haut en bas est la raison pour laquelle l'ordre des politiques est extrêmement important. Un ticket pourrait techniquement correspondre à trois politiques différentes, mais seule la mieux classée sera appliquée.

Prenons un exemple concret. Supposons que vous ayez ces politiques dans cet ordre :

1. Clients VIP — Première réponse sous 1 heure
2. Clients Entreprise — Première réponse sous 4 heures
3. Assistance Standard — Première réponse sous 8 heures

Si un ticket arrive d'un client qui possède à la fois la balise « VIP » et appartient à une organisation « Entreprise », et que les conditions des deux politiques correspondent, la politique VIP l'emporte car elle est en haut de la liste. Le client bénéficie de l'objectif d'une heure, et non de celui de quatre heures.

Ce comportement est en fait une fonctionnalité, pas une limitation. Il vous permet de créer une hiérarchie de niveaux de service où vos clients les plus importants bénéficient toujours des délais de réponse les plus rapides, même s'ils pourraient être éligibles à plusieurs politiques.

Bonnes pratiques pour organiser les configurations multi-SLA dans Zendesk

Puisque vous ne pouvez pas appliquer plusieurs politiques à un seul ticket, vous devez concevoir votre structure de politiques de manière à ce que la bonne politique s'applique automatiquement. Voici comment les administrateurs Zendesk expérimentés abordent la question.

Ordonner les politiques de la plus spécifique à la moins spécifique

La règle d'or de l'organisation des SLA est de placer vos politiques les plus restrictives et spécifiques en haut, et vos politiques larges et générales en bas. Pensez-y comme à un entonnoir : les cas les plus urgents et importants sont captés par les politiques du haut, tandis que tout le reste descend vers vos paramètres par défaut.

Voici une stratégie d'ordonnancement recommandée :

Utiliser des déclencheurs pour définir la priorité avant l'évaluation SLA

L'une des techniques les plus efficaces pour gérer des scénarios SLA complexes consiste à utiliser des déclencheurs pour standardiser les champs des tickets avant que le système SLA ne les évalue. Comme les politiques SLA ne peuvent pas utiliser tous les champs de ticket comme conditions (notamment, elles ne peuvent pas utiliser le statut ou certains champs personnalisés), convertir votre logique métier dans le champ Priorité vous donne plus de contrôle.

Voici un flux de travail pratique :

1. Créez des déclencheurs qui analysent les tickets entrants — Vérifiez les organisations VIP, les mots-clés spécifiques, les indicateurs d'urgence.
2. Définissez la Priorité en conséquence — Utilisez le déclencheur pour attribuer une priorité Urgente, Élevée, Normale ou Basse.
3. Construisez des politiques SLA autour de la Priorité — Vos politiques peuvent ensuite utiliser la Priorité comme condition principale, avec des objectifs différents pour chaque niveau.

Cette approche est particulièrement précieuse lors de l'utilisation des SLA de groupe, qui ont des options de conditions plus limitées que les SLA standard.

Configurer des politiques spécifiques aux canaux

Les différents canaux d'assistance impliquent des attentes clients différentes. Une personne qui vous contacte via le chat s'attend à une réponse immédiate, tandis que les clients par e-mail peuvent se contenter de quelques heures. Créer des politiques distinctes pour chaque canal vous permet de répondre à ces attentes variées sans surcharger votre équipe.

Une configuration courante ressemble à ceci :

La clé est d'utiliser la condition « Le canal est / n'est pas » pour segmenter vos politiques. De nombreux administrateurs placent les politiques de messagerie en haut de leur liste car ces tickets sont les plus sensibles au facteur temps.

Utiliser les SLA de groupe parallèlement aux politiques standard

Si vous disposez d'un forfait Zendesk Enterprise, vous avez accès aux SLA de groupe — parfois appelés accords de niveau opérationnel ou OLA (Operational Level Agreements). Il s'agit de minuteurs internes qui mesurent combien de temps un ticket reste attribué à un groupe spécifique, plutôt que de suivre les délais de réponse orientés client.

Le point important à comprendre est que les SLA de groupe fonctionnent indépendamment des SLA standard. Un ticket peut avoir l'un de chaque simultanément. Cela signifie que vous pourriez avoir :

• Un SLA standard indiquant que vous répondez au client sous 4 heures.
• Un SLA de groupe indiquant que l'équipe Ingénierie possède le ticket pendant 8 heures maximum.

Ce double suivi est particulièrement utile pour les tickets qui passent entre plusieurs départements. Vous pouvez voir à la fois comment vous performez par rapport aux engagements clients et avec quelle efficacité le travail circule au sein de vos équipes internes.

Cependant, les SLA de groupe comportent des limitations. Ils ne peuvent utiliser l'attribution de groupe que comme condition requise, en plus de conditions optionnelles supplémentaires. Ils n'offrent pas toute la gamme de champs de conditions disponibles dans les SLA standard. Et surtout, ils ne peuvent pas faire la différence entre un groupe qui reçoit un ticket en tant qu'attribution principale et un groupe qui le reçoit via une escalade.

Scénarios courants pour les configurations de politiques multi-SLA Zendesk

Passons en revue quelques scénarios réels et la manière de structurer vos politiques pour chacun d'eux.

Scénario 1 : Les clients VIP ont besoin de délais de réponse plus rapides

Vous avez un mélange de clients standard et VIP, et les VIP ont besoin d'un service plus rapide, quel que soit le canal ou le type de problème.

Solution : Créez une politique VIP tout en haut de votre liste en utilisant des balises d'organisation ou des champs d'utilisateur pour identifier les VIP. Définissez des objectifs agressifs. Placez ensuite les politiques standard en dessous pour tous les autres.

Scénario 2 : Les différents canaux nécessitent des délais de réponse différents

Votre équipe gère à la fois le chat (immédiat) et l'e-mail (moins urgent), et vous voulez des objectifs appropriés pour chacun.

Solution : Créez des politiques distinctes pour chaque canal en haut de votre liste. Utilisez les conditions « Le canal est Messagerie » et « Le canal n'est pas Messagerie ». Assurez-vous que les politiques de messagerie sont plus hautes dans l'ordre car ces tickets sont les plus urgents.

Scénario 3 : Les tickets escaladés ont besoin d'un suivi interne

Les tickets qui passent du Support à l'Ingénierie ont besoin d'objectifs de possession interne distincts des SLA orientés client.

Solution : Utilisez les SLA standard pour les engagements clients. Créez des SLA de groupe pour chaque équipe interne avec des objectifs de temps de possession. Rappelez-vous simplement que les SLA de groupe ne font pas la différence entre un ticket attribué directement à l'Ingénierie et un ticket escaladé depuis le Support — les deux déclencheront le même minuteur de possession.

Scénario 4 : Gérer les escalades externes

Vous devez parfois escalader des tickets vers des fournisseurs ou des partenaires qui travaillent avec des outils extérieurs à Zendesk (comme Jira ou via Slack).

Limitation : Les SLA de groupe ne peuvent pas mesurer le temps passé avec des équipes externes car ces équipes ne sont pas des groupes Zendesk.

Contournement : Certains administrateurs créent des groupes « fictifs » pour les escalades externes. Le ticket est attribué au groupe externe pendant l'attente, ce qui met en pause le SLA de groupe interne. Lorsque l'équipe externe répond, le ticket est réattribué à l'équipe interne et le SLA de groupe reprend.

Optimiser les performances SLA grâce à l'IA

Respecter systématiquement des objectifs SLA agressifs est un défi, surtout lorsque le volume de tickets augmente. C'est là que les outils d'IA peuvent aider.

Atteindre les objectifs de Délai de première réponse est souvent le plus grand défi. Pour les questions courantes comme les réinitialisations de mots de passe, les suivis de commande ou le dépannage de base, le délai de première réponse idéal est pratiquement instantané. Les agents IA peuvent fournir des réponses immédiates et précises à ces demandes de routine, satisfaisant votre SLA avant même qu'un agent humain ne voie le ticket.

Pour les problèmes plus complexes nécessitant une expertise humaine, les copilotes IA peuvent réduire le temps que les agents passent à rédiger des réponses. En extrayant des informations de votre base de connaissances et en suggérant des réponses basées sur les résolutions passées, les agents peuvent répondre plus rapidement sans sacrifier la qualité. Cela aide à améliorer à la fois le Délai de réponse suivante et les indicateurs de Délai de résolution globale.

Chez eesel AI, nous avons conçu notre plateforme pour qu'elle s'intègre directement à Zendesk et réponde à ces défis précis. Notre Agent IA peut gérer les tickets courants de manière autonome, respectant instantanément vos objectifs de Délai de première réponse pour les demandes de routine. Pour les problèmes complexes nécessitant un jugement humain, notre Copilote IA rédige des réponses précises et personnalisées en apprenant de vos anciens tickets, macros et contenu du centre d'aide. Cela réduit le temps que les agents passent à chercher des informations et les aide à répondre dans les délais de vos SLA.

Ce qui rend cela particulièrement précieux pour la gestion des SLA, c'est la capacité de simulation. Avant de déployer toute automatisation par l'IA, vous pouvez la tester par rapport à vos tickets historiques pour voir exactement comment elle se serait comportée par rapport à vos SLA existants. Cela vous permet d'ajuster votre configuration en toute confiance.

Commencez à optimiser vos politiques SLA Zendesk dès aujourd'hui

La limitation de Zendesk à une seule politique par ticket n'est pas une contrainte que vous devez contourner — c'est un cadre pour créer des niveaux de service clairs et hiérarchisés. En ordonnant vos politiques de la plus spécifique à la moins spécifique et en utilisant des déclencheurs pour standardiser les champs des tickets avant l'évaluation du SLA, vous pouvez gérer pratiquement n'importe quel scénario d'assistance.

Voici une liste de contrôle rapide pour examiner votre configuration actuelle :

• Vos politiques clients les plus importantes sont-elles en haut de la liste ?
• Avez-vous une politique générale (catch-all) en bas pour garantir que chaque ticket a un SLA ?
• Utilisez-vous des déclencheurs pour définir la priorité de manière cohérente avant l'évaluation du SLA ?
• Avez-vous défini des heures d'ouverture pour que les SLA ne comptent pas le temps lorsque votre équipe est hors ligne ?
• Vos agents sont-ils formés pour comprendre ce que signifient les badges SLA et comment prioriser leur travail ?

Si vous cherchez à améliorer vos performances SLA au-delà du simple suivi des indicateurs, réfléchissez à la manière dont l'IA peut vous aider. Automatiser les réponses aux questions courantes, aider les agents avec des brouillons de réponses et fournir un accès instantané aux connaissances pertinentes peuvent tous vous aider à atteindre vos objectifs plus régulièrement. Vous pouvez connecter votre compte Zendesk à eesel AI et tester la configuration par rapport à vos tickets historiques pour voir l'impact potentiel sur vos performances SLA.