Comprendre le temps d'appropriation de la cible SLA de Zendesk : un guide complet

Lorsque votre équipe de support fait remonter un ticket à l'ingénierie, qui est responsable du respect du SLA (Service Level Agreement, Accord sur les niveaux de service) ? Si le client attend et que le ticket a été transféré entre trois équipes internes différentes, comment suivre qui est responsable du retard ? C'est là que le temps d'appropriation de la cible SLA de groupe de Zendesk entre en jeu.

Les SLA de groupe (également appelés accords de niveau opérationnel ou OLA) vous permettent de mesurer combien de temps un ticket reste avec des équipes internes spécifiques. Contrairement aux SLA réguliers qui promettent des temps de réponse aux clients, les SLA de groupe suivent les transferts et l'appropriation internes. Ils sont particulièrement utiles pour les organisations avec un support à plusieurs niveaux, des flux de travail interfonctionnels ou des SLA internes stricts avec d'autres départements.

Décomposons le fonctionnement du temps d'appropriation de la cible SLA de Zendesk, comment le configurer et quand vous pourriez vouloir l'augmenter avec des solutions basées sur l'IA.

Qu'est-ce que le temps d'appropriation de la cible SLA de Zendesk ?

Les SLA réguliers dans Zendesk suivent le temps entre les messages des clients et les réponses de votre équipe. Ce sont des engagements externes, visibles par les clients et liés à vos promesses de service. Les SLA de groupe fonctionnent différemment. Ils mesurent combien de temps un ticket reste attribué à un groupe spécifique d'agents, en suivant la responsabilité interne plutôt que les mesures destinées aux clients.

La mesure du temps d'appropriation mesure spécifiquement la durée entre le moment où un ticket est attribué à un groupe et le moment où il est réattribué à un autre groupe ou résolu. C'est ce que Zendesk appelle un « accord de niveau opérationnel » ou OLA (Operational Level Agreement). Considérez-le comme un contrat interne entre les équipes. Lorsque le niveau 1 remonte au niveau 2, les deux parties savent exactement combien de temps le niveau 2 a pour résoudre le problème.

Voici quand les SLA de groupe sont pertinents :

• Structures de support à plusieurs niveaux où les tickets remontent de la première ligne aux équipes spécialisées
• Flux de travail interfonctionnels impliquant le support, l'ingénierie, le produit ou les opérations
• Remontées de fournisseurs ou de partenaires où vous devez suivre les temps de réponse des équipes externes
• Centres d'assistance informatique internes mesurant les temps de résolution pour différents départements

Il y a une prise importante : les SLA de groupe ne sont disponibles que sur le plan Enterprise de Zendesk. Si vous êtes sur Suite Professional (115 $ par agent par mois annuellement) ou moins, vous n'aurez pas accès à cette fonctionnalité. Vous aurez besoin de Suite Enterprise (169 $ par agent par mois annuellement) ou plus.

Comment fonctionne le temps d'appropriation des SLA de groupe

Comprendre quand le temps d'appropriation commence et s'arrête est essentiel pour utiliser efficacement les SLA de groupe. L'horloge commence à tourner au moment où un ticket est attribué à un groupe qui correspond aux conditions de votre politique de SLA de groupe. Elle s'arrête lorsque le ticket est résolu ou réattribué à un groupe différent.

Voici un exemple concret. Imaginez qu'un ticket arrive à votre groupe de support de première ligne. Votre politique indique que le niveau 1 a 4 heures pour résoudre les tickets. L'agent se rend compte qu'il s'agit d'un bug et le remonte à l'ingénierie après 2 heures. Le temps d'appropriation s'arrête à 2 heures (bien dans la cible de 4 heures), et une nouvelle horloge démarre pour le groupe d'ingénierie, qui pourrait avoir une cible de 8 heures.

