Conditions de déclenchement

Les alertes liées à une propriété client

# Les alertes liées à une propriété client

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.

# Alertes liées aux clients

Nouveau client créé : l'alerte se déclenche à la création d'un nouveau client.
Phase du cycle de vie (stage) modifiée : l'alerte se déclenche lorsqu'un client change de phase de cycle de vie (stage).
Phase du cycle de vie non modifiée : l'alerte se déclenche lorsqu'un client n'a pas changé de phase de cycle de vie depuis une durée à définir.
Profil modifié : l'alerte se déclenche lorsqu'un client change de profil de score de santé (Healthscore profile).
Date de renouvellement proche : l'alerte se déclenche 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).
Date de fin contrat proche : l'alerte se déclenche 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).
Date de début du premier agreement du compte atteinte : l'alerte se déclenche lorsque la date de début du premier contrat (agreement) du compte est atteinte ou dépassée.

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é : l'alerte se déclenche lorsqu'un CSM change son CSM Pulse sur un client.
Propriétaire du compte modifié : l'alerte se déclenche lorsqu'un nouveau CSM propriétaire de compte est assigné.
Devient client dormant (ghost) : l'alerte se déclenche 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é : l'alerte se déclenche lorsqu'un client se réactive (interaction récente ou connexion).
Tags client ajoutés : l'alerte se déclenche lorsqu'un ou plusieurs tags choisis sont ajoutés à un client (tags système exclus). Si un client est créé avec des tags directement, l'alerte 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é : l'alerte se déclenche 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 alors utiliser la condition "la valeur existe" dans vos filtres.
Propriété nom_de_votre_champ_custom modifiée : l'alerte se déclenche lorsque le champ custom sélectionné prend la valeur que vous indiquez.

# Alertes liées à une propriété contact

Nouveau contact créé : l'alerte se déclenche à la création d'un nouveau contact.
NPS contact modifié : l'alerte se déclenche lorsque le NPS donné par un contact est ajouté pour la première fois ou modifié.
Tags contact ajoutés : l'alerte se déclenche lorsqu'un ou plusieurs tags sont ajoutés à un contact (tags custom uniquement).
Titre du poste modifié : l'alerte se déclenche au changement d'intitulé de poste d'un contact (correspond à la "fonction" du contact).

# Alertes liées au score de santé d'un client

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.

# Alertes liées aux interactions

Nouvelle interaction créée : déclenchement 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éclenchement X jours/semaines/mois après la date d'une interaction spécifiée.
Tags interaction ajoutés : déclenchement à l’ajout de tags spécifiés sur des interactions choisies.
Titre de l’interaction modifié : déclenchement lorsque le titre d’une interaction est modifié. Vous pouvez 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éclenchement 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éclenchement 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éclenchement 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 déclencheur.

Définition de la période sans contact

Conseil : les filtres avancés permettent de filtrer des critères supplémentaires. Vous pouvez par exemple filtrer 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 filtres avancés

Lors de la configuration d'une nouvelle alerte d'interaction…

Il est important de savoir qu'une alerte 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 : elle reste strictement basée sur le nombre de jours défini.

De la même manière, elle ne se déclenchera pas automatiquement sur tous les clients avec lesquels vous n'avez pas eu d'interactions depuis plus de 15 jours. Pensez à appliquer manuellement l'alerte à ces clients lors de son activation, en filtrant par exemple sur Dernier contact client + date relative + il y a plus de N jours.

# Alertes 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 configuration d’une nouvelle alerte d’usage…

Il est important de savoir qu’une alerte 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 : elle reste strictement basée sur le nombre de jours défini.

Si vous souhaitez avoir un message pour vous signaler tous les clients qui n'ont pas utilisé le produit depuis plus de 15 jours au moment où vous lancez l'alerte, vous pouvez passer par les playbooks et créer le même déclencheur mais cette fois l'appliquer manuellement, en filtrant par exemple sur Dernier usage client + date relative + il y a plus de N jours.

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 : l'alerte 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 %), l'alerte 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 une alerte de baisse d'au moins 50 %.

Calibrez donc le seuil et la fenêtre en fonction de votre nombre moyen d'utilisateurs par compte et de la fréquence d'usage de votre solution : un outil utilisé quotidiennement n'appelle pas la même fenêtre qu'un outil utilisé une fois toutes les deux semaines.

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, l'alerte 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 déclencheur aux clients en phase run grâce aux filtres avancés, afin de ne pas le déclencher pendant l'onboarding.

Exemple filtrage usage

Baisse des utilisateurs actifs hebdomadaires : l'alerte 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 l'alerte. 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.

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

# Alertes liées aux tâches

Nouvelle tâche créée : déclenchement à la création d’une tâche.
Tâche assignée à un utilisateur : déclenchement à l’assignation ou modification de l'assignation.
Tâche terminée : déclenchement à la complétion d’une tâche.
Date limite de la tâche approche : déclenchement à l’approche de la date d’échéance, délai paramétrable (à noter : lorsque vous créez une tâche, vous décidez si elle est éligible ou non à ces rappels).

# Alertes liées aux projets de tâches

Nouveau groupe de tâches créé : déclenchement à la création d’un nouveau projet.
Groupe de tâches terminé : déclenchement à la complétion d’un projet.
Date limite du projet approche : déclenchement à l’approche de la deadline du projet (la deadline de la tâche la plus éloignée dans le temps).

# Alertes liées aux Playbooks

Activation Playbook nécessite une action (étape manuelle) : déclenchement lorsqu’une action manuelle est nécessaire pour poursuivre l’exécution du Playbook : splits manuels, étapes de validation manuelle et mails à vérifier avant envoi.

La création d'une alerte

Choix des destinataires et du canal