Plan de match MPN360
Le parcours client post-closing d'Éric, automatisé dans GHL : des rappels ancrés sur les rendez-vous prébookés, avec escalade humaine garantie — jamais un client oublié. Rien n'est encore implémenté : ce plan est la base du call Martin × Matt.
Rappeler, pas booker : le parcours post-closing sans abandon
Éric a livré un cahier de charges complet qui renverse notre lecture initiale. L'acquisition reste 100 % côté GS — on automatise tout ce qui suit le closing. Dorianne prébook TOUS les rendez-vous dès le jour 1 : l'automatisation ne fait pas booker, elle rappelle, offre une porte de sortie pour déplacer, et escalade vers un humain en cas de silence.
Tout est prébooké
Dorianne prébook chaque RDV dès le jour 1 (même jour, même heure, au rythme du cycle). On n'écrit jamais « book ton rendez-vous » — les courriels rappellent le RDV existant et offrent de le déplacer.
Règle de non-abandon
Aucune séquence ne finit en silence : chaque relance sans réponse aboutit à une tâche ou un appel humain (Dorianne). L'automatisation prépare l'humain, elle ne le remplace pas.
Gate de contenu levé
Les 40 courriels (20 FR + 20 EN) sont livrés par MPN360, avec identifiants uniques mappés aux workflows. Tutoiement confirmé par écrit, texte brut, un seul CTA. Plus rien ne bloque côté copy.
4 paliers, 2 pipelines
Les 4 paliers du cahier de charges se mappent sur les 2 pipelines décidés au call de config (MPN 360 + Opération Membership). Le rythme — 4 vs 6 semaines — vit dans les tags et les champs, pas dans des pipelines séparés. Priorité d'implantation dictée par Éric.
Palier 1 · P1 — urgent
Performance — cycle 4 semaines
Évaluation + remise aux 4 semaines, 3 cycles, tout prébooké. Bascule critique : le RDV final de package à la semaine 16.
Palier 2 · P1 — urgent
Autonome — cycle 6 semaines
Mécanique identique à Performance, seul le rythme change (6 semaines, pas 4). RDV final à la semaine 18. Un workflow paramétré ou deux clones — à trancher avec Matt.
Palier 4 · P2 — le plus payant
Fin de cycle 3 mois
Courriel de décision à deux options : continuer, ou rencontrer Éric. Jamais d'option « j'arrête ». Les 3 courriels DEC sont signés « Éric » — rare, pour garder son poids.
Palier 3 · P3 — phase 2
Membership — annuel
Appel d'accueil 30 min, contacts aux mois 3/6/9, bilan au mois 11, renouvellement au mois 12. Se construit en dernier.
Le pattern maître de relance — construit une fois, réutilisé partout
Le cœur du système : avant chaque RDV prébooké, une séquence de rappels qui s'arrête dès que le client réagit — et qui finit toujours par un humain s'il ne réagit pas.
Rappel 1
Courriel avec date, heure et type du RDV en champs dynamiques, phrase de sortie pour déplacer, un seul bouton d'action.
Rappel 2
Deuxième passage, même structure. La séquence s'arrête immédiatement sur toute action du client.
Rappel 3
Dernier courriel — ton urgent si c'est le RDV final de package.
Escalade humaine
Silence total → tâche Dorianne à J-2. RDV final de package → appel obligatoire à J-1. Décision fin de cycle → séquence J-10/J-6/J-3 + appel J-1.
Ancrer les séquences sur les appointments, pas sur des calculs de dates
Le recalcul dynamique exigé par Éric (« si un RDV est déplacé, tout se recalcule ») est le point techniquement critique — GHL n'a pas de math de dates native sur les opportunités. L'approche proposée contourne complètement le problème.
Ancrage sur les appointments
- Pourquoi
- Ça évite tout calcul de dates dans GHL et c'est exactement le pattern GS « automations plutôt que notifications built-in ». Zéro champ de date à maintenir à la main.
- À valider
- Comportement re-entry du workflow sur reschedule · désactivation des notifs built-in des calendriers · et surtout : le booking se fait-il dans GHL ou dans Virtuagym ? (question à retourner à Éric — bloquant pour toute l'approche).
- Piège connu
- Éric lui-même a déjà eu des envois en rafale dans ses workflows GHL existants à cause des blocs Wait (Time Delay vs Wait until Date/Time). Test bout en bout avec contact test obligatoire avant toute mise en prod.
Tags & custom fields
- Tags
- client-performance · client-autonome · client-membership · langue-fr / langue-en · cycle-actif / cycle-fin-approche / cycle-termine · inactif (offboarding, posé manuellement). Lowercase sans accents, posés par les workflows.
- Custom fields
- Folder MPN Parcours : date_debut_package, date_derniere_remise, date_prochain_rdv, type_prochain_rdv, numero_cycle, rdv_final_flag, derniere_interaction_client.
- Nuance
- Si l'ancrage appointment fonctionne, plusieurs de ces champs deviennent optionnels — le RDV porte sa propre date. À trancher à la construction : ne pas créer de champs orphelins.
Calendriers — un par type de RDV
- Liste
- Évaluation · remise · RDV final · appel d'accueil membership · bilan annuel · continuité Éric.
- Pourquoi
- Nécessaire pour brancher les workflows par type de RDV sans merge tag de statut (branch par nom de trigger). Notifs built-in désactivées partout — ce sont les workflows qui parlent au client.
7 workflows, nomenclature d'Éric
Chaque workflow sortant : Stop on Response ON, fenêtre 7h–20h, branche FR/EN sur tag de langue. Attention : les merge tags de la banque de courriels sont des pseudo-tags ({{date_prochain_rdv}}, {{lien_renouvellement}}...) — chacun doit être mappé vers le vrai merge tag GHL à la construction, jamais deviné.
WF-01 · P1
Accueil nouveau client
Courriel « voici ton parcours + tes dates », pose des tags, owner Dorianne, tâche de prébooking. Courriels ACC-PERF-01 / ACC-AUTO-01 (+EN).
WF-02 · P1 — à prototyper en premier
Rappel RDV standard
J-7 / J-5 / J-3 + tâche Dorianne à J-2 si silence. Ancré sur l'appointment, réutilisé à chaque cycle. C'est le pattern maître : tout le reste en découle. Courriels STD-01 à 03 (+EN).
WF-03 · P1
Rappel RDV final de package
J-7 / J-5 / J-3 ton urgent + appel obligatoire Dorianne à J-1. Courriels FIN-01 à 03 (+EN).
WF-04 · P2 — le plus payant
Décision fin de cycle
J-10 courriel deux options / J-6 / J-3 / tâche appel J-1. Courriels DEC-01 à 03 (+EN), signés « Éric ». Dépend de la réponse sur {{lien_renouvellement}} (facturation Virtuagym).
WF-05 · P3
Membership
Bienvenue + relances appel d'accueil (J+3/6/10) + contacts mois 3/6/9 + bilan annuel (J-14/7/3) + tâche à l'échéance. Courriels MEM-* (+EN).
WF-06 · P3
Détecteur de silence
Aucune interaction depuis X jours (3 mois sans ouverture pour membership) → tâche de vérification. Interne, pas de courriel client.
WF-07 · P2
Offboarding
Tag inactif → retrait des tags actifs, courriel de sortie, opportunité fermée. Seul courriel absent de la banque — à faire rédiger par MPN360.
5 questions à trancher avec Matt
Dans l'ordre d'impact — la première conditionne toute la construction.
Ancrage appointment vs champs de dates calculés
Valider l'approche de la section Architecture avant de construire quoi que ce soit. C'est la décision structurante du projet.
Le snapshot GS chevauche-t-il WF-02/03 ?
Si le snapshot contient des workflows de reminders RDV, il faut arbitrer — jamais deux workflows sur le même trigger.
Un workflow paramétré ou deux clones pour 4 vs 6 semaines ?
Recommandation : deux clones, plus maintenable dans GHL. À confirmer.
Qui construit quoi, et quand ?
Répartition Martin / Matt, et est-ce qu'on attend l'import du snapshot avant de commencer les fondations ?
{{lien_renouvellement}} — existe-t-il ?
L'option A du courriel de décision promet un « renouvellement en un clic », mais la facturation est dans Virtuagym. Sinon : fallback page GHL ou réponse au courriel.
Ce qui est prêt, ce qui reste
Cahier de charges + banque de 40 courriels livrés
Cahier « MPN360 Parcours Client Automatisations » v1.0 + 20 courriels FR / 20 EN avec identifiants mappés aux workflows. Le gate de contenu est levé.
Call de configuration GS × Éric
Pipelines (MPN 360 + Opération Membership), tags = segmentation, owner dynamique Dorianne ↔ Éric, Location ID et domaine Mailgun fournis.
Phase 0 — Call Martin × Matt + réponses d'Éric
Trancher les 5 questions ci-dessus, et obtenir surtout la réponse booking GHL vs Virtuagym.
Phase 1 — Fondations
Tags, calendriers, désactivation des notifs built-in, custom fields minimaux. Dépend de l'import du snapshot.
Phase 2 — Prototype WF-02 (pattern maître)
Test reschedule, test des blocs Wait, contact test bout en bout. Rien d'autre ne se construit tant que ce prototype n'est pas validé.
Phase 3 — WF-01 + WF-03, Performance puis clone Autonome
Les paliers urgents d'Éric.
Phase 4 — WF-04 décision fin de cycle
Le plus payant selon Éric.
Phase 5 — WF-05 membership, WF-06 silence, WF-07 offboarding
Le courriel d'offboarding doit être rédigé par MPN360 d'ici là.
Phase 6 — QA + dashboard + démo à Éric
Checklist QA GS complète, dashboard simple (clients actifs par palier, RDV à venir, tâches d'escalade ouvertes), démo finale.