Que se passe-t-il lorsque les tickets sont rouverts ? Si un ticket a été résolu par l'ingénierie, mais que le client signale que le correctif n'a pas fonctionné, le temps d'appropriation est réinitialisé lorsque le ticket est réattribué à l'ingénierie. Cela empêche les équipes de manipuler le système en marquant les tickets comme résolus prématurément.

Vous devez également choisir entre les heures ouvrables et les heures calendaires :

Zendesk autorise plusieurs horaires d'ouverture sur les plans Enterprise, de sorte que différents groupes peuvent avoir des heures de travail différentes. Votre équipe de support APAC peut fonctionner de 9 h à 18 h, heure de Singapour, tandis que votre groupe d'ingénierie suit les heures du Pacifique américain.

Les SLA de groupe et les SLA réguliers peuvent coexister sur le même ticket. Votre client peut voir un engagement de temps de première réponse de 24 heures, tandis qu'en interne, vous suivez que l'ingénierie a 8 heures pour fournir un correctif. Les deux minuteurs fonctionnent indépendamment. Apprenez-en davantage sur les politiques SLA standard dans la documentation de Zendesk.

Configuration des politiques SLA de groupe avec le temps d'appropriation

Avant de commencer à configurer les SLA de groupe, vous aurez besoin de quelques éléments en place :

