Les conditions de déclenchement des Playbooks

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

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.

Définition de la période sans contact

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.

Exemple filtre avancé

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.

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.).

Les déclencheurs suivants surveillent les variations de volume d'usage plutôt que l'absence d'usage.

Pas sûr du paramétrage à choisir ? Un assistant de configuration est disponible en bas de cette section.

Ce qui compte comme un événement

Pour les déclencheurs de baisse, hausse et variation d'usage, ce sont les événements qui sont comptabilisés. Une visite compte comme un événement standard : c'est donc la somme du nombre de visites et du nombre de fonctionnalités utilisées qui est comparée d'une période à l'autre.

Baisse d'usage client : le playbook se déclenche lorsque l'usage d'un client baisse d'au moins un seuil de variation défini, mesuré sur une fenêtre de comparaison glissante. Par exemple, avec une fenêtre d'un mois, Skalin compare la somme des événements des 30 derniers jours à celle des 30 jours précédents ; si la baisse atteint le seuil choisi (par ex. 20 %), le playbook se déclenche. Les seuils proposés sont 10, 20, 30 et 50 %, mais toute valeur jusqu'à 200 % est sélectionnable.
Hausse d'usage client : fonctionne exactement comme la baisse d'usage, mais se déclenche lorsque l'usage de la dernière période dépasse celui de la période précédente d'au moins le seuil défini.
Baisse d'usage contact / Hausse d'usage contact : équivalents des deux déclencheurs ci-dessus, appliqués au niveau du contact. Particulièrement indiqué lorsque seul l'usage de certains utilisateurs est déterminant.

Fenêtre glissante et calibrage du seuil

La fenêtre de comparaison est toujours glissante : elle compare la dernière période à la période immédiatement précédente, de même durée. Il n'existe aucun seuil d'événement minimal. Ainsi, si un client ne compte que deux utilisateurs actifs à parts égales et que l'un part deux semaines en congés, une fenêtre de comparaison de 2 semaines déclenchera le playbook sur une baisse d'au moins 50 %.

Calibrez donc le seuil et la fenêtre en fonction de votre nombre moyen d'utilisateurs par compte.

Pour ces déclencheurs, l'aperçu de la détection est surtout indicatif : en pratique, seuls comptent le point actuel et celui de la période précédente.

Calcul nocturne et périodes glissantes

Les déclencheurs de baisse, hausse et variation d'usage sont recalculés chaque nuit, toujours sur des périodes glissantes : la dernière période analysée se termine la veille, et non en fin de semaine calendaire.

C'est pourquoi les valeurs d'un déclencheur ne se retrouvent pas telles quelles dans le rapport Adoption Produit, qui affiche l'usage semaine calendaire par semaine calendaire. Les deux mesurent la même chose, mais pas sur le même découpage : une fenêtre glissante de 2 semaines arrêtée un mercredi ne coïncide pas avec les deux dernières semaines du lundi au dimanche du graphe.

Filtrage par fonctionnalité

Les déclencheurs liés à l'usage peuvent être filtrés sur une fonctionnalité spécifique — aussi bien les déclencheurs d'absence d'usage que ceux de baisse, hausse et variation d'usage (au niveau client comme contact). Indiquez le nom de la fonctionnalité dans l'encart prévu à cet effet (à copier depuis la liste de fonctionnalités visibles dans le rapport Adoption Produit). Vous pouvez renseigner plusieurs fonctionnalités en appuyant sur Entrée entre chaque nom ; un filtre OU s'applique alors, le playbook se déclenchant dès que l'une d'elles est concernée.

Seuls les déclencheurs liés aux utilisateurs actifs hebdomadaires et mensuels ne peuvent pas être filtrés par fonctionnalité.

Cas d'usage : cibler les fonctionnalités clés. Si vous suivez en priorité les fonctionnalités qui portent la valeur et doivent être utilisées régulièrement, filtrez sur ces fonctionnalités clés plutôt que sur celles de paramétrage. En début de vie du compte, l'administrateur configure la plateforme, ce qui gonfle l'usage : inclure ce setup dans la normale ferait passer le retour à un usage courant pour une baisse. Pour la même raison, pensez à restreindre le playbook aux clients en phase run grâce aux filtres avancés, afin de ne pas le déclencher pendant l'onboarding.

Filtre sur fonctionnalité

Baisse des utilisateurs actifs hebdomadaires : le playbook se déclenche lorsque le nombre d'utilisateurs actifs hebdomadaires (indicateur Weekly Active Users) baisse d'au moins un seuil défini (10, 20, 30, 50 % ou une valeur personnalisée).
Hausse des utilisateurs actifs hebdomadaires : équivalent, à la hausse.
Baisse des utilisateurs actifs mensuels / Hausse des utilisateurs actifs mensuels : mêmes principes appliqués à l'indicateur Monthly Active Users.

Le déclencheur suivant fonctionne différemment : au lieu de comparer la dernière période à la seule période précédente, il compare l'usage récent à une période de référence plus longue pour repérer les écarts statistiquement anormaux.

Baisse en pourcentage ou variation d'usage : lequel choisir ?

La baisse d'usage applique un seuil fixe : simple et prévisible, elle convient quand vous avez une attente claire et un usage plutôt stable. Mais une règle unique montre vite ses limites :

