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é. Les décisions structurantes ont été prises au call du 28 juillet : GHL devient le home base, Virtuagym devient le miroir. La construction est lancée.
GHL devient le home base — le parcours post-closing sans abandon
Décision formelle d'Éric au call du 28 juillet : « On va faire la transition vers GoHighLevel et that's it. » L'adjointe prébook TOUS les rendez-vous dès le jour 1 — dans GHL. L'automatisation ne fait pas booker : elle confirme, rappelle, offre une porte de sortie pour déplacer, et escalade vers un humain en cas de silence. L'acquisition reste 100 % côté GS.
GHL = source de vérité
Tous les bookings et toutes les automatisations vivent dans GHL. Virtuagym devient le miroir : le client continue de voir ses RDV dans son app, et Virtuagym garde programmes, nutrition, tracking et facturation. Transitoire : l'adjointe rebooke manuellement dans Virtuagym. Cible : push automatique par API.
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.
3 parcours actifs — comptes corrigés au call
Strip & rebuild confirmé par Éric (« Si vous avez besoin de scrapper, on scrappe, puis that's it ») : le pipeline Leads du snapshot GS devient le pipeline 1 (acquisition), les anciens Acquisition et Opérations sont scrappés, et les pipelines opération sont repeuplés depuis l'Excel de l'équipe. MPN360 Mouvement est discontinué (~1 client) — son workflow legacy sera archivé.
Parcours 1 · P1 — urgent
Performance — cycle 4 semaines
3 évaluations + 3 remises sur 3 mois, tout prébooké dès le jour 1 (à 4 semaines forcées si le client n'a pas de dates). Bascule critique : la discussion finale de décision.
Parcours 2 · P1 — urgent
Autonome — cycle 6 semaines
Mécanique identique, rythme 6 semaines : 2 évaluations + 2 remises sur 3 mois, puis la discussion finale. Deux clones de workflows (plus maintenable dans GHL).
Fin de parcours · P2 — le plus payant
La discussion finale
Deux options, jamais « j'arrête » : Option 1 = je continue (on book l'évaluation, facturation) · Option 2 = discussion avec Éric. Courriels DEC signés « Éric ». Reco : prébooker systématiquement 1 h de discussion qui devient l'évaluation si le client continue — à trancher vendredi.
Parcours 3 · P2 — périmètre élargi au call
Membership — annuel
Nouveau calendrier GHL dédié au mini-onboarding 30 min (profil + code d'accès + explications app), séquence « Bienvenue dans la famille » déclenchée au booking, contacts mois 3/6/9, bilan mois 11. Objectif : réduire le délai actuel de 24-48 h entre l'inscription et le code.
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 adjointe à J-2 (Dorianne primary, Yoakim secondary). RDV final → appel obligatoire à J-1. Décision fin de cycle → séquence J-10/J-6/J-3 + appel J-1.
GHL source de vérité, Virtuagym en miroir — et un seul sens de sync
Le recalcul dynamique exigé par Éric (« si un RDV est déplacé, tout se recalcule ») reste le point techniquement critique. Avec GHL comme home base, l'ancrage sur les appointments le résout — et le pont vers Virtuagym se fait en one-way, jamais en sync bidirectionnelle.
Ancrage sur les appointments GHL
- Contrainte GHL
- Un contact ne peut vivre qu'une fois dans un workflow (Matt) → 7 calendriers typés / 7 workflows indépendants. Alternative proposée par Matt : 6 custom fields de dates dont l'update déclenche les workflows — mais recalcul manuel et double vérité. Reco : les calendriers.
- Pourquoi
- Recalcul automatique au reschedule, zéro champ de date à maintenir, et l'appointment GHL est exactement l'objet que l'API poussera vers Virtuagym.
- Piège connu
- Éric a déjà eu des envois en rafale à cause des blocs Wait (Time Delay vs Wait until Date/Time). Test bout en bout avec contact fictif obligatoire avant toute activation.
Pont Virtuagym — one-way + détecteur de dérive
- Flux principal
- GHL → Virtuagym : RDV créé/déplacé/annulé dans GHL → l'API Virtuagym crée/met à jour l'événement (le client le voit dans son app). API v1 : auth api_key + club_secret (portail Éric), 500 req/h, connecteur Make.com disponible. À confirmer dans la doc : les endpoints d'écriture sur les Events.
- Sens inverse
- Pas de webhooks Virtuagym → pas de sync retour. Un poller léger compare les deux systèmes et, en cas d'écart, crée une tâche adjointe — l'humain arbitre, jamais la machine. À vérifier : le client peut-il modifier ses bookings lui-même dans l'app (si on peut désactiver ce self-service, le problème disparaît).
- Transitoire
- Tant que l'API n'est pas validée : l'adjointe booke dans GHL puis rebooke manuellement dans Virtuagym. Les automatisations tournent à 100 % — le miroir est cosmétique.
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 (7)
- Évaluation 360 · Remise de programme · Discussion finale de parcours · Onboarding adjointe (sem. 0) · Mini-onboarding membership 30 min · Bilan annuel membership · Continuité Éric (Option 2).
- Pourquoi
- Nécessaire pour brancher les workflows par type de RDV sans merge tag de statut (branch par nom de trigger), et pour contourner la contrainte « un contact par workflow ». 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 GHL + miroir Virtuagym. + Play-by-play post-achat (« arrive avec tes runnings »). Courriels ACC-PERF-01 / ACC-AUTO-01 (+EN).
WF-02 · P1 — à prototyper en premier
Rappel RDV standard
Confirmation immédiate au booking/reschedule + J-7 / J-5 / J-3 + tâche adjointe à J-2 si silence (Dorianne → Yoakim). Branche « champion ». 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 Option 1 / Option 2, J-6, J-3, tâche appel J-1. Courriels DEC-01 à 03 (+EN), signés « Éric ». Lien renouvellement self-serve Virtuagym à configurer côté Éric — fallback : « réponds à ce courriel » → tâche adjointe.
WF-05 · P2 — périmètre élargi au call
Membership
« Bienvenue dans la famille » déclenché au booking du 30 min + remise du code d'accès + relances (J+3/6/10) + contacts mois 3/6/9 + bilan annuel (J-14/7/3). Vidéo tutoriel de l'app à filmer par Éric. 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 points à trancher au checkpoint de vendredi
Les grandes questions du call sont réglées (GHL home base, comptes des cycles, strip & rebuild, email-first). Reste ceci — avec les recommandations déjà posées.
7 calendriers vs 6 custom fields de dates
Reco : les calendriers — recalcul automatique au reschedule, et l'appointment est l'objet que l'API poussera vers Virtuagym. Les champs = double vérité et mise à jour manuelle.
Mécanique de la discussion finale
Courriel Option 1/Option 2 seul, ou booking systématique d'1 h de discussion qui devient l'évaluation si le client continue. Éric est à l'aise avec les deux.
FR/EN : tags de langue ou courriels bilingues ?
Reco : les tags — la banque est déjà écrite en 20 FR + 20 EN séparés, et un courriel bilingue double la longueur (mauvais en texte brut).
Verdict API Virtuagym
Doc en route (Matt → api@virtuagym.com). GO : pont automatique GHL → Virtuagym. NO-GO : double booking manuel assumé par l'adjointe.
Réponse du support GHL sur le KYC
Si le compte peut basculer vers le système KYC → SMS débloqués rapidement. Sinon : demande A2P complète, 1-2 semaines (dev de Matt).
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.
Call de validation Martin × Matt × Éric (28 juillet)
GHL home base acté, comptes des cycles corrigés, strip & rebuild confirmé, email-first, périmètre membership élargi, Excel de l'équipe livré.
Phase 1 — Fondations
Trancher calendriers vs champs → créer les 7 calendriers, tags, désactivation des notifs built-in. Revue desync du snapshot, restructuration des pipelines (Leads GS = pipeline 1), audit + import de l'Excel.
Phase 2 — Prototype WF-02 (pattern maître)
Test booking, test reschedule, test des blocs Wait, contact fictif bout en bout. Rien d'autre ne se construit tant que ce prototype n'est pas validé. Démo à Éric.
Phase 3 — WF-01 + WF-03, Performance puis clone Autonome
Les parcours urgents d'Éric, avec les comptes corrigés (3+3 / 2+2 + discussion finale).
Phase 4 — WF-04 décision + WF-05 membership
La discussion finale (mécanique tranchée vendredi) et le nouveau périmètre membership (code d'accès, bienvenue au booking).
Phase 5 — WF-06 silence, WF-07 offboarding, dashboard, QA
Checklist QA GS complète, dashboard (clients actifs par parcours, RDV à venir, tâches d'escalade ouvertes). Courriel d'offboarding rédigé par MPN360 d'ici là.
En parallèle — pont API Virtuagym · déblocage SMS · formation adjointe
Spike API dès réception de la doc (one-way GHL → Virtuagym + détecteur de dérive). KYC/A2P selon la réponse du support. Adjointe formée au double booking transitoire.
Checkpoint — vendredi 31 juillet
Update complet à Éric : snapshot, desync, A2P, API, et les 5 points à trancher.