zendesk-automation-reopen-ticket-conditions
Written by
eesel Team
Last edited 24 février 2026
{
"title": "Conditions de réouverture automatisée des tickets Zendesk : un guide complet pour 2026",
"slug": "zendesk-automation-reopen-ticket-conditions",
"locale": "fr",
"date": "2026-02-24",
"updated": "2026-02-24",
"template": "default",
"excerpt": "Maîtrisez les conditions de réouverture automatisée des tickets Zendesk grâce à ce guide complet. Découvrez quand utiliser les déclencheurs (triggers) par rapport aux automatisations, configurez les flux de travail de réouverture et résolvez le problème des « mercis ».",
"categories": [
"Blog Writer AI"
],
"tags": [
"Zendesk",
"Automation",
"Customer Support",
"Ticket Management",
"Help Desk"
],
"readTime": 16,
"author": 16,
"reviewer": 14,
"seo": {
"title": "Conditions de réouverture automatisée des tickets Zendesk : un guide complet pour 2026",
"description": "Maîtrisez les conditions de réouverture automatisée des tickets Zendesk grâce à ce guide complet. Découvrez quand utiliser les déclencheurs (triggers) par rapport aux automatisations, configurez les flux de travail de réouverture et résolvez le problème des « mercis ».",
"image": "https://wmeojibgfvjvinftolho.supabase.co/storage/v1/object/public/public_assets/blog-gen/banner-1a926c95-0d50-40c9-aa02-3a4a37caae17"
},
"coverImage": "https://wmeojibgfvjvinftolho.supabase.co/storage/v1/object/public/public_assets/blog-gen/banner-1a926c95-0d50-40c9-aa02-3a4a37caae17",
"coverImageAlt": "Image de bannière pour les conditions de réouverture automatisée des tickets Zendesk : un guide complet pour 2026",
"coverImageWidth": 1920,
"coverImageHeight": 1080,
"faqs": {
"heading": "Foire aux questions",
"type": "blog",
"answerType": "html",
"faqs": [
{
"question": "Comment configurer les conditions de réouverture automatisée des tickets Zendesk pour notifier immédiatement mon équipe ?",
"answer": "Utilisez un déclencheur (trigger) (et non une automatisation) avec la condition « Catégorie de statut | Est modifié en | Ouvert ». Ajoutez « Commentaire | Est | Public » pour vous assurer qu’il ne se déclenche que sur les réponses des clients. Définissez l’action pour envoyer un e-mail à la personne affectée ou à un groupe."
},
{
"question": "Les conditions de réouverture automatisée des tickets Zendesk peuvent-elles fonctionner avec des statuts de ticket personnalisés ?",
"answer": "Oui, mais utilisez « Catégorie de statut » au lieu de « Statut » dans vos conditions. Les statuts personnalisés sont regroupés en catégories (Nouveau, Ouvert, En attente, Résolu, Fermé). La condition « Catégorie de statut » prend en compte toutes les variations au sein d’une catégorie."
},
{
"question": "Quelle est la meilleure façon d’empêcher les conditions de réouverture automatisée des tickets Zendesk de se déclencher plusieurs fois ?",
"answer": "Ajoutez une condition de neutralisation à l’aide de balises (tags). Incluez « Balises | Ne contient aucune des suivantes | [votre-balise] » dans les conditions, puis ajoutez cette balise comme action lorsque l’automatisation se déclenche. Cela garantit qu’elle ne s’exécute qu’une seule fois par ticket."
},
{
"question": "Comment puis-je utiliser les conditions de réouverture automatisée des tickets Zendesk pour planifier des suivis ?",
"answer": "Utilisez le statut En attente + le flux de travail Date d’échéance. Créez une macro qui définit le Type sur Tâche, le Statut sur En attente et invite à entrer une date d’échéance. Créez ensuite une automatisation avec « Heures depuis la date d’échéance | Supérieur à | 0 » qui rétablit le statut sur Ouvert."
},
{
"question": "Pourquoi mes conditions de réouverture automatisée des tickets Zendesk manquent-elles certains tickets ?",
"answer": "Si vous utilisez des conditions basées sur le temps, évitez « Est » et utilisez plutôt « Supérieur à ». Les automatisations s’exécutent toutes les heures, donc « Est 24 » peut manquer les tickets qui atteignent 24 heures entre les vérifications. « Supérieur à 24 » prend en compte tous les tickets qui ont dépassé le seuil."
},
{
"question": "Les conditions de réouverture automatisée des tickets Zendesk peuvent-elles faire la distinction entre les réponses des clients et les notes internes ?",
"answer": "Oui. Ajoutez « Commentaire | Est | Public » à vos conditions pour ne déclencher que les commentaires visibles par le client. Utilisez « Commentaire | Est | Privé » pour les flux de travail réservés à un usage interne. Ceci est essentiel pour éviter les faux déclenchements dus à l’activité des agents."
}
],
"supportLink": null
}
}
---
La gestion des réouvertures de tickets est l’un de ces flux de travail qui semble simple jusqu’à ce qu’il ne le soit plus. Vous résolvez un ticket, le client répond par un rapide « merci » et, soudain, ce ticket se retrouve dans votre file d’attente ouverte, encombrant votre charge de travail. Ou pire, un ticket reste résolu pendant des jours alors qu’il nécessitait en fait un suivi, et vous avez maintenant manqué votre chance d’aider.
Pour que les conditions de réouverture automatisée de vos tickets Zendesk soient correctes, vous devez créer des flux de travail qui gèrent ces scénarios de manière intelligente. Toutes les réponses des clients ne nécessitent pas une réouverture. Tous les tickets résolus ne doivent pas rester résolus pour toujours. L’astuce consiste à savoir quel outil utiliser et quand.
Ce guide vous explique exactement comment configurer les automatisations et les déclencheurs (triggers) pour les scénarios de réouverture. Que vous essayiez d’informer les agents des tickets rouverts, de planifier des suivis ultérieurs ou d’arrêter la redoutable boucle de réouverture des « mercis », vous trouverez les conditions et les étapes spécifiques dont vous avez besoin.
Et si vous vous retrouvez à créer des chaînes de déclencheurs (triggers) de plus en plus complexes pour gérer des scénarios nuancés, nous verrons comment [nous abordons ces défis différemment chez eesel AI](https://www.eesel.ai/integration/zendesk-ai).
## Comprendre le fonctionnement de la réouverture des tickets Zendesk
Avant de nous plonger dans les conditions et les configurations, clarifions le fonctionnement réel de la réouverture des tickets dans Zendesk. La plateforme suit un cycle de vie strict qui détermine ce qui peut et ne peut pas se produire à chaque étape.
Le cycle de vie standard d’un ticket ressemble à ceci : **Nouveau → Ouvert → En attente → Résolu → Fermé** ([Documentation Zendesk](https://support.zendesk.com/hc/en-us/articles/4408885654298))
Voici ce que signifie chaque statut :
- **Nouveau** : Le ticket vient d’être créé et n’a pas encore été affecté
- **Ouvert** : Un agent travaille activement sur le ticket
- **En attente** : L’agent attend des informations du client
- **Résolu** : L’agent estime que le problème est résolu
- **Fermé** : Le ticket est verrouillé et ne peut pas être modifié
La règle essentielle pour la réouverture : **Les tickets ne peuvent être rouverts qu’à partir du statut Résolu.** Une fois qu’un ticket atteint le statut Fermé, il est permanent. C’est voulu. Les tickets fermés deviennent des enregistrements historiques qui préservent l’intégrité des données à des fins de reporting et de conformité.
Lorsqu’un client répond à un ticket Résolu, Zendesk rétablit automatiquement le statut sur Ouvert. Il s’agit du scénario de réouverture le plus courant. Mais c’est aussi ce qui cause le plus de maux de tête. Cet e-mail de « merci beaucoup ! » d’un client satisfait ? Il rouvre le ticket au même titre qu’un suivi de type « cela n’a pas fonctionné ».
Il est important de comprendre ce cycle de vie, car vos conditions d’automatisation doivent en tenir compte. Vous ne pouvez pas créer une automatisation qui rouvre un ticket Fermé (Zendesk ne le permettra pas). Vous pouvez toutefois créer des flux de travail sophistiqués qui gèrent intelligemment la transition Résolu → Ouvert.
Pour les équipes qui trouvent ces limitations natives restrictives, [notre intégration Zendesk](https://www.eesel.ai/integration/zendesk-ai) offre une approche alternative qui lit l’intention plutôt que de simplement vérifier les champs de statut.
## Déclencheurs (triggers) vs. automatisations : quand utiliser chacun d’eux pour les scénarios de réouverture
Zendesk vous offre deux outils d’automatisation : les déclencheurs (triggers) et les automatisations. Ils se ressemblent, mais ils fonctionnent très différemment. Utiliser le mauvais pour votre flux de travail de réouverture est la recette de la frustration.
### Déclencheurs (triggers) : basés sur des événements et immédiats
Les déclencheurs (triggers) se déclenchent instantanément lorsqu’un ticket remplit leurs conditions. Ils sont parfaits pour les réponses en temps réel aux changements de statut. Pour en savoir plus, consultez [la documentation sur les déclencheurs (triggers) de Zendesk](https://support.zendesk.com/hc/en-us/articles/4408893545882).
**Utilisez les déclencheurs (triggers) lorsque :**
- Vous souhaitez une notification immédiate lorsqu’un ticket est rouvert
- Vous devez prendre des mesures en fonction de la personne qui a mis à jour le ticket
- Vous répondez aux transitions de statut (Résolu → Ouvert)
**La condition essentielle pour les déclencheurs (triggers) de réouverture :**
Ticket : Catégorie de statut | Est modifié en | Ouvert
Cette condition ne se déclenche que lorsque le statut d’un ticket passe réellement à Ouvert, et non lorsqu’il « est » simplement Ouvert. C’est cette distinction qui fait que les déclencheurs (triggers) fonctionnent pour les scénarios de réouverture.
### Automatisations : basées sur le temps et planifiées
Les automatisations s’exécutent selon un calendrier (environ une fois par heure). Elles sont conçues pour les actions qui doivent se produire après un certain temps. Consultez [le guide d’automatisation de Zendesk](https://support.zendesk.com/hc/en-us/articles/4408883801626) pour plus de détails.
**Utilisez les automatisations lorsque :**
- Vous souhaitez assurer le suivi des tickets qui ont été résolus pendant X heures
- Vous planifiez la réouverture des tickets à des heures spécifiques
- Vous avez besoin d’une escalade basée sur le temps (ticket ouvert depuis plus de 24 heures)
**Conditions courantes basées sur le temps :**
Ticket : Heures depuis la résolution | Supérieur à | 24 Ticket : Heures depuis la mise en attente | Supérieur à | 48 Ticket : Heures depuis la date d’échéance | Supérieur à | 0
### Le cadre de décision
Voici comment choisir :
| Scénario | Utiliser | Pourquoi |
|----------|-----|-----|
| Notifier la personne affectée lorsque le client rouvre | Déclencheur (trigger) | Doit se produire immédiatement |
| Escalader si le ticket reste ouvert 24 h | Automatisation | Condition basée sur le temps |
| Planifier la réouverture du ticket la semaine prochaine | Automatisation | Condition de temps future |
| Baliser (tag) les tickets rouverts pour le reporting | Déclencheur (trigger) | Capturer l’événement lorsqu’il se produit |
| Fermer les tickets résolus pendant 96 heures | Automatisation | Action basée sur le temps |
La chose essentielle à retenir : les déclencheurs (triggers) réagissent aux événements, les automatisations réagissent au temps. La plupart des flux de travail de réouverture ont en fait besoin des deux. Vous pouvez utiliser un déclencheur (trigger) pour notifier immédiatement la personne affectée, puis une automatisation pour escalader si le ticket reste ouvert trop longtemps.
Pour en savoir plus sur l’automatisation basée sur le temps, consultez notre [guide sur les conditions d’automatisation Zendesk](https://www.eesel.ai/blog/zendesk-automation-conditions-to-act-after-hours-since-status-change) pour agir après les heures suivant le changement de statut.
## Conditions essentielles pour les automatisations de tickets de réouverture
La création de flux de travail de réouverture efficaces nécessite de comprendre toute la gamme de conditions disponibles. Voici la référence complète des conditions que vous utiliserez réellement.
### Conditions basées sur le statut
Ce sont vos bases pour les scénarios de réouverture :
**Catégorie de statut | Est modifié en | Ouvert**
- Se déclenche lorsqu’un ticket passe au statut OUVERT
- À utiliser dans les déclencheurs (triggers) pour une notification immédiate
- Condition de détection de réouverture la plus courante
**Statut | Est modifié de | Résolu**
- Se déclenche lorsqu’un ticket quitte le statut Résolu
- Plus spécifique que « Est modifié en Ouvert » (prend en compte Résolu → n’importe quel statut)
- Utile lorsque vous souhaitez suivre tout mouvement hors du statut Résolu
**Catégorie de statut | Est | Ouvert**
- Vérifie l’état actuel, pas les transitions
- À utiliser dans les automatisations pour une surveillance continue
- Exemple : « Le statut est Ouvert ET Heures depuis l’ouverture > 24 »
### Conditions basées sur le temps
Les automatisations reposent fortement sur celles-ci :
**Heures depuis la résolution | Supérieur à | [nombre]**
- Le plus courant pour le suivi post-résolution
- Utilisez « Supérieur à » et non « Est » (plus fiable)
- N’oubliez pas : les automatisations s’exécutent toutes les heures, la synchronisation n’est donc pas exacte
**Heures depuis la mise en attente | Supérieur à | [nombre]**
- Pour l’escalade des tickets obsolètes
- Valeur courante : 48 heures (2 jours ouvrables)
**Heures depuis la date d’échéance | Supérieur à | 0**
- Pour les flux de travail de réouverture planifiés
- Fonctionne uniquement avec les tickets de type Tâche qui ont des dates d’échéance
**Heures depuis l’ouverture | Supérieur à | [nombre]**
- Pour l’escalade des tickets qui restent ouverts trop longtemps
- Utile pour les SLA et les augmentations de priorité
### Conditions de participant
Elles vous aident à distinguer QUI a causé la réouverture :
**Utilisateur actuel | Est | (utilisateur final)**
- Garantit que le déclencheur (trigger) ne se déclenche que sur les actions du client
- Essentiel pour éviter les boucles de réouverture déclenchées par l’agent
**Utilisateur actuel | Est | (agent)**
- Pour les flux de travail où les actions de l’agent sont importantes
- Moins courant pour les scénarios de réouverture
**Commentaire | Est | Public**
- Distingue les commentaires des clients des notes internes
- Essentiel pour les flux de travail « le client a répondu »
**Commentaire | Est | Privé**
- Pour les flux de travail réservés à un usage interne
- Rarement utilisé pour les scénarios de réouverture
### Conditions de neutralisation (empêcher les boucles)
L’erreur d’automatisation la plus courante : oublier d’empêcher l’automatisation de s’exécuter à plusieurs reprises. Incluez toujours une condition de neutralisation.
**Balises | Ne contient aucune des suivantes | [votre-balise]**
- Ajoutez la balise comme action lorsque l’automatisation se déclenche
- Empêche la réexécution sur le même ticket
- Exemple : Balise « reopen_notified » après la première notification
**Pourquoi « Supérieur à » est préférable à « Est » pour les conditions de temps**
Les automatisations Zendesk s’exécutent selon un cycle horaire. Si vous utilisez « Heures depuis la résolution | Est | 24 », l’automatisation peut vérifier à 23,5 heures (manque) puis à 24,5 heures (manque à nouveau). L’utilisation de « Supérieur à » vous assure de prendre en compte tous les tickets éligibles.
## Étape par étape : création d’un déclencheur (trigger) de notification de réouverture
Créons un déclencheur (trigger) pratique qui notifie aux personnes affectées lorsque leurs tickets résolus sont rouverts. Il s’agit de l’un des flux de travail de réouverture les plus courants.
### Étape 1 : Accédez à la page des déclencheurs (triggers)
Accédez à **Centre d’administration > Objets et règles > Règles métier > Déclencheurs (triggers)**. Vous verrez une liste des déclencheurs (triggers) existants. Ne supprimez pas les déclencheurs (triggers) standard, sauf si vous savez exactement ce qu’ils font. Consultez [la référence des conditions de déclenchement (trigger) de Zendesk](https://support.zendesk.com/hc/en-us/articles/4408893545882) pour connaître toutes les options de condition.
### Étape 2 : Créer un nouveau déclencheur (trigger)
Cliquez sur **Ajouter un déclencheur (trigger)**. Donnez-lui un nom descriptif tel que :
- « Notifier la personne affectée lorsque le ticket est rouvert par le client »
- « Notification de ticket rouvert »
Évitez les noms vagues comme « Déclencheur (trigger) 1 ». Votre futur vous remerciera de votre présent lors du dépannage.
### Étape 3 : Définir les conditions
Sous « Remplir TOUTES les conditions suivantes », ajoutez :
Ticket : Catégorie de statut | Est modifié en | Ouvert
**Ajouts facultatifs mais recommandés :**
Ticket : Commentaire | Est | Public
(Cela garantit qu’il ne se déclenche que sur les réponses des clients, pas sur les notes internes)
Ticket : Utilisateur actuel | Est | (utilisateur final)
(Cela confirme que le client a causé la réouverture, pas un agent)
Ticket : Balises | Ne contient aucune des suivantes | reopen_notified
(Cela empêche le déclencheur (trigger) de se déclencher deux fois sur le même ticket)
### Étape 4 : Configurer les actions
Sous « Effectuer ces actions », ajoutez :
**Notifier la personne affectée :**
Notifications : Envoyer un e-mail à l’utilisateur | (personne affectée) Objet : « Ticket rouvert par le client : {{ticket.title}} » Corps : Inclure les détails du ticket et le lien
**Ajouter une balise de suivi :**
Ticket : Ajouter des balises | reopen_notified
**Facultatif : Définir la priorité :**
Ticket : Priorité | Haute
(Utile si les tickets rouverts nécessitent une attention immédiate)
### Étape 5 : Tester votre déclencheur (trigger)
1. Enregistrez le déclencheur (trigger) (il s’active automatiquement)
2. Créez un ticket de test ou utilisez-en un existant
3. Résolvez le ticket
4. Ajoutez un commentaire public en tant qu’utilisateur final (utilisez une fenêtre de navigation privée ou un compte différent)
5. Vérifiez que le statut passe à Ouvert
6. Vérifiez que la personne affectée a reçu la notification
Si cela ne fonctionne pas, vérifiez la position du déclencheur (trigger). Zendesk traite les déclencheurs (triggers) de haut en bas. Si un autre déclencheur (trigger) modifie le ticket en premier, le vôtre risque de ne pas se déclencher.
Le générateur d’automatisation utilise une interface similaire, mais se concentre sur les conditions basées sur le temps au lieu des événements immédiats :
Pour une autre approche des déclencheurs (triggers) de changement de statut, consultez notre [guide sur la création de déclencheurs (triggers) Zendesk lorsque le statut passe à ouvert](https://www.eesel.ai/en/blog/zendesk-trigger-when-status-changed-to-open).
## Recette : Planification de la réouverture des tickets à des heures spécifiques
Parfois, vous devez « mettre en veille » un ticket pour un suivi ultérieur. Peut-être qu’un client a dit « revenez me voir la semaine prochaine » ou que vous devez vérifier qu’un correctif a fonctionné avant de fermer complètement. Voici comment créer un flux de travail de réouverture planifié.
### Étape 1 : Activer le statut En attente
Par défaut, le statut En attente n’est pas actif. Accédez à **Centre d’administration > Objets et règles > Tickets > Statuts** et ajoutez le statut En attente si ce n’est pas déjà fait. Consultez [la recette de réouverture planifiée de Zendesk](https://support.zendesk.com/hc/en-us/articles/7509181267226) pour plus de détails.
### Étape 2 : Créer une macro pour les agents
Les macros garantissent que les agents suivent le flux de travail de manière cohérente. Créez une macro qui :
1. Définit le **Type** sur **Tâche**
2. Définit le **Statut** sur **En attente**
3. Ajoute une balise (tag) personnalisée (comme « schedule_reopen »)
4. Invite l’agent à définir le champ **Date d’échéance**
**Pour créer la macro :**
- Centre d’administration > Espaces de travail > Outils d’agent > Macros
- Ajouter une macro
- Actions : Type = Tâche, Statut = En attente, Ajouter des balises = schedule_reopen
### Étape 3 : Créer l’automatisation de réouverture
Créez maintenant une automatisation qui surveille les dates d’échéance :
**Conditions :**
Ticket : Catégorie de statut | Est | En attente Ticket : Type | Est | Tâche Ticket : Balises | Contient au moins une des suivantes | schedule_reopen Ticket : Heures depuis la date d’échéance | Supérieur à | 0
**Actions :**
Ticket : Catégorie de statut | Ouvert Ticket : Ajouter des balises | auto_reopened
La condition « Heures depuis la date d’échéance > 0 » signifie « la date d’échéance est dépassée ». Lorsque l’automatisation s’exécute (toutes les heures), tout ticket dont la date d’échéance est dépassée sera rouvert.
### Comment les agents utilisent ce flux de travail
1. L’agent applique la macro à un ticket
2. L’agent sélectionne la date de réouverture souhaitée dans le champ Date d’échéance
3. Le ticket passe en statut En attente
4. À la date sélectionnée, l’automatisation le rouvre automatiquement
Ce flux de travail est particulièrement utile pour :
- Rappels de suivi
- Attente de dépendances externes
- Problèmes saisonniers ou urgents
- Rappels demandés par le client
## Résoudre le problème de la réouverture des « mercis »
Voici une statistique de la communauté Zendesk qui pourrait vous parler : **60 à 70 % des réouvertures de tickets ne sont que des clients qui disent « merci ».** Pas de questions de suivi. Pas de plaintes. Juste une gratitude polie qui crée un travail inutile pour les agents.
Le défi consiste à distinguer les remerciements sincères des « mercis, mais j’ai encore besoin d’aide ». Un simple déclencheur (trigger) de mots-clés qui résout automatiquement tout ce qui contient « merci » finira par manquer un problème réel.
### Solution 1 : La méthode du hashtag
Formez les clients à utiliser un hashtag spécifique lorsqu’ils ont réellement besoin d’une réouverture. Dans votre e-mail de ticket résolu, incluez un texte tel que :
> « Si vous avez besoin d’aide supplémentaire, répondez avec #reopen et nous vous répondrons. Sinon, pas besoin de répondre. »
**Configuration du déclencheur (trigger) :**
Conditions :
- Catégorie de statut | Est modifié en | Ouvert
- Texte du commentaire | Ne contient pas la chaîne suivante | #reopen
Actions :
- Statut | Résolu
- Ajouter des balises | false_reopen
- Envoyer un e-mail au demandeur | « Votre ticket reste résolu. Répondez avec #reopen si vous avez besoin d’aide. »
Cela fonctionne, mais nécessite l’éducation du client. Tous les clients ne lisent pas attentivement.
### Solution 2 : Le déclencheur (trigger) de résolution automatique (avec des garanties)
Créez un déclencheur (trigger) qui résout automatiquement les tickets contenant « merci » ou « remerciements », mais UNIQUEMENT lorsqu’aucun point d’interrogation n’est présent.
**Configuration du déclencheur (trigger) :**
Conditions :
- Catégorie de statut | Est modifié en | Ouvert
- Texte du commentaire | Contient au moins une des suivantes | merci remerciements
- Texte du commentaire | Ne contient aucune des suivantes | ?
Actions :
- Statut | Résolu
- Ajouter des balises | auto_solved_thanks
Cela prend en compte « Merci pour votre aide ! » mais manque « Merci, mais comment puis-je... ? »
### Solution 3 : Applications tierces
L’application [Thank You GPT](https://www.zendesk.com/marketplace/apps/support/470124/thank-you-gpt) de [Zendesk Marketplace](https://www.zendesk.com/marketplace) utilise l’IA pour détecter les remerciements sincères par rapport aux questions de suivi. Elle est spécialement conçue pour ce problème.
### Solution 4 : Détection basée sur l’IA (avancée)
Pour les équipes ayant accès à [Zapier](https://zapier.com) et [OpenAI](https://openai.com), vous pouvez créer un flux de travail sophistiqué :
1. Le déclencheur (trigger) détecte la réouverture et ajoute une balise (tag)
2. Zapier surveille une vue pour les tickets balisés (tagged)
3. OpenAI analyse le commentaire : « Est-ce juste un remerciement ou y a-t-il une vraie question ? »
4. Si ce ne sont que des remerciements, Zapier résout le ticket via l’API
Un responsable du service client d’une grande entreprise a partagé sa configuration :
<quote text="J’ai créé une automatisation via Zapier en utilisant une invite dans OpenAI, qui fait des merveilles pour nous. Je le recommande vivement." sourceIcon="https://www.iconpacks.net/icons/2/free-reddit-logo-icon-2436-thumb.png" sourceName="Communauté Zendesk" sourceLink="https://support.zendesk.com/hc/de/community/posts/4409222754970-Stopping-the-reopening-tickets-by-a-Thank-you-response/">
</quote>
### Notre recommandation
Commencez par la solution 2 (résolution automatique avec protection par point d’interrogation). C’est simple, gratuit et cela prend en compte la plupart des cas. Si vous êtes toujours submergé par les réouvertures de remerciements, passez à l’application Thank You GPT ou envisagez une approche basée sur l’IA.
En parlant de cela, [notre agent IA](https://www.eesel.ai/product/ai-agent) gère ce scénario exact en comprenant l’intention plutôt que de simplement faire correspondre les mots-clés. Il connaît la différence entre « merci ! » et « merci, mais... » sans chaînes de déclencheurs (triggers) complexes.
## Erreurs courantes et dépannage
Même les administrateurs Zendesk expérimentés rencontrent des problèmes avec les automatisations de réouverture. Voici les problèmes les plus courants et comment les résoudre.
### Le déclencheur (trigger) ne se déclenche pas
**Vérifiez la position du déclencheur (trigger).** Zendesk traite les déclencheurs (triggers) de haut en bas. Si un autre déclencheur (trigger) modifie le ticket en premier (en particulier celui qui modifie le statut ou ajoute des balises (tags)), le vôtre risque de ne jamais avoir la chance de s’exécuter. Déplacez votre déclencheur (trigger) de réouverture vers le haut.
**Vérifiez « Est modifié en » par rapport à « Est ».** C’est l’erreur n° 1. « Le statut est Ouvert » correspond à n’importe quel ticket ouvert. « Le statut est modifié en Ouvert » ne correspond qu’aux tickets qui viennent de devenir ouverts. Pour la détection de réouverture, vous avez besoin de « Est modifié en ».
**Vérifiez votre champ de statut.** Si vous avez activé des statuts personnalisés, utilisez « Catégorie de statut » et non « Statut ». Si vous utilisez un plan Team sans statuts personnalisés, utilisez « Statut ».
### L’automatisation s’exécute plusieurs fois
**Vous avez oublié une condition de neutralisation.** Chaque automatisation a besoin d’un moyen de s’empêcher de s’exécuter à plusieurs reprises. Ajoutez une balise (tag) lorsque l’automatisation se déclenche, puis incluez « Les balises (tags) ne contiennent aucune des suivantes » dans vos conditions.
**Exemple de correctif :**
Conditions :
- Statut | Résolu
- Heures depuis la résolution | Supérieur à | 24
- Balises | Ne contient aucune des suivantes | solved_24h_notified
Actions :
- Envoyer un e-mail à la personne affectée | « Le ticket a été résolu depuis 24 heures »
- Ajouter des balises | solved_24h_not
Partager cet article
Article by
