Les conditions de déclenchement des Playbooks

Les conditions de déclenchement des Playbooks

• Déclencheurs liés à un évènement
  • Conditions liées à une propriété client
  • Conditions liées à une propriété contact
  • Conditions liées au score de santé
  • Conditions liées aux interactions
  • Conditions liées aux usages
  • Conditions liées aux opportunités
• Playbooks programmés
  • Cas d'usage
  • Configuration
  • Limite de fréquence par client ou contact

Un Playbook commence toujours par une condition de déclenchement (trigger). Même si le déclenchement est manuel, cela doit être spécifié au début du Playbook.

Il existe deux grandes catégories de déclencheurs : les déclencheurs liés à un évènement (changement de propriété, interaction, usage...), qui réagissent à quelque chose qui se passe sur un client ou un contact, et les playbooks programmés, qui se déclenchent à une date ou une récurrence définie, indépendamment de tout évènement.

Astuce

Un Playbook déclenché par un trigger automatique peut toujours être lancé manuellement (voir la rubrique sur le déclenchement manuel).

Un playbook qui a le déclencheur "Activation Manuelle" n'est jamais déclenché automatiquement, sauf si un autre playbook le déclenche (action "Lancer un nouveau playbook").

Playbooks de qualification

Si vous avez défini un playbook de qualification, qui se déclenche à la création d'un client, puis qui lui met des tags, lui assigne le bon profil de score de santé etc, il ne sera pas joué sur tous les clients existants. Pour le déclencher sur tous ces clients, vous devez le déclencher manuellement.

Pour chacune de ces conditions de déclenchement, n'oubliez pas d'afficher les filtres avancés afin de voir toutes les options de configuration possibles.

Déclencheurs liés à un évènement

Conditions liées à une propriété client

• Activation manuelle : déclenché uniquement manuellement ou par un autre Playbook (action > Lancer un nouveau Playbook).

• Nouveau client créé : déclenché à la création d’un nouveau client.

• Phase du cycle de vie (stage) modifiée : déclenché lorsqu'un client change de phase de cycle de vie (stage).

• Phase du cycle de vie non modifiée : déclenché lorsqu'un client n'a pas changé de phase de cycle de vie depuis une durée à définir.

• Profil modifié : déclenché lorsqu'un client change de profil de score de santé (Healthscore profile).

• Date de renouvellement proche : déclenché lorsqu'un client approche de sa date de renouvellement de contrat de X jours/mois (à définir dans l'alerte). Pour un contrat en reconduction tacite, la date de renouvellement correspond à la date de fin de contrat moins la date de préavis (pour un contrat se terminant le 31/12 avec un préavis de 3 mois, la date de fin se situe le 31/09). En savoir plus sur les cas spécifiques liés aux dates ici.

• Date de fin contrat proche : déclenché X jours/mois avant la date de fin de contrat du client. Peut également se déclencher après la date de fin si aucun nouveau contrat n'existe pour ce client (passer le paramètre de "avant date" à "après date). En savoir plus sur les cas spécifiques liés aux dates ici.

• Date de début du premier agreement du compte atteinte : déclenché lorsque la date de début du premier contrat (agreement) du compte est atteinte ou dépassée. En savoir plus sur les cas spécifiques liés aux dates ici.

  Use case : cibler les clients selon leur ancienneté

  Ce déclencheur est idéal pour orchestrer des actions en fonction de la date de début d'abonnement. Par exemple, les clients onboardés avant le lancement d'une nouvelle version de votre plateforme peuvent être ciblés par une série de messages spécifiques pour les aider à prendre en main les nouveautés, là où vos nouveaux clients auront suivi un parcours d'onboarding déjà adapté.

• Score CSM modifié : déclenché lorsqu'un CSM change son CSM Pulse sur un client.

• Propriétaire du compte modifié : déclenché lorsqu'un nouveau CSM propriétaire de compte est assigné.

• Devient client dormant (ghost) : déclenché lorsqu'un client devient dormant (aucune interaction ni connexion pendant une période définie, par défaut 30 jours). Paramètres modifiables dans Paramètres > Général (opens new window).

• Client dormant réactivé : déclenché lorsqu'un client se réactive (interaction récente ou connexion).

