Recettes d'automatisation : configurations courantes

Last updated: September 2, 2026

Configurations d'automatisation prêtes à l'emploi que vous pouvez copier, chacune avec le déclencheur à choisir, quand elle s'exécute, les conditions à ajouter, les actions suggérées et les pièges à éviter. Couvre le suivi des propositions (vue, acceptation, expiration), le rappel aux étudiants des dates de début et de fin de leur police d'assurance, et la réaction aux changements de stade du pipeline. C'est une page vivante — d'autres recettes sont ajoutées au fil du temps avec de nouveaux déclencheurs et conditions.

Cette page décrit des configurations d'automatisation courantes que vous pouvez créer dans Paramètres > Recrutement > Automatisations. Chaque recette suit la même structure — ce qu'elle accomplit, le déclencheur à choisir, quand elle s'exécute, les conditions à ajouter, les actions suggérées, et ce à quoi faire attention — afin que vous puissiez parcourir rapidement celle dont vous avez besoin et la construire en quelques minutes.

Plus de recettes seront ajoutées ici au fil du temps avec de nouveaux déclencheurs et conditions, considérez donc cela comme une bibliothèque en croissance plutôt qu'une liste fixe. Si vous créez quelque chose d'utile qui n'est pas encore ici, cela peut être ajouté en tant que nouvelle section.

Pour la liste complète de ce qui est disponible, voir la référence des déclencheurs, conditions et actions liée en bas.

Recette 1 — Suivi des propositions

Ce qu'elle accomplit : Maintient les propositions en mouvement sans relances manuelles. Vous incitez l'étudiant avant l'expiration de la proposition, faites un suivi lorsqu'il l'a consultée mais n'a pas agi, et transférez en interne au moment où il accepte.

Déclencheur à choisir : Une automatisation par comportement que vous souhaitez, tirée du groupe Propositions :

  • Proposition vue — la première fois que l'étudiant ouvre la proposition.
  • Proposition acceptée — lorsque l'étudiant l'accepte.
  • Date d'expiration de la proposition — un déclencheur basé sur la date que vous pouvez définir pour s'exécuter avant, le jour ou après l'expiration de la proposition.

Quand elle s'exécute :

  • Proposition vue se déclenche lors de la première ouverture de la proposition par l'étudiant et ne se reproduit pas lors de vues ultérieures.
  • Proposition acceptée se déclenche lors de la transition réelle vers acceptée.
  • Date d'expiration de la proposition s'exécute par rapport à la date d'expiration — pour un rappel, la définir quelques jours avant. Lors de la création d'un déclencheur basé sur une date, le générateur vous rappelle la règle en langage clair pour que vous puissiez confirmer que vous avez choisi le bon décalage et la bonne direction.

Conditions à ajouter : Limitez l'automatisation pour qu'elle ne se déclenche que pour les étudiants que vous ciblez — par exemple sur Nationalité de l'étudiant, ou sur des champs de proposition tels que la destination ou le type de programme. Vous pouvez utiliser le même champ plusieurs fois dans une règle si vous avez besoin de deux tests dessus, et la carte affiche un résumé de ce que vous avez construit (par exemple "3 conditions · n'importe"). Si vous souhaitez que tout corresponde, laissez le mode de correspondance sur tout ; utilisez n'importe quand une seule condition suffit.

Actions suggérées :

  • Avant l'expiration : envoyer un e-mail de rappel à l'étudiant avec un lien vers la proposition, et créer une tâche pour le conseiller responsable afin de l'appeler.
  • Lors de l'acceptation : envoyer un e-mail de félicitations, créer la tâche pour l'étape suivante (dépôt, documents), et notifier l'équipe via webhook ou notification interne.
  • Vu mais non accepté : associer une automatisation Proposal Viewed avec un e-mail de suivi après un certain délai, ou utiliser la relance par date d'expiration pour combler l'écart.

