Le comportement natif : une fonctionnalité, pas un bug
Par défaut, quand un client répond à un email lié à un ticket fermé, HubSpot rouvre le ticket. C'est voulu : cela évite de perdre une relance client tombée après la clôture. Avant de parler de dysfonctionnement, vérifiez si les réouvertures correspondent à de vraies réponses de clients — auquel cas le système fait exactement son travail, et le désactiver vous ferait perdre des demandes légitimes.
Les faux déclencheurs à traquer
Le problème apparaît quand des emails non humains rouvrent les tickets : réponses automatiques d'absence, accusés de réception, notifications d'autres outils reçues sur le même fil. Filtrez ces expéditeurs et affinez les règles de votre boîte de réception partagée pour que ces messages n'agissent plus sur le statut. Vérifiez aussi qu'aucune automatisation externe, connectée par intégration, ne réédite le statut du ticketing à votre insu.
Les workflows qui se contredisent
Une cause fréquente : un workflow HubSpot qui réinscrit les tickets et repositionne un statut « ouvert » sur des critères trop larges. Si deux automatisations agissent sur la même propriété de statut, elles se battent et le ticket oscille. Auditez toutes les automatisations qui modifient le statut de ticket, cartographiez qui écrit quoi, et supprimez les chevauchements pour ne garder qu'une source de décision.
Stabiliser le processus
Une fois le déclencheur identifié, documentez la règle de réouverture voulue et alignez-la avec vos usages du Service Hub. Fixez noir sur blanc dans quels cas un ticket doit rouvrir, et confiez cette décision à une seule automatisation. Prévoyez enfin un contrôle régulier : une fois par mois, vérifiez sur un échantillon de tickets rouverts que la règle tient toujours et qu'aucune nouvelle intégration n'est venue la contourner. Un statut de ticket fiable est la base de tout reporting support crédible et de tout suivi de SLA.