• Tags client ajoutés : déclenché lorsqu'un ou plusieurs tags choisis sont ajoutés à un client (tags système exclus). Si un client est créé avec des tags directement, le playbook se déclenche aussi, les tags sont considérés comme ajoutés juste après la création du client.

• MRR du compte modifié : déclenché lorsque le MRR d'un compte change (hausse, baisse, dépassement d'un seuil, variation en %). Attention, si le MRR est vide, la valeur est différente de 0, il faut choisir "la valeur existe" dans les branches d'un split & merge appliqué au MRR.

• Propriété nom_de_votre_champ_custom modifiée : déclenché lorsque le champ custom sélectionné prend la valeur que vous indiquez.

Conditions liées à une propriété contact

Les actions disponibles à la suite d'un trigger lié à une propriété contact sont différentes de celles disponibles à la suite d'un trigger lié à une propriété client.

• Activation manuelle avec un contact : déclenché uniquement manuellement ou via un autre Playbook, associé directement à un contact.
• Nouveau contact créé : déclenché à la création d’un contact.
• NPS contact modifié : déclenché lorsqu’un NPS est ajouté ou modifié.
• Tags contacts ajoutés : déclenché lorsqu’un ou plusieurs Tags custom sont ajoutés à un contact.
• Titre du poste modifié : déclenché au changement d'intitulé de poste (correspond à la "fonction" du contact)

Conditions liées au score de santé

• Score de santé passe dans le rouge : déclenchement si le score passe de ≥4 à ≤3 (code couleur rouge).
• Score de santé sort de la zone rouge : déclenchement si le score passe de ≤3 à ≥4 (jaune ou vert).
• Score de santé passe dans le vert : déclenchement si le score passe de ≤6 à ≥7 (vert).
• Score de santé sort de la zone verte : déclenchement si le score passe de ≥7 à ≤6 (jaune ou rouge).
• Score de santé modifié : déclenchement si le score change, conditions ajustables via critères avancés.

Conditions liées aux interactions

• Nouvelle interaction créée : déclenché lorsqu'une interaction correspondant aux critères choisis est créée (type (email, note, appel, RDV, ticket), direction entrante ou sortante, statut, tags).

• Date de l'interaction arrivée ou dépassée : déclenché X jours/semaines/mois après la date d'une interaction spécifiée (par exemple 2 semaines après le dernier meeting avec un statut Confirmé) En savoir plus sur les cas spécifiques liés aux dates ici.

• Tags interaction ajoutés : déclenché à l’ajout de tags spécifiés sur des interactions choisies.

• Titre de l'interaction modifié : déclenché lorsque le titre d'une interaction est modifié. Vous pouvez désormais préciser une condition sur le titre : égal à, correspond à, contient, commence par ou se termine par la chaîne de caractères que vous saisissez dans le champ associé.

  Use case : détecter automatiquement les QBR et sessions de formation

  Ce déclencheur est particulièrement utile pour identifier la réalisation de QBR ou de sessions de formation et y apposer automatiquement le tag correspondant sur l'interaction. C'est un atout majeur pour tous ceux qui utilisent les objectifs d'interaction : en taguant automatiquement les bonnes interactions, les objectifs se mettent à jour sans action manuelle.

• Pas de contact client : déclenché si aucun échange avec un contact d’un compte depuis X jours/semaines/mois (emails sans réponse non comptés).

• Pas d'interaction avec le contact : déclenché si aucun échange avec un contact donné depuis X jours/semaines/mois (remarque : les emails restés sans réponse ne sont pas comptabilisés comme un point de contact).