Attention à : Proposal Viewed ne se déclenche que lors du premier ouverture — un étudiant qui rouvre la proposition cinq fois génère toujours un seul événement, alors ne construisez pas de logique supposant des vues répétées. Proposal Accepted se déclenche une seule fois, lors de la transition — si l'étudiant accepte l'option A puis passe à l'option B, cela reste un seul événement, pas deux, donc une automatisation d'acceptation ne se déclenchera pas à nouveau lors du changement.

Recette 2 — Rappeler aux étudiants les dates de leur police d'assurance

Ce que cela permet : Les étudiants reçoivent un rappel avant le début de leur couverture d'assurance et avant sa fin, pour voyager avec une couverture active et savoir quand la renouveler. Cela donne également à votre équipe une incitation à vérifier les documents au bon moment.

Déclencheur à choisir : À partir de la nouvelle catégorie Assurance dans le sélecteur de déclencheurs :

  • Date de début de la police — pour les messages avant l'arrivée et "votre couverture commence bientôt".
  • Date de fin de la police — pour les rappels de renouvellement et d'expiration.

Quand il s'exécute : Les deux sont basés sur la date, vous choisissez donc avant, le jour même ou après la date pertinente — par exemple sept jours avant la date de début de la police, ou quatorze jours avant la date de fin. Le générateur reformule la règle en langage clair tel que vous l'avez définie, pour que vous puissiez vérifier que le décalage est correct avant de sauvegarder.

Conditions à ajouter : Utilisez Pays de destination de l'assurance pour envoyer des instructions spécifiques au pays, et Fournisseur d'assurance lorsque la formulation ou les documents diffèrent selon le fournisseur. Combinez-les lorsque vous avez besoin des deux, et utilisez le résumé de la condition sur la carte pour confirmer que la règle correspond à ce que vous avez décrit.

Actions suggérées :

  • Envoyer un e-mail à l'étudiant avec les détails de sa police et ce qu'il doit emporter.
  • Créer une tâche pour le conseiller afin de confirmer que l'étudiant a ses documents.
  • Pour les dates de fin, envoyer une relance pour le renouvellement et créer une tâche pour discuter de la prolongation de la couverture.

Attention à : Les déclencheurs d'assurance s'appliquent uniquement aux réservations confirmées. Les polices attachées à des réservations non encore confirmées ne déclencheront pas ces déclencheurs, donc un étudiant en attente ne recevra rien — ne considérez pas cette recette comme votre seul contrôle de couverture.

Recette 3 — Réagir aux changements d'étape du pipeline

Ce que cela permet : Transformer le mouvement du pipeline en actions automatiques — messages de bienvenue lorsqu'un étudiant entre dans une étape, tâches de transfert lorsqu'il progresse, et alertes internes lorsqu'il revient en arrière ou quitte une étape.

Déclencheur à choisir : Changement d'étape de pipeline.

Quand il s'exécute : Chaque fois qu'une étape de pipeline d'un étudiant change. Vous décidez alors quels changements vous intéressent en utilisant les conditions du déclencheur.

Conditions à ajouter : Utilisez "Passé à l'étape" pour agir lorsqu'un étudiant arrive à une étape spécifique, et "Passé de l'étape" pour agir lorsqu'il en quitte une. Combinez les deux pour capturer une transition spécifique (d'une étape à une autre), et superposez d'autres conditions — nationalité, destination, programme — pour limiter la règle aux bons étudiants.

Actions suggérées :

  • Passé à une nouvelle étape : envoyer l'email approprié à cette étape et créer la prochaine tâche pour le responsable.
  • Passé d'une étape active en arrière : notifier le responsable, ou créer une tâche de revue.
  • Tout changement d'étape : déclencher un webhook pour que votre reporting ou CRM reste synchronisé.

Attention : Les réaffectations en masse ne le déclenchent pas. Si les étapes sont modifiées en masse, aucune automatisation ne s'exécute, donc une grande opération de nettoyage ou de migration restera silencieuse dans les logs. Planifiez tout déplacement d'étape en supposant que les emails et tâches de suivi ne seront pas créés, et gérez-les manuellement.

Lié