Concept
Un playbook est le contrat d’exécution d’une motion commerciale. Il ne stocke pas seulement des templates de copie. Dans le code actuel, il gouverne le ciblage, la qualification, le premier contact, les relances, la gestion des objections, l’escalade, la logique de démo et le suivi des meetings.
icpDefinitionDéfinition de ciblage utilisée pendant le matching déterministe du playbook et la qualification par LeadFinder.qualificationRulesRègles de go / no-go appliquées après enrichissement et scoring.scoringRulesPoids et heuristiques qui orientent les décisions de scoring.messageStrategyLignes directrices de rédaction réutilisées par Personalization et Sequence.followUpCadenceHoursIndices de cadence utilisés quand un scheduling historique est créé.stepsListe historique ordonnée des steps pour les playbooks non-flow.flowFlow de playbook basé graphe; c’est aujourd’hui le chemin runtime le plus solide.objectionHandlingRulesRéponses d’objection approuvées utilisées par ReplyAgent.demoMappingGuidage de sélection de démo utilisé lors des flows autour des démos.bookingStrategyGuidage de prise de rendez-vous utilisé par Sequence et Closer.escalationRulesRègles qui disent à Reply / Closer quand escalader vers un humain.localePréférence de langue pouvant influencer la rédaction.Le playbook influence à la fois la sélection et l’exécution. Le point essentiel dans le code actuel est que le premier message outbound est envoyé par `personalization`, tandis que les lignes durables de séquence sont créées ensuite par `SequenceStarter`.
EventConsumer + lead_finderLe worker peut d’abord matcher un playbook de manière déterministe, puis LeadFinder enrichit, score, et peut émettre `lead.scored`.
personalizationEnvoie le premier message outbound et émet `sequence.started` ainsi que `message.sent`.
SequenceStarterCrée les lignes `sequences` et `sequence_steps`. Cet événement est hors de la table de routage du Supervisor.
sequenceExécute les relances à échéance en utilisant le contexte du playbook, du Product Brain, l’historique outbound et les signaux d’engagement.
sequencePasse par le même chemin SequenceAgent pour le nurturing post-démo ou post-engagement.
replyUtilise les règles d’objection et d’escalade du playbook une fois le message inbound rattaché à la bonne conversation / au bon lead.
demo / closerLes playbooks continuent de cadrer le suivi de démo, la préparation de meeting, le reschedule et les mises à jour d’opportunité.
| Action | Acteur | Comportement actuel |
|---|---|---|
| Playbook matching | EventConsumer + PlaybookMatcher | Rematch déterministe sur `lead.created`, `lead.scored` et `nurture.triggered` à partir du snapshot lead le plus récent. |
| Qualification | LeadFinder | Enrichit le lead, applique la logique de qualification, et n’émet `lead.scored` que si le lead reste qualifié. |
| Premier contact | Personalization | Rédige et envoie directement le premier email au lieu d’attendre un step de séquence. |
| Persistance de séquence | SequenceStarter | Crée des lignes de séquence durables après le premier contact; les flows graphe et les steps historiques ordonnés sont tous deux supportés. |
| Dispatch des steps à échéance | SequenceScheduler | Sonde les steps en attente, hydrate le contexte outbound précédent et les signaux d’engagement, puis émet `sequence.step_due`. |
| Exécution des relances | Sequence | Utilise la stratégie de message du playbook, le Product Brain, la connaissance workspace et la continuité d’expéditeur pour les relances. |
| Traitement inbound | Reply | Utilise les règles d’objection et d’escalade du playbook, et annule ou met en pause les séquences selon l’intent inbound. |
Le Supervisor est un routeur d’événements statique, pas un planner dynamique.
`sequence.started` appartient aux workers et n’est jamais routé vers un agent d’exécution.
Les playbooks flow sont le modèle privilégié. Les steps historiques ordonnés fonctionnent encore, mais le mode graphe est le chemin runtime le plus fort.
La chaîne de qualification effective est `lead.created -> lead_finder -> lead.scored -> personalization`.
Le contexte de playbook hydraté n’expose pas aujourd’hui certaines mutations optionnelles de séquence comme l’adaptive abandonment ou la channel mutation; il ne faut donc pas les sur-promettre dans la doc.
Pour comprendre comment le contexte acheteur est injecté dans ces playbooks, lire Personas. Pour le graphe d’événements, l’ordre de routage inbound et le pilotage des séquences, lire Runtime et Inbound.