Escalade du support prioritaire pour les comptes clés
Un ticket provenant d’un compte prioritaire atteint le bon responsable en quelques secondes, tandis que le même ticket alimente une vue bimensuelle des comptes en difficulté.
La situation
Les conversations de support étaient déjà traitées rapidement dans Gleap. Le Customer Success devait malgré tout savoir quand l’un de ses comptes les plus importants ouvrait un nouveau ticket. Lorsqu’un client à forte valeur le faisait, le bon responsable devait être informé rapidement ; le trouver demandait une recherche manuelle.
L’autre partie du problème suivait un autre rythme. Un ticket individuel décrit un moment. Il ne montre pas qu’un compte important a ouvert onze tickets en deux semaines — une information différente, qui peut signaler un risque de churn.
La contrainte
La solution facile consiste à envoyer une alerte Slack pour chaque ticket de support. Elle échoue en une semaine. Un canal qui se déclenche pour tout est réduit au silence. Une fois masquée, l’escalade devient pire que l’absence d’escalade, car chacun suppose que quelqu’un la surveille.
Le workflow n8n décide avant d’interrompre qui que ce soit. Il vérifie si le ticket a déjà été traité, associe le client à la bonne entreprise dans HubSpot, confirme que l’entreprise est un compte prioritaire et identifie le responsable de la relation. Ce n’est qu’ensuite que quelque chose atteint Slack.
Les webhooks ont rendu le problème plus difficile qu’il n’y paraît. La même conversation Gleap peut être livrée plusieurs fois. Sans garde-fou, cela crée des doublons et des alertes répétées — exactement le bruit que le design cherche à éviter. Chaque événement entrant est donc comparé à ce qui a déjà été traité avant toute autre action.
Les deux questions de l’équipe utilisent les mêmes données à des rythmes différents. Une alerte répond à « Qui a besoin d’attention maintenant ? ». Elle ne répond pas à « Quels comptes génèrent discrètement du volume de support depuis deux semaines ? ». Un enregistrement central des tickets sert les deux besoins, au lieu de séparer l’alerte et le reporting dans des workflows qui ne connaîtraient chacun qu’une moitié de l’histoire.
Ce que nous avons construit
Une nouvelle conversation Gleap est comparée aux tickets déjà traités puis enregistrée. Le client est associé à son entreprise HubSpot, l’entreprise est vérifiée comme compte prioritaire et le responsable Customer Success est identifié. Les tickets des comptes ordinaires s’arrêtent là et restent dans Gleap, où ils doivent être traités.
Les comptes prioritaires et les clients ordinaires reçoivent le même support dans Gleap. Le rôle supplémentaire du système est de montrer au Customer Success lorsqu’un compte clé rencontre un problème avec un service, afin que le responsable concerné décide s’il doit contacter le client personnellement.
Les tickets prioritaires sont enrichis avec les données du compte et du responsable, puis publiés dans le canal Customer Success avec le client, l’entreprise, le sujet, le responsable et un lien direct vers la conversation. Toutes les deux semaines, un second workflow lit les mêmes enregistrements, les regroupe par compte et par responsable, les compte et écrit une ligne par compte dans un tableur partagé pour la période. Avec le temps, cela crée un historique plutôt qu’un instantané.
Où en est le système
Le Customer Success voit quels comptes clés ont des problèmes ouverts et peut décider de contacter personnellement le client, en parallèle du support courant déjà traité dans Gleap. La vue bimensuelle rend visibles les tensions récurrentes au niveau du compte au lieu de les laisser isolées dans les conversations de support.
Réalisation suivante
Analyse des retours clients par IA pour de meilleures décisions produit
Prêt à améliorer vos résultats grâce à l’automatisation IA ?
Réservez un diagnostic opérationnel de 30 minutes. Nous examinerons où le travail manuel freine votre activité et s’il existe une manière concrète de créer de la capacité.
Réserver un diagnostic opérationnelSwiss precision. Valley speed.