1. Plan Suite Enterprise ou supérieur (169 $ par agent par mois annuellement)
2. Groupes déjà créés dans votre Zendesk (Centre d'administration > Personnes > Groupes)
3. Champ de priorité rempli sur les tickets (généralement via des déclencheurs qui définissent la priorité en fonction du type de demande ou du formulaire)

Pour des instructions de configuration détaillées, consultez la documentation SLA de groupe de Zendesk.

Une fois que vous avez ces prérequis, voici comment configurer une politique SLA de groupe avec des cibles de temps d'appropriation :

Étape 1 : Accédez aux paramètres SLA Accédez à Centre d'administration > Objets et règles > Règles métier > Accords sur les niveaux de service. Cliquez sur l'onglet « SLA de groupe » en haut de la page.

Étape 2 : Créez une nouvelle politique Cliquez sur « Ajouter une politique » et donnez-lui un nom descriptif. Quelque chose comme « SLA de remontée d'ingénierie » ou « Cibles d'appropriation de niveau 2 ». Des noms clairs aident lorsque vous gérez plusieurs politiques plus tard.

Étape 3 : Définissez les conditions Cela détermine à quels tickets la politique s'applique. Vous pouvez cibler des groupes spécifiques, des ensembles de groupes ou des tickets correspondant à certains critères. Les conditions courantes incluent :

• Le groupe est « Ingénierie » OU « Produit »
• La priorité est élevée ou urgente
• L'état du ticket est inférieur à Résolu

Étape 4 : Définissez les cibles de temps d'appropriation C'est ici que vous définissez combien de temps chaque groupe a. Zendesk vous permet de définir différentes cibles en fonction de la priorité :

Étape 5 : Choisissez les heures ouvrables ou calendaires Sélectionnez si le minuteur doit fonctionner en continu (heures calendaires) ou uniquement pendant les heures de travail (heures ouvrables). N'oubliez pas que les heures ouvrables nécessitent que vous ayez des horaires de travail configurés dans Zendesk.

Étape 6 : Enregistrez et ordonnez vos politiques L'ordre des politiques est important. Zendesk applique la première politique correspondante et arrête la vérification. Placez vos politiques les plus spécifiques et restrictives en haut, et les politiques générales de rattrapage en bas.

Comprendre les mesures de temps d'appropriation et les rapports

Une fois que vos SLA de groupe sont en cours d'exécution, vous voudrez suivre les performances. Zendesk fournit plusieurs façons de surveiller les mesures de temps d'appropriation.

Vues de ticket avec des colonnes SLA Ajoutez des colonnes SLA de groupe à vos vues de ticket pour voir le risque de violation en un coup d'œil. Vous pouvez trier les tickets par leur proximité de la violation, aidant les agents à prioriser le travail qui nécessite une attention immédiate.

Tableaux de bord Zendesk Explore Le tableau de bord SLA de groupe dans Zendesk Explore fournit des rapports agrégés. Vous verrez des mesures comme :

• % Atteint : Le pourcentage de tickets qui ont atteint leur cible de temps d'appropriation
• Temps de résolution moyen : Combien de temps les tickets restent généralement avec chaque groupe
• Taux de violation : La fréquence à laquelle les groupes manquent leurs cibles

Rapports basés sur l'instance par rapport aux rapports basés sur le ticket Les rapports basés sur l'instance suivent chaque fois qu'un ticket entre dans un groupe, même si le même ticket entre dans le même groupe plusieurs fois. Les rapports basés sur le ticket examinent le temps total qu'un ticket a passé avec un groupe dans toutes les instances. La plupart des équipes utilisent les rapports basés sur l'instance pour les revues opérationnelles, car ils capturent chaque transfert séparément.

Lors de l'examen de vos mesures, recherchez des modèles :

• Certains groupes violent-ils systématiquement ? Ils pourraient avoir besoin de plus de ressources ou de cibles différentes.
• Les tickets rebondissent-ils entre les groupes à plusieurs reprises ? Vos critères de remontée pourraient avoir besoin de clarification.
• Y a-t-il un modèle d'heure de la journée ? Vous pourriez avoir des lacunes de couverture pendant certaines heures.

Meilleures pratiques pour la mise en œuvre des SLA de groupe

Après avoir travaillé avec des dizaines d'équipes de support sur leurs configurations SLA, nous avons identifié plusieurs modèles qui séparent les mises en œuvre réussies des mises en œuvre frustrantes.

Configurez d'abord les déclencheurs de priorité Avant que les SLA de groupe puissent fonctionner, les tickets ont besoin de priorités. Créez des déclencheurs qui définissent automatiquement la priorité en fonction de la sélection du formulaire, du type de demande ou des mots-clés. Si les agents définissent manuellement les priorités, vous obtiendrez des résultats incohérents et des données SLA peu fiables.

Différenciez les canaux de conversation par rapport aux canaux de billetterie Les conversations de chat et de messagerie ont des rythmes différents de ceux des tickets de messagerie. Une cible d'appropriation de 4 heures est logique pour un ticket de messagerie. Pour un chat en direct qui pourrait prendre 10 minutes à résoudre, cette même cible est dénuée de sens. Envisagez des politiques distinctes ou des méthodes de calcul différentes pour les canaux synchrones.

Utilisez la règle 2-4-8-16 comme point de départ De nombreuses équipes réussissent avec des cibles à plusieurs niveaux en fonction de la gravité :

• Urgent : 2 heures
• Élevée : 4 heures
• Normale : 8 heures
• Faible : 16 heures

Ajustez-les en fonction de la capacité réelle de votre équipe et des attentes des clients. Mieux vaut commencer avec souplesse et resserrer que de fixer des cibles impossibles que tout le monde ignore.

Ordonnez les politiques de la plus restrictive à la moins restrictive Zendesk applique la première politique correspondante et s'arrête. Si vous avez une politique spécifique pour les « tickets d'ingénierie de haute priorité » et une politique générale pour « Tous les tickets d'ingénierie », placez la politique spécifique en premier.

Créez des vues basées sur les SLA pour les agents Donnez à chaque groupe une vue dédiée montrant uniquement ses tickets, triés par risque de violation. Cela aide les agents à voir ce qui est urgent sans avoir à parcourir les tickets qui ne s'appliquent pas à eux.

Gérez soigneusement les flux de travail multi-équipes Lorsque les tickets doivent passer séquentiellement par plusieurs groupes (Support → Ingénierie → QA → Support), déterminez si vous avez besoin de politiques distinctes pour chaque transfert ou d'une seule politique couvrant l'ensemble du flux.

Créez une responsabilité sans blâme Les SLA sont des outils de coaching, pas des mécanismes de punition. Lorsqu'une équipe viole régulièrement, la conversation devrait porter sur les contraintes de ressources, les améliorations de processus ou les cibles irréalistes, et non sur les performances des agents.

Défis et solutions courants des SLA de groupe

Même avec une planification minutieuse, les équipes rencontrent des défis spécifiques avec les SLA de groupe. Voici les plus courants et comment les résoudre.

Défi : Confusion entre l'attribution et la remontée Les agents « remontent » parfois en réattribuant simplement le ticket à un autre groupe sans aucun contexte ou documentation approprié. Le groupe destinataire reçoit un ticket sans historique, et l'horloge SLA commence à tourner sur quelque chose qu'il ne comprend pas.

Solution : Créez des groupes distincts pour les tickets de première ligne et les tickets remontés. Utilisez des macros qui nécessitent des champs spécifiques (comme la raison de la remontée ou l'impact sur le client) avant d'autoriser la réattribution à des groupes spécialisés. Formez les agents au fait que la réattribution sans contexte est un échec de processus, pas une solution.

Défi : Remontées externes Que se passe-t-il lorsque vous remontez à une équipe en dehors de Zendesk ? Peut-être créez-vous un ticket Jira pour l'ingénierie, ou démarrez-vous un fil Slack avec l'équipe produit. Le ticket Zendesk reste avec votre groupe de support pendant que vous attendez des réponses externes, mais le SLA de groupe continue de tourner.

Solution : Créez des groupes d'espace réservé comme « En attente d'ingénierie » ou « En attente de produit ». Lorsque vous remontez en externe, réattribuez le ticket au groupe d'espace réservé. Cela met en pause l'horloge SLA du groupe d'origine et en démarre une nouvelle pour la dépendance externe. Certaines équipes créent même une automatisation qui réattribue les tickets après un certain temps pour éviter qu'ils ne disparaissent dans les files d'attente externes.

Défi : Temps d'appropriation du support de première ligne Les équipes de première ligne ont souvent du mal avec les cibles de temps d'appropriation parce qu'elles attendent des informations des clients. Un ticket peut rester en suspens pendant 24 heures parce que le client n'a pas répondu, puis l'agent le prend en charge et le résout en 10 minutes. Le SLA affiche une violation même si l'agent n'a rien fait de mal.

Solution : Définissez des cibles réalistes en fonction du temps de résolution prévu, pas seulement du temps de réponse. Envisagez d'utiliser les heures ouvrables afin que les heures creuses ne soient pas comptabilisées contre votre équipe. Certaines équipes créent un statut « En attente du client » qui met en pause les SLA, bien que cela nécessite une configuration de déclencheur minutieuse.

Défi : Conflits de politiques et problèmes d'ordonnancement Les tickets correspondant à plusieurs politiques SLA de groupe peuvent produire des résultats déroutants. Un ticket qui est dans « Ingénierie » ET a une priorité « Élevée » peut correspondre à deux politiques différentes, et seule la première de la liste s'applique.

Solution : Vérifiez régulièrement vos politiques. Documentez les conditions que chaque politique cible. Testez les cas extrêmes (tickets qui pourraient correspondre à plusieurs politiques) pour voir laquelle s'applique. Envisagez d'utiliser les conditions « TOUTES » plutôt que les conditions « N'IMPORTE QUELLE » pour rendre les correspondances plus spécifiques.

Aller au-delà des SLA natifs avec des solutions basées sur l'IA

Les SLA de groupe sont puissants pour suivre la responsabilité interne, mais ils ont des limites. Ils mesurent le temps. Ils n'améliorent pas les processus qui consomment ce temps. Ils suivent les transferts, mais ne les réduisent pas. Ils identifient les goulots d'étranglement, mais ne les résolvent pas.

C'est là que les coéquipiers IA peuvent augmenter votre stratégie SLA.

Chez eesel AI, nous avons créé un coéquipier IA pour les équipes de support qui se branche directement sur Zendesk. Bien qu'il ne remplace pas les SLA de groupe, il aborde bon nombre des causes profondes qui rendent les cibles de temps d'appropriation difficiles en premier lieu.

AI Triage pour le routage automatique des tickets Notre produit AI Triage lit les tickets entrants et les achemine automatiquement vers le bon groupe. Au lieu que les tickets rebondissent entre les équipes pendant que les agents déterminent qui devrait les traiter, l'IA attribue correctement la première fois. Cela réduit le nombre total de transferts et garantit que le temps d'appropriation commence quand il le devrait, et non après une journée de ping-pong interne.

AI Agent pour la résolution autonome Notre AI Agent gère les tickets de support de première ligne de bout en bout. Pour les tickets qu'il peut résoudre (généralement 60 à 80 % des demandes courantes), il n'y a pas de remontée, pas de transfert, pas de temps d'appropriation à suivre. L'IA résout le problème et ferme le ticket. Vos SLA de groupe ne deviennent pertinents que pour les cas extrêmes complexes qui ont réellement besoin d'une expertise humaine.

Informations sur les performances en temps réel Alors que les rapports de Zendesk montrent les performances SLA historiques, notre IA offre une visibilité en temps réel sur ce qui se passe en ce moment. Vous pouvez voir quels tickets risquent de violer avant qu'ils ne le fassent réellement, et intervenir de manière proactive plutôt que de revoir les violations après coup.

La combinaison fonctionne bien : les SLA de groupe suivent les transferts qui se produisent, tandis que l'IA réduit le nombre total de transferts nécessaires. Les équipes qui utilisent les deux voient généralement leurs mesures de temps d'appropriation s'améliorer non pas parce qu'elles travaillent plus vite, mais parce que l'IA gère le travail simple qui avait l'habitude d'obstruer leurs files d'attente.

Si vous êtes intéressé à explorer comment l'IA pourrait compléter votre stratégie SLA de Zendesk, vous pouvez en apprendre davantage sur notre intégration Zendesk ici ou consulter nos prix pour comprendre comment notre modèle à tarif fixe se compare aux licences par agent.

Tirer le meilleur parti de vos SLA de Zendesk

Le temps d'appropriation de la cible SLA de groupe est un outil précieux pour la responsabilité interne, mais ce n'est qu'un élément d'une opération de support bien gérée. Voici les principaux points à retenir :

Commencez par des cibles réalistes basées sur la capacité réelle de l'équipe, pas sur des objectifs ambitieux. Les SLA inatteignables sont ignorés. Les SLA atteignables stimulent l'amélioration.

Surveillez régulièrement vos mesures, mais utilisez-les comme des outils de coaching plutôt que comme des clubs de performance. La question devrait toujours être « Comment pouvons-nous améliorer cela ? » et non « Qui est responsable de la violation ? »

Envisagez l'augmentation de l'IA pour les flux de travail complexes. Si vous suivez le temps d'appropriation dans cinq groupes différents pour un ticket typique, le problème pourrait être votre processus, pas vos employés. Les coéquipiers IA comme eesel AI peuvent gérer le travail de routine qui nécessite actuellement plusieurs transferts, permettant à vos équipes humaines de se concentrer sur ce qui a réellement besoin de leur expertise.

N'oubliez pas que les SLA sont un moyen d'atteindre une fin. Le but n'est pas d'atteindre parfaitement les SLA. Il s'agit de résoudre les problèmes des clients rapidement et efficacement. Parfois, cela signifie qu'une violation est le bon résultat, si cela signifie résoudre correctement le problème plutôt que de se précipiter pour respecter une échéance arbitraire.

Si vous êtes prêt à explorer comment l'IA pourrait aider votre équipe à atteindre ses cibles de manière plus cohérente, essayez eesel AI gratuitement et voyez comment un coéquipier IA peut transformer vos opérations de support.