Dans Migma, commencez par définir l'action attendue pour chaque e-mail d'onboarding. Définissez ensuite, avec le responsable du workflow, une règle tout aussi claire pour déterminer à quel moment cette relance devient inutile. Même avec un design soigné, inciter un utilisateur à terminer sa configuration alors qu'il l'a finalisée la veille reste une erreur d'expérience.
Ce guide publié par Migma détaille la gestion des règles de sortie pour les équipes utilisant Loops. Plutôt qu'un énième calendrier d'envois à jours fixes, il propose une grille de relecture et des scénarios de test concrets. La documentation officielle a été vérifiée le 15 octobre 2026. Migma prend en charge la revue créative présentée ici ; les responsables produit et emailing doivent quant à eux implémenter et valider l'état des contacts ainsi que le comportement du workflow.
Définir la complétion à partir d'un événement produit vérifiable
Résumez en une phrase l'action visée par la relance. Pour une application de gestion de projet, par exemple, l'étape clé consiste souvent à publier un premier projet contenant au moins une tâche. Une simple connexion ou l'ouverture de l'e-mail de bienvenue ne garantit en rien cette issue.
Identifiez ensuite la source de cette information. Un événement produit, une propriété de contact stockée et l'ouverture d'un message constituent des signaux distincts. Le Product Owner doit préciser comment la plateforme d'envoi reçoit cet état et comment s'assurer de sa réception. Un brouillon incitant à « finaliser votre projet » ne doit pas reposer sur une simple supposition quant à l'existence de ce projet.
Le guide des exemples d'onboarding de Loops recommande de synchroniser la complétion dans une propriété de contact et de vérifier cette valeur avant d'envoyer les e-mails de configuration suivants. Appuyez-vous sur les jalons réels de votre produit au lieu de reprendre une propriété d'exemple sans consensus d'équipe sur sa signification.
Structurer le brief créatif avec une condition de sortie
Dans Migma, préparez le texte validé, les éléments de marque et l'action attendue pour chaque message. Associez-y une grille de suivi à destination du responsable du workflow. Placez cette fiche à côté des maquettes : les relecteurs pourront ainsi relier chaque message à la condition exacte qui justifie son envoi.
| Objectif du message | État utilisateur justifiant l'envoi | Condition d'arrêt ou de modification |
|---|---|---|
| Inciter à créer un premier projet | Le jalon convenu n'est pas encore atteint | La complétion est enregistrée |
| Expliquer une intégration non finalisée | L'intégration manque et l'utilisateur dispose des droits nécessaires | L'intégration fonctionne ou l'utilisateur n'a pas le rôle requis |
| Proposer de l'aide à la configuration | L'utilisateur est toujours éligible et reste bloqué | La configuration est terminée, les permissions changent ou la séquence prend fin |
| Présenter une étape suivante utile | Le premier jalon est validé | L'étape suivante est déjà réalisée ou non pertinente |
Ces règles servent d'illustration pour notre exemple d'application ; il ne s'agit ni de métriques observées ni d'une configuration Loops prête à l'emploi. Validez-les avec les responsables des données produit avant d'activer votre workflow.
Vérifier la portée de chaque filtre d'audience
La documentation Loops sur le branching distingue « All following nodes » de « Next node only ». Avec la première option, un contact qui ne remplit plus le critère plus tard est exclu du workflow. Avec la seconde, la condition est évaluée uniquement lorsque le contact atteint le nœud suivant, et les modifications ultérieures ne l'excluent pas sur ce fondement.
Cette portée est déterminante lorsqu'un utilisateur termine sa configuration pendant une période d'attente. Un filtre appliqué une seule fois au début ne garantit en rien la pertinence des relances ultérieures. Demandez au responsable du workflow d'indiquer précisément où la condition de complétion s'applique et ce qu'il advient d'un contact déjà en attente en aval.
Vérifiez également la version de la branche concernée. Loops documente un passage de l'évaluation parallèle historique au modèle « first-match » pour les nouvelles branches, les anciennes conservant leur logique tant qu'elles ne sont pas explicitement migrées. Ne préjugez pas du comportement d'un workflow existant à partir d'une simple capture de la documentation actuelle.
Distinguer le rôle de l'utilisateur de l'état de complétion
Un collaborateur invité peut être très actif sans disposer des droits pour connecter une source de données d'entreprise. De même, l'administrateur de l'espace de travail a pu finaliser cette connexion pendant qu'un membre de l'équipe attendait une relance. Le brief doit préciser si la complétion est rattachée à l'individu, au compte ou au workspace.
Cette distinction doit se refléter dans le contenu. « Connectez la source de données de votre équipe » est une consigne logique pour un administrateur, mais déroutante pour un simple contributeur. Si l'équipe ne dispose pas de données fiables sur les rôles, prévoyez un parcours neutre et demandez au responsable technique de gérer délibérément les états indéterminés.
D'après la documentation sur les branches, les filtres récents sont évalués de gauche à droite selon la règle de la première correspondance (first-match). Un filtre positionné tout à droite, sans condition spécifique, peut faire office de branche par défaut. Concevez ce chemin comme un choix éditorial à part entière : une absence de données ne doit pas se transformer en relance infondée affirmant que la configuration est incomplète.
Tester le changement d'état pendant les délais d'attente
Élaborez un cahier de recette simple avec des profils fictifs. Confiez son exécution au responsable des tests dans un environnement dédié. Ne modifiez jamais les propriétés d'un client réel pour une simple capture d'écran.
Prévoyez cinq cas types : un profil qui ne termine pas la configuration ; un qui valide le jalon avant la première relance ; un troisième qui finalise l'action pendant le délai d'attente entre deux messages ; un quatrième avec des données d'état manquantes ; et un cinquième représentant un collaborateur n'ayant pas les droits pour réaliser l'action demandée.
Pour chaque scénario, consignez le message attendu (ou la sortie), le résultat constaté dans le workflow et la version créative associée. Si une relance part malgré la complétion, vérifiez la mise à jour des données et la portée du filtre avant de réécrire l'objet ou le titre : aucun copywriting ne corrigera un mauvais ciblage d'audience.
Aligner l'e-mail final avec la maquette validée
Dans Migma, vérifiez que le message met en avant la bonne action et explique clairement l'étape restante. Utilisez Email Preflight pour inspecter la création. Gardez un format concis afin que la demande et les options d'assistance restent immédiatement visibles.
Si un transfert HTML est pertinent, utilisez les options d'export de Migma pour que l'intégrateur adapte le template dans la plateforme cible. Cela n'implique pas l'existence d'un connecteur d'export natif entre Migma et Loops. Contrôlez l'URL finale des boutons d'action selon le rôle et l'état du contact : un lien peut être fonctionnel sur le plan technique tout en dirigeant l'utilisateur vers un écran auquel il n'a pas accès.
Distinguez clairement la validation créative de la recette du workflow. La maquette Migma atteste de ce qui a été validé par l'équipe ; l'e-mail de test reçu et les logs du workflow démontrent le comportement effectif du parcours configuré.
Interrompre la relance et engager la prochaine étape utile
La complétion doit mettre fin aux relances devenues obsolètes. Pour autant, elle n'exige pas l'envoi immédiat d'un autre e-mail. Déterminez si l'utilisateur a besoin d'une confirmation, de conseils ultérieurs pour franchir une étape suivante, ou tout simplement de temps pour explorer le produit en toute autonomie.
Dans notre exemple, un projet finalisé peut déclencher plus tard un conseil sur la collaboration en équipe, tandis qu'un utilisateur bloqué recevra une proposition d'aide ciblée. Ces messages répondent à des besoins distincts et exigent des briefs spécifiques. Ne vous contentez pas de renommer une relance d'onboarding pour continuer à l'envoyer.
Concevez vos e-mails dans Migma en rendant la règle de sortie visible dès la relecture. Demandez ensuite au responsable du workflow de prouver que les relances s'interrompent pour la bonne raison. Une séquence d'onboarding efficace respecte les avancées de l'utilisateur avec autant de soin qu'elle sollicite son attention.
Foire aux questions
L'ouverture d'un e-mail constitue-t-elle une bonne règle de complétion pour l'onboarding ?
Non. Une ouverture ne prouve aucunement que le jalon produit est atteint. Définissez une action produit précise et vérifiez la transmission de son état à la plateforme d'envoi.
Que se passe-t-il si un utilisateur s'active pendant un délai d'attente ?
L'objectif est d'interrompre les relances devenues obsolètes. Le responsable du workflow doit vérifier l'état actuel du contact et la portée des filtres d'audience pour un contact déjà en attente.
Toutes les branches Loops enregistrées fonctionnent-elles selon la même logique d'évaluation ?
Non. La documentation actuelle distingue les nouvelles branches en « first-match » des anciennes branches, qui conservent une évaluation parallèle jusqu'à leur mise à niveau explicite. Examinez le workflow configuré avant de présumer de sa logique.
Ce workflow nécessite-t-il un connecteur natif entre Migma et Loops ?
Non. Préparez et validez les créations dans Migma, puis adaptez l'export ou les maquettes dans l'outil d'envoi. Le responsable de l'intégration vérifie ensuite le template final et le comportement du workflow.