zendesk-sla-reset-on-reply-or-status
Written by
eesel Team
Last edited 20 février 2026
{
"title": "Réinitialisation des SLA Zendesk lors d'une réponse ou d'un changement de statut : un guide complet",
"slug": "zendesk-sla-reset-on-reply-or-status",
"locale": "fr",
"date": "2026-02-20",
"updated": "2026-02-20",
"template": "default",
"excerpt": "Comprenez exactement quand les minuteurs SLA de Zendesk se réinitialisent ou se mettent en pause, et comment configurer des politiques pour des rapports précis.",
"categories": [
"Blog Writer AI"
],
"tags": [
"Zendesk",
"SLA",
"Customer Support",
"Help Desk",
"Ticket Management"
],
"readTime": 8,
"author": 16,
"reviewer": 14,
"seo": {
"title": "Réinitialisation des SLA Zendesk lors d'une réponse ou d'un changement de statut : un guide complet",
"description": "Comprenez exactement quand les minuteurs SLA de Zendesk se réinitialisent ou se mettent en pause, et comment configurer des politiques pour des rapports précis.",
"image": "https://wmeojibgfvjvinftolho.supabase.co/storage/v1/object/public/public_assets/blog-gen/banner-1241178b-17c8-46df-bc0d-ed634c2415d2"
},
"coverImage": "https://wmeojibgfvjvinftolho.supabase.co/storage/v1/object/public/public_assets/blog-gen/banner-1241178b-17c8-46df-bc0d-ed634c2415d2",
"coverImageAlt": "Image de bannière pour la réinitialisation des SLA Zendesk lors d'une réponse ou d'un changement de statut : un guide complet",
"coverImageWidth": 1920,
"coverImageHeight": 1080,
"faqs": {
"heading": "Foire aux questions",
"type": "blog",
"answerType": "html",
"faqs": [
{
"question": "Le changement de priorité d'un ticket réinitialise-t-il le minuteur SLA dans Zendesk ?",
"answer": "Non, le changement de priorité ne réinitialise pas les minuteurs SLA. La cible existante continue, mais la cible temporelle s'ajuste pour correspondre à la valeur configurée de la nouvelle priorité. Tout temps écoulé est reporté. Les violations qui se sont produites sous l'ancienne priorité restent dans vos rapports."
},
{
"question": "Comment puis-je empêcher le temps de prochaine réponse de compter lorsqu'aucune réponse n'est nécessaire ?",
"answer": "Zendesk n'a pas d'option native « aucune réponse nécessaire ». Les solutions de contournement courantes incluent : l'utilisation d'une macro pour ajouter puis privatiser immédiatement un commentaire public (remplissant le SLA sans visibilité client), le déplacement temporaire du ticket vers une politique SLA différente sans suivi du temps de prochaine réponse, ou l'utilisation de déclencheurs pour mettre le ticket en pause d'une manière qui arrête la métrique."
},
{
"question": "Quelle est la différence entre Mise à jour périodique et Mise à jour pouvant être mise en pause ?",
"answer": "Mise à jour périodique se réinitialise après chaque commentaire d'agent public et ne se met jamais en pause. Mise à jour pouvant être mise en pause se réinitialise également après les commentaires des agents, mais se met en pause lorsque le ticket est en statut En attente. Utilisez Mise à jour périodique lorsque vous souhaitez une responsabilité stricte pour la communication avec le client, quel que soit le statut. Utilisez Mise à jour pouvant être mise en pause lorsqu'il est acceptable que l'horloge s'arrête en attendant les clients."
},
{
"question": "Les politiques SLA s'appliquent-elles aux tickets créés par les agents ?",
"answer": "Le temps de première réponse standard ne calcule pas les tickets où un agent crée le ticket avec un commentaire public, car la cible est immédiatement satisfaite. Cependant, vous pouvez activer les paramètres avancés pour activer le temps de première réponse sur les tickets créés par les agents, en mesurant jusqu'à la deuxième réponse publique de l'agent."
},
{
"question": "Puis-je remplir une cible SLA avec une note interne au lieu d'une réponse publique ?",
"answer": "Par défaut, non. Les cibles SLA nécessitent des commentaires publics. Cependant, Zendesk offre des paramètres avancés (disponibles sur les plans admissibles) qui permettent aux cibles de temps de première réponse, de temps de prochaine réponse et de mise à jour périodique d'être remplies par des notes internes. Activez-les dans le Centre d'administration sous Objets et règles > Règles métier > Accords sur les niveaux de service > Paramètres avancés."
},
{
"question": "Quel plan Zendesk inclut les politiques SLA ?",
"answer": "Les politiques SLA sont incluses avec les plans Suite Professional et supérieurs, à partir de 115 $ par agent par mois en cas de facturation annuelle. Elles ne sont pas disponibles sur les plans Suite Team ou Support Team. Les SLA de groupe (pour le suivi de l'équipe interne) nécessitent des plans Enterprise."
}
],
"supportLink": null
}
}
---
La gestion des accords sur les niveaux de service (SLA, *Service Level Agreements*) dans [Zendesk](https://www.zendesk.com) peut donner l'impression d'essayer d'attraper de la fumée. Vous configurez des politiques, définissez des cibles et regardez les minuteurs décompter. Mais ensuite, quelque chose d'inattendu se produit : la priorité d'un ticket change, un client envoie un message qui n'a pas besoin de réponse ou votre équipe marque un ticket comme étant en attente. Soudain, ces minuteurs SLA se comportent d'une manière que vous n'aviez pas prévue.
Comprendre quand les minuteurs SLA de Zendesk se réinitialisent ou se mettent en pause n'est pas qu'un simple détail technique. C'est la différence entre des rapports précis et le fait de passer des heures chaque semaine à expliquer manuellement pourquoi les métriques semblent « fausses » à votre équipe de direction. Ce guide explique exactement comment ces mécanismes fonctionnent afin que vous puissiez configurer vos politiques en toute confiance.
## Comprendre la différence : réinitialisation *vs.* pause
Avant de plonger dans des métriques spécifiques, clarifions deux comportements fondamentalement différents :
**Réinitialisation** signifie que le minuteur recommence à compter à partir de zéro. Tout temps écoulé est effacé et le SLA recommence à zéro. Cela se produit lorsque des événements spécifiques déclenchent un nouveau cycle de mesure.
**Pause** signifie que le minuteur s'arrête temporairement, mais se souvient d'où il s'est arrêté. Lorsque les conditions changent, le minuteur reprend exactement là où il s'est arrêté. Aucun temps n'est perdu ni gagné.
Voici pourquoi cette distinction est importante. Lorsqu'un minuteur se réinitialise, votre équipe dispose d'une nouvelle fenêtre cible complète. Lorsqu'il se met en pause, la pression reste forte, car cette échéance initiale se profile toujours. Une mauvaise compréhension du comportement qui s'applique à chaque métrique conduit à une fausse confiance ou à une panique inutile.
## Pause SLA Zendesk sur le statut : quand les minuteurs s'arrêtent temporairement
Les métriques de résolution se comportent différemment des métriques de réponse. Au lieu de se réinitialiser lors des actions de l'agent, elles se mettent en pause en fonction du statut du ticket. Cela reflète mieux la réalité des flux de travail de support où le travail n'est pas toujours continu.
### Temps d'attente du demandeur
Le temps d'attente du demandeur mesure le temps total qu'un client passe à attendre votre équipe tout au long du cycle de vie du ticket. La partie astucieuse est qu'il se met automatiquement en pause lorsque le ticket est en statut En attente (en attendant le client).
Le minuteur fonctionne lorsque le ticket est Nouveau, Ouvert ou En attente. Lorsque vous le marquez comme En attente, la pause s'engage. Lorsque le client répond et que le statut revient à Ouvert, le minuteur reprend exactement là où il s'était arrêté.
Cette métrique vous donne la vision la plus centrée sur le client de votre performance. Elle répond à la question suivante : « Combien de temps cette personne a-t-elle réellement attendu après nous ? » et non « Combien de temps le ticket a-t-il existé ? ».
### Temps de travail de l'agent
Le temps de travail de l'agent pousse le concept de pause plus loin. Il ne compte que le temps où le ticket est en statut Nouveau ou Ouvert, en se mettant en pause à la fois sur En attente ET En suspens.
Pourquoi cette différence ? En suspens signifie généralement que vous attendez un tiers : un fournisseur, un transporteur, un autre service. Si vous attendez quelqu'un d'autre, vous ne travaillez pas activement sur le ticket, donc la métrique ne devrait pas compter contre votre équipe.
Cette métrique est particulièrement utile pour les équipes qui escaladent les tickets vers des parties externes. Elle mesure uniquement le temps pendant lequel les tickets sont réellement disponibles pour que vos agents travaillent dessus.
### Mise à jour pouvant être mise en pause
Mise à jour pouvant être mise en pause combine des concepts des deux catégories. Comme Mise à jour périodique, elle mesure le temps entre les commentaires des agents. Mais comme les métriques de résolution, elle se met en pause lorsque le ticket est En attente.
La cible s'active lorsqu'un agent fait son premier commentaire public alors que le ticket est Nouveau, Ouvert ou En attente. Elle se met en pause si le ticket passe en statut En attente. Elle reprend lorsque le ticket revient à Ouvert ou En attente.
Une bizarrerie à surveiller : si un agent soumet un commentaire public et change le statut en En attente dans la même action, la métrique Mise à jour pouvant être mise en pause ne s'appliquera pas tant que le ticket n'aura pas été soumis pour la première fois en statut Nouveau, Ouvert ou En attente avec un commentaire public. Cela fait trébucher certaines équipes qui s'attendent à ce que la métrique démarre immédiatement.
---
## Cas limites courants et solutions de contournement
Même avec des règles claires, les scénarios du monde réel compliquent le suivi des SLA. Voici les cas limites les plus courants que rencontrent les équipes de support.
### Le scénario « Aucune réponse nécessaire »
Votre agent résout un ticket. Le client répond par un simple « merci » ou une confirmation que la solution a fonctionné. Techniquement, cela crée une nouvelle cible de temps de prochaine réponse, car il y a un commentaire client sans réponse. Mais répondre semble maladroit et inutile.
Lorsque le client commente à nouveau sur un problème véritablement nouveau, le minuteur SLA compte à partir de son message original de « merci », et non de l'énoncé du nouveau problème. Cela crée de faux rapports de violation et fausse vos métriques.
Une solution de contournement consiste à utiliser une macro qui ajoute un bref commentaire public (qui remplit le SLA), puis le rend immédiatement privé afin que le client ne le voie jamais. Une autre approche consiste à déplacer temporairement le ticket vers une politique SLA différente qui n'applique pas le temps de prochaine réponse, en utilisant un déclencheur pour le remettre en place si le client envoie un autre message.
### Changements de priorité et fausses violations
Un ticket arrive avec une priorité Normale avec une cible de résolution de 24 heures. Après enquête, vous réalisez que c'est plus urgent et vous le changez en priorité Haute avec une cible de 4 heures. Le problème ? Si le ticket a déjà été violé sous la priorité Normale, cette violation reste dans vos rapports même si le ticket est maintenant traité de manière appropriée sous les cibles de priorité Haute.
Zendesk applique de nouvelles cibles de priorité à l'avenir, mais n'ajuste pas rétroactivement les données de violation historiques. Cela cause des maux de tête aux équipes qui essaient de rendre compte avec précision de la performance SLA.
Certaines équipes contournent ce problème en créant des tickets entièrement nouveaux lorsque la priorité change de manière significative, bien que cela perde l'historique des conversations. D'autres tiennent des feuilles de calcul de suivi distinctes pour noter quelles violations étaient « légitimes » par rapport aux « artefacts de changement de priorité ».
### Tickets rouverts
Lorsqu'un ticket résolu est rouvert, différentes métriques se comportent différemment :
- **Temps de première réponse et temps de prochaine réponse** : Activez de nouvelles cibles si rouvert avec un commentaire client public
- **Mise à jour périodique et Mise à jour pouvant être mise en pause** : Activez de nouvelles cibles uniquement si rouvert avec un commentaire public de l'agent
- **Temps de travail de l'agent et temps d'attente du demandeur** : Réactivez la même cible, en traitant le temps en statut Résolu comme une pause
- **Temps de résolution total** : Continue de compter à partir de la création du ticket, en traitant le temps Résolu comme une pause
Comprendre ces nuances aide à expliquer pourquoi les tickets rouverts semblent parfois avoir un comportement SLA étrange.
---
## Bonnes pratiques pour la configuration des politiques SLA
Après avoir compris les mécanismes de réinitialisation et de pause, comment devriez-vous réellement configurer vos politiques ? Voici des recommandations pratiques d'équipes qui ont appris à la dure.
Commencez simplement. Choisissez le temps de première réponse plus une métrique de résolution (le temps d'attente du demandeur est généralement le choix le plus centré sur le client). Familiarisez-vous avec ces bases avant d'ajouter de la complexité comme le temps de prochaine réponse ou la mise à jour périodique.
Choisissez soigneusement entre les heures ouvrables et les heures calendaires. Les heures ouvrables sont plus justes pour votre équipe, car elles ne comptent pas les nuits et les week-ends. Mais les clients vivent le temps calendaire. Un ticket soumis le vendredi soir donne l'impression d'être ouvert tout le week-end, même si votre horloge des heures ouvrables n'a pas beaucoup tourné. Certaines équipes utilisent les heures ouvrables pour les rapports internes et les heures calendaires pour les engagements envers les clients.
Commandez correctement vos politiques. Zendesk les évalue de haut en bas et applique la première correspondance. Placez vos politiques les plus restrictives en haut et les politiques générales de rattrapage en bas. Une erreur courante est d'avoir une politique générique qui correspond à tout avant que les politiques spécifiques ne soient évaluées.
Tenez compte des différences de canal. Les conversations de chat ont des attentes différentes de celles des tickets de courriel. Vous voudrez peut-être un temps de première réponse de 5 minutes pour le chat, mais une cible de 1 heure pour le courriel. Utilisez des conditions pour acheminer différents canaux vers différentes politiques.
Définissez des cibles réalistes en fonction de la capacité réelle, et non des objectifs ambitieux. Un SLA que vous violez constamment est pire que pas de SLA du tout. Il entraîne votre équipe à ignorer la métrique et érode la confiance avec les clients qui voient des engagements non tenus.
---
## Améliorer la performance SLA de Zendesk avec l'IA
Comprendre les mécanismes SLA est important. Mais ne serait-il pas préférable d'atteindre ces cibles sans effort ?
Les outils d'IA modernes vous aident à résoudre les tickets plus rapidement et de manière plus cohérente. [eesel AI](https://www.eesel.ai) offre [AI Agent](https://www.eesel.ai/product/ai-agent) et [AI Copilot](https://www.eesel.ai/product/ai-copilot) qui fonctionnent directement avec votre [intégration Zendesk](https://www.eesel.ai/integration/zendesk-ai) pour améliorer vos métriques.
Notre [AI Agent](https://www.eesel.ai/product/ai-agent) gère instantanément les questions courantes et répétitives. Un client pose des questions sur les réinitialisations de mot de passe, le statut de la commande ou le dépannage de base ? Il obtient une réponse précise en quelques secondes, pas en quelques heures. Votre temps de première réponse devient effectivement instantané pour ces tickets, et vos temps de résolution diminuent, car les problèmes de routine n'atteignent jamais une file d'attente humaine.
Pour les problèmes complexes qui nécessitent une intervention humaine, notre [AI Copilot](https://www.eesel.ai/product/ai-copilot) rédige des réponses en extrayant des informations de votre base de connaissances, des tickets passés et de la documentation connectée. Les agents examinent et envoient plutôt que de partir de zéro. Cela réduit le temps de travail de l'agent et permet aux clients d'obtenir des réponses plus rapidement.
Vous pouvez simuler notre IA sur vos tickets historiques avant de passer en direct. Voyez exactement comment elle se serait comportée par rapport à vos cibles SLA existantes. Ajustez les configurations en fonction de données réelles plutôt que d'espérer le meilleur.
Puisque nous nous intégrons directement à Zendesk, il n'y a pas de configuration complexe ni de changements de flux de travail. Vos politiques SLA existantes continuent de mesurer comme toujours, mais les chiffres sont meilleurs.
Partager cet article
Article by