Clients de tailles différentes : avec un seuil à 30 %, un client d'un ou deux utilisateurs déclenche dès qu'une personne part en congés, tandis qu'un client de trente utilisateurs ne déclenche presque jamais. Le même pourcentage n'a pas le même sens selon la taille du compte.
Érosion lente : la baisse d'usage ne compare que deux périodes consécutives. Une perte de quelques pour cent par semaine ne franchit jamais le seuil d'un coup, mais peut diviser l'usage par deux en quelques mois sans jamais déclencher.
Usage irrégulier : un client qui utilise la plateforme par à-coups déclenche à chaque creux normal, ce qui multiplie les fausses alertes.

Dans ces cas, préférez la variation d'usage : elle apprend la normale propre à chaque client et s'adapte automatiquement à sa taille, à son rythme et à sa régularité. Un seul déclencheur couvre alors tout votre portefeuille, sans multiplier les scénarios.

Variation d'usage client : détecte les écarts d'usage anormaux par rapport à la normale du client. Les options se règlent dans cet ordre :
1. Direction : Les deux (pics à la hausse comme à la baisse), Hausse ou Effondrement.
2. Mode de détection et sensibilité : Sensible, Recommandé ou Strict ; le mode positionne le seuil en σ, que le curseur de sensibilité permet d'ajuster finement (voir encart).
3. Fenêtre de comparaison : la durée de la période analysée (jour, semaine(s) ou mois).
4. Référence : le nombre de périodes précédentes servant de base de comparaison. Exemple : une fenêtre d'un mois avec 6 périodes de référence compare le dernier mois aux 6 mois précédents ; une fenêtre de 2 semaines avec 10 périodes le compare aux 20 semaines précédentes.
5. Écart minimum : le nombre minimal d'événements d'écart requis pour déclencher (voir encart).
Variation d'usage contact : équivalent du déclencheur ci-dessus, appliqué au niveau du contact.

Écart minimum et aperçu de la détection

L'écart minimum est un filtre absolu, exprimé en nombre d'événements : la dernière fenêtre doit s'écarter de la normale d'au moins ce nombre d'événements pour déclencher. Utile lorsqu'un client a très peu d'usage, où le moindre événement suffirait sinon à déclencher le playbook. La valeur 0 désactive ce filtre (détection purement statistique).

Dans l'aperçu de la détection, chaque point représente une période (une ou plusieurs semaines, ou un ou plusieurs mois selon votre choix) et le nombre total de points correspond à la période de référence.

Comprendre la normale et les écarts-types

Skalin calcule d'abord une normale : la moyenne de l'usage sur la période de référence (par exemple les 6 derniers mois). L'écart-type — noté σ (sigma) — mesure la dispersion habituelle autour de cette moyenne, c'est-à-dire l'ampleur des variations considérées comme « normales » d'une période à l'autre.

Le déclencheur réagit lorsque l'usage de la dernière fenêtre s'éloigne de la normale de plus d'un certain nombre d'écarts-types :

Sensible : à partir de 1,5 σ — réagit dès les écarts modérés (plus d'alertes, davantage de faux positifs).
Recommandé : à partir de 2 σ — détecte les anomalies nettes.
Strict : à partir de 2,5–3 σ — uniquement les anomalies prononcées.

Plus le seuil en σ est élevé, plus l'écart à la normale doit être important pour être jugé anormal.

Prenons un client dont l'usage sur les 6 périodes de référence tourne autour de 40 événements : 40, 42, 38, 41, 39, 40. Sa normale (moyenne) est de 40 et son écart-type d'environ 1,3 : d'une période à l'autre, l'usage s'écarte habituellement d'un peu plus d'un événement. En mode Recommandé (2 σ), il faudrait que la dernière période sorte de la fourchette d'environ 37 à 43 pour déclencher ; en mode Sensible (1,5 σ), cette fourchette se resserre autour de 38 à 42.

La régularité de l'usage joue donc un rôle central :

Un usage très régulier donne un écart-type petit : la moindre variation paraît anormale et déclenche rapidement. C'est utile pour repérer tôt un changement, mais cela peut multiplier les faux positifs — d'où l'intérêt de l'écart minimum en nombre d'événements.
Un usage erratique donne un écart-type grand : il faut une variation importante pour déclencher, ce qui évite de réagir au moindre soubresaut.

Rupture ou saisonnalité : bien choisir la période de référence

Une période de référence longue donne une normale stable, mais seulement si le passé ressemble encore au présent. Avant de l'allonger, demandez-vous si la période contient une rupture, c'est-à-dire un changement durable de niveau ou de rythme.

En cas de rupture (par exemple un client devenu plus régulier mais à un niveau plus bas), une référence qui remonte avant la rupture mélange deux normales. Elle gonfle l'écart-type et rend le déclencheur aveugle aux vrais décrochages du nouveau régime. Calez alors la référence sur le régime actuel uniquement.
En cas de saisonnalité (un motif qui se répète chaque année), une référence d'environ 52 semaines est au contraire pertinente : un creux saisonnier ne sera pas confondu avec une anomalie.

En résumé, une référence longue n'est un atout que si le passé lointain reste représentatif. Sinon, préférez une référence plus courte, ancrée sur le rythme actuel du client.

Assistant de configuration. Répondez à quelques questions pour obtenir un paramétrage de départ à tester, à ajuster ensuite selon vos résultats.

# 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.

La création d'un Playbook

Les filtres liés au déclenchement des Playbooks