• Évolution de la moyenne du score de sentiment : déclenché selon l’évolution du score (hausse, baisse, dépassement d'un seuil, variation en %) sur une période définie.

Vous pouvez définir la période sans contact directement dans le trigger.

Astuce

Les filtres avancés vous donnent accès à des critères supplémentaires. Vous pouvez par exemple utiliser le déclencheur "Pas d'interaction avec le contact" en utilisant les Tags attachés au contact pour cibler spécifiquement vos "Champions", par exemple.

Lors de la mise en place d’un nouveau playbook d’interaction…

Il est important de savoir qu’un playbook qui se déclenche lorsqu’un utilisateur n’a eu aucune interaction au cours des 15 derniers jours ne se déclenchera pas le 16ᵉ ou le 17ᵉ jour sans interaction avec ce même client : il reste strictement basé sur le nombre de jours défini.

De la même manière, il ne se déclenchera pas automatiquement sur tous les clients avec lesquels vous n’avez pas eu d’interactions depuis plus de 15 jours. Ainsi, après son activation, vous pouvez vouloir l’appliquer manuellement à l’ensemble de ces clients : Lancer manuellement le playbook, en choisissant les conditions suivantes :
Dernier contact client + date relative + il y a plus de N jours + 15
ET en ajoutant également toutes les conditions initiales de votre playbook (par exemple : phase = run ET profil de score de santé = Tier 1, etc.).

Conditions liées aux usages

• Aucun usage client : déclenchement lorsqu’un client n’a jamais utilisé l’outil. Vous définissez le délai entre la création du client et le déclenchement de l'alerte.
• Aucun usage contact : déclenchement lorsqu’un contact n’a jamais utilisé l’outil, délai paramétrable.
• Aucun usage client depuis : déclenchement lorsqu’un client n’a plus utilisé l’outil depuis un certain délai, à définir dans les paramètres.
• Aucun usage contact depuis : déclenchement lorsqu’un contact n’a plus utilisé l’outil depuis un certain délai, à définir dans les paramètres.
• Nouvel usage client depuis : déclenchement lorsqu’un client réutilise l’outil après une période sans usage, période à définir dans les paramètres.
• Nouvel usage contact depuis : déclenchement lorsqu’un contact réutilise l’outil après une période sans usage, période à définir dans les paramètres.
• Premier usage client : déclenchement à la première utilisation par le client.
• Premier usage contact : déclenchement à la première utilisation par le contact.

Astuce

Les triggers liés à l’usage peuvent être filtrés sur une fonctionnalité spécifique. Dans l’exemple ci-dessous le trigger "No contact usage" s’applique uniquement aux fonctionnalités 1 et 2 (à copier depuis la liste de fonctionnalités visibles dans le rapport Adoption Produit) ce qui permet de déclencher un scénario spécifique pour les utilisateurs n’ayant pas pris en main l'une ou l'autre des fonctionnalités importantes de mon produit un mois après leur création.

Vous pouvez indiquer plusieurs fonctionnalités en appuyant sur Entrée entre chaque nom. Lorsque plusieurs fonctionnalités sont renseignées, un filtre OU s’applique : le Playbook se déclenche dès que l’une d’elles est concernée.

Lors de la mise en place d’un nouveau playbook d’usage…

Il est important de savoir qu’un playbook qui se déclenche lorsqu’un utilisateur n’a pas utilisé le produit au cours des 15 derniers jours ne se déclenchera pas le 16ᵉ ou le 17ᵉ jour sans usage du produit : il reste strictement basé sur le nombre de jours défini.

De la même manière, il ne se déclenchera pas automatiquement sur tous les clients qui n'ont pas utilisé le produit depuis plus de 15 jours. Ainsi, après son activation, vous pouvez vouloir l’appliquer manuellement à l’ensemble de ces clients : Lancer manuellement le playbook, en choisissant les conditions suivantes :
Dernier usage client + date relative + il y a plus de N jours + 15
ET en ajoutant également toutes les conditions initiales de votre playbook (par exemple : phase = run ET profil de score de santé = Tier 1, etc.).

Conditions liées aux opportunités

• Nouvelle opportunité créée : déclenchement à la création d’une opportunité dans un pipeline donné.
• Opportunité assignée à un utilisateur : déclenchement à l’assignation ou modification de l’assignation sur une opportunité d'un pipeline donné.
• Opportunité gagnée : déclenchement lors de la victoire d’une opportunité dans un pipeline donné.
• Opportunité perdue : déclenchement lors de la perte d’une opportunité dans un pipeline donné.
• Phase d'opportunité modifiée : déclenchement lors d’un changement de phase d'une opportunité dans un pipeline donné.
• Phase d'opportunité non modifiée : déclenchement si la phase d'une opportunité d'un pipeline donné n'a pas été modifiée depuis X jours/semaine/mois.
• Date limite de l'opportunité approche : déclenchement X heures/jours/semaines avant ou après la date de clôture d'une opportunité dans un pipeline donné. En savoir plus sur les cas spécifiques liés aux dates ici.

Playbooks programmés

Les playbooks programmés sont une alternative aux playbooks déclenchés sur un évènement lié au client ou au contact. Ils permettent de déclencher automatiquement un playbook à une date précise ou selon une récurrence régulière — chaque semaine, chaque mois, chaque trimestre ou chaque année — sur un jour spécifique du mois ou de la semaine. C'est une façon puissante de structurer des actions récurrentes sans dépendre d'un évènement déclencheur, idéale pour des rendez-vous réguliers comme les QBR, les enquêtes NPS ou les communications liées au calendrier produit.

Disponibilité et rétro-activité

Disponible sur tous les plans. Il est possible de modifier un playbook existant pour remplacer son déclencheur par un déclencheur programmé.

Un playbook programmé peut cibler un client ou un contact.

Cas d'usage

• Enquête NPS trimestrielle : envoyer automatiquement un email d'enquête NPS à chaque début de trimestre aux clients d'une catégorie donnée n'ayant jamais reçu cette enquête.
• QBR trimestriel : planifier une prise de contact pour un QBR tous les trimestres sur chacun des clients en phase run.
• Communication de mise à jour produit : si une nouvelle version de votre plateforme est prévue à une date donnée, vous pouvez communiquer à tous vos clients le jour même de la sortie grâce à un playbook programmé.

Configuration

Fuseau horaire

Commencez par choisir le fuseau horaire d'exécution. C'est particulièrement important si l'heure de déclenchement est critique (par exemple pour envoyer un email à 9h dans le fuseau de vos clients).

Fréquence

Choisissez ensuite la fréquence :

• Exécution unique : le playbook se déclenche une seule fois à une date précise.
• Quotidienne : choisissez simplement l'heure de déclenchement.
• Hebdomadaire : choisissez le jour de la semaine et l'heure.
• Mensuelle : choisissez parmi une liste prédéfinie de jours (1er, 5, 10, 15, 25 ou dernier jour du mois), et l'heure de déclenchement.
• Trimestrielle : déclenche par défaut le 1er du mois au début de chaque trimestre.
• Personnalisée : saisissez directement une expression CRON pour définir précisément le calendrier d'exécution.

Mode personnalisé (expression CRON)

Le mode personnalisé utilise une expression CRON au format minute heure jour mois jour-semaine. Chaque champ peut contenir une valeur spécifique, * (tous), ou des intervalles.

Champ	Valeurs
Minute	0–59
Heure	0–23
Jour du mois	1–31
Mois	1–12
Jour de la semaine	0–6 (0 = dimanche)

Exemples courants :

• 0 9 * * * → tous les jours à 9h00
• 0 9 * * 1 → tous les lundis à 9h00
• 0 9 1 * * → le 1er de chaque mois à 9h00
• 0 9 1 1 * → le 1er janvier de chaque année à 9h00
• 0 9 5 1,4,7,10 * → le 5 de janvier, avril, juillet et octobre à 9h00

Limites d'exécution

Sous la configuration de la récurrence, vous pouvez définir des limites d'exécution :

• Date de fin : la récurrence s'arrête à une date donnée.
• Nombre maximum d'exécutions : le playbook s'arrête après un nombre défini d'exécutions.

Limite de fréquence par client ou contact

Point de vigilance

Pour les playbooks programmés récurrents, posez-vous systématiquement la question : mon client risque-t-il d'être ciblé plusieurs fois par cette récurrence ? Et si oui, est-ce souhaité ?

Si ce n'est pas souhaité, activez la Limite de fréquence par client dans l'onglet Paramètres du playbook, et indiquez le nombre maximum d'activations autorisées par client sur la période choisie (une fois par semaine, par mois, par trimestre ou par année).

À ne pas confondre avec le nombre d'activations concurrentes (aucune, 1 seule par client ou 1 seule par contact), qui concerne uniquement le nombre d'exécutions du playbook en parallèle sur un même client. Un playbook qui se déroule rapidement peut tout à fait se déclencher à nouveau dès le lendemain sur ce même client sans jamais atteindre cette limite — c'est la limite de fréquence qui protège contre ce cas de figure.

Ce paramètre est accessible depuis l'onglet Paramètres du playbook.