Une automatisation de la réactivation client qui sait quand ne pas envoyer
Lorsqu’un utilisateur devient silencieux pendant une semaine, le système étudie le compte, prépare un message pertinent et décide si un e-mail automatisé est approprié.
La situation
Lorsqu’un utilisateur n’a pas utilisé le produit pendant sept jours, la réponse habituelle est un e-mail de reconquête qui semble envoyé à tous ceux qui sont devenus inactifs pendant la semaine — parce que c’est le cas.
Un message de réactivation utile a besoin de contexte : quels services le compte utilise, à quel niveau il les utilisait avant de s’arrêter, s’il s’agit d’un compte prioritaire et si quelqu’un du Customer Success a parlé à la personne trois jours auparavant. Sans ce contexte, l’e-mail automatisé est au mieux ignoré et, au pire, envoyé à quelqu’un en pleine conversation avec son account manager.
La contrainte
La construction tentante consiste à laisser un modèle lire le compte, écrire l’e-mail et l’envoyer. Cela fonctionne dans une démo, mais produit la mauvaise architecture. Un modèle qui peut déclencher une action est un modèle dont le mauvais jour atteint un client.
L’agent renvoie des champs structurés plutôt qu’un texte accompagné d’une action : objet, corps, responsable Customer Success et évaluation indiquant si un échange d’e-mails pertinent a déjà eu lieu. Le workflow lit ces champs et applique ses propres règles. Le modèle contribue à l’écriture et à l’évaluation ; il ne décide jamais de la suite.
Tous les utilisateurs inactifs ne doivent pas recevoir un e-mail automatisé. Un compte prioritaire, un utilisateur qui envoyait beaucoup de volume ou une personne ayant un fil actif peut nécessiter une réponse personnelle. Dans ces cas, un message automatisé peut signaler que personne ne suit le compte. Le workflow envoie plutôt tout le contexte dans Slack et une personne décide s’il faut reprendre contact.
La recherche sur la personne et l’entreprise s’exécute en parallèle : données CRM, historique des réunions, LinkedIn, contacts précédents, données d’entreprise et recherche externe. Le parallélisme maintient le workflow assez rapide pour que le signal reste utile.
Ce que nous avons construit
Sept jours d’inactivité créent un événement avec l’identité de l’utilisateur et son usage du produit. Le workflow trouve le contact HubSpot, récupère l’entreprise associée, l’étape du cycle de vie et le statut prioritaire, puis exécute en parallèle les recherches sur la personne et l’entreprise.
L’agent renvoie une sortie structurée. Le workflow la route ensuite. Les comptes standard éligibles reçoivent un e-mail adapté depuis la boîte du bon responsable Customer Success plutôt qu’une adresse générique. Les comptes nécessitant davantage d’attention sont envoyés dans Slack avec le contexte et le responsable assigné, afin que le propriétaire de la relation décide de la suite.
Schéma du processus
Où en est le système
Les utilisateurs inactifs reçoivent des messages qui reflètent leur compte plutôt que leur simple statut. Les comptes pour lesquels un message automatisé pourrait être nuisible n’en reçoivent pas.
Réalisation suivante
Trouvez des entreprises similaires à partir de vos meilleurs clients
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.