Un Claude Skill qui transforme le contexte du deal — l’opportunité closed-won, le SOW, les notes de l’appel de discovery — en un plan d’onboarding basé sur des milestones avec des owners nommés, des dates cibles ancrées au début du contrat et un objectif de time-to-value (TTV) explicite. L’output est un plan Markdown structuré plus un CSV de milestones qui se mappe proprement sur l’import de projets de Rocketlane, de sorte que le CSM passe de « le deal vient de se conclure, sans plan » à un draft prêt pour le kickoff en quelques minutes au lieu de fixer un template vide. Le bundle de l’artifact comprend le SKILL.md plus trois fichiers de référence que l’équipe d’onboarding adapte une fois et réutilise sur chaque nouveau compte.

Quand l’utiliser

Vous êtes un CSM ou un onboarding manager qui vient d’hériter d’un compte fraîchement conclu et qui a besoin d’un plan à apporter à l’appel de kickoff. Le contexte du deal existe — il y a un SOW signé ou un order form, l’AE a laissé des notes de handoff, peut-être un transcript de l’appel de discovery — mais personne ne l’a transformé en un plan séquencé avec owners et dates. Ce Skill effectue cette conversion. Il est conçu pour le cas courant où l’onboarding est templatisé par segment (un motion standard 30/60/90 pour le SMB, un rollout en phases plus long pour l’enterprise) et où le travail consiste à adapter le template au scope, aux intégrations et aux stakeholders spécifiques de ce compte.

Il produit l’output le plus utile quand le SOW nomme des livrables concrets, que la date de début du contrat est connue et que vous pouvez lui indiquer quel template d’onboarding (segment, édition du produit, type de déploiement) s’applique. Donnez-lui ces trois éléments et il renvoie un plan que vous éditez au lieu de le rédiger. C’est un Skill de niveau beginner à dessein : aucun câblage d’API n’est requis pour obtenir le premier plan — vous collez le contexte du deal dans Claude et vous récupérez le plan et le CSV. L’import vers Rocketlane est le dernier kilomètre optionnel qui place les milestones dans votre PSA sans ressaisie manuelle.

Quand NE PAS l’utiliser

Ne l’utilisez pas pour créer automatiquement des projets Rocketlane sans passage humain. Le Skill écrit un plan draft ; le CSM possède l’engagement. Les dates cibles que le Skill calcule à partir du début du contrat sont des points de départ, pas des promesses au client — un CSM qui pousse le CSV directement dans Rocketlane et dans un portail client sans révision livrera des dates que l’équipe de delivery n’a jamais acceptées.

Ne l’utilisez pas pour des comptes où il n’y a ni SOW ni liste de livrables scopée — un plan généré à partir d’un order form d’une ligne est un template générique avec le nom du compte collé dessus, et vous feriez mieux de partir directement du template. Le Skill le signale : si le contexte du deal contient moins de trois livrables concrets, il renvoie un avis SCOPE_TOO_THIN et le template nu plutôt que d’inventer des milestones qui se lisent comme plausibles et engagent votre équipe sur du travail que personne n’a scopé.

Ne l’utilisez pas pour la planification de renewal ou d’expansion — celles-ci sont pilotées par l’usage et la progression du success plan, pas par un SOW frais, et la logique de milestones ici suppose une implémentation greenfield. Pour la health continue et l’expansion, les artifacts pertinents sont les workflows de customer health score et de détection de signaux d’expansion, pas celui-ci.

Ne l’utilisez pas comme substitut à la conversation de kickoff. Le plan est l’input du kickoff, où le client confirme owners, dates et séquence. Un plan qui saute cette confirmation est un plan que le client n’a jamais accepté.

Setup

Environ 30 à 45 minutes la première fois, presque entièrement consacrées à adapter les trois fichiers de référence au motion d’onboarding de votre équipe. Ensuite, chaque nouveau plan se résume à coller-et-exécuter.

Installez le Skill. Déposez le bundle de apps/web/public/artifacts/onboarding-plan-generator-skill/ dans ~/.claude/skills/onboarding-plan-generator/. Le SKILL.md définit un comportement d’entrée — étant donné le contexte du deal et un nom de template, produire un plan — plus les helpers de parsing et de calcul de dates. Aucun identifiant n’est requis pour le flux principal.
Adaptez les templates de milestones. Ouvrez references/1-onboarding-templates.md et remplacez les templates d’exemple par les vôtres. Fournissez-en au moins deux : un motion SMB court et un motion enterprise en phases. Chaque template est une liste de phases, les milestones dans chaque phase, le role d’owner par défaut par milestone (CSM, onboarding-manager, customer-champion, solutions-engineer) et l’offset en jours depuis le début du contrat. Les offsets sont ce que le Skill transforme en dates cibles ; réglez-les bien une fois et chaque plan en hérite.
Définissez le roster d’owners. Ouvrez references/2-owner-roster.md et mappez les roles d’owner à la façon dont votre équipe les nomme, plus la règle pour résoudre l’owner côté client (généralement « l’economic buyer nommé dans le SOW » ou « le sponsor du projet issu des notes de handoff »). Le Skill attribue un role d’owner à chaque milestone ; ce fichier est la manière dont un role devient une personne nommée.
Réglez la définition du TTV. Ouvrez references/3-ttv-definition.md et indiquez, par template, ce que « time to value » signifie pour votre produit — le milestone spécifique dont l’achèvement constitue la première valeur (première intégration en ligne, premier rapport livré, première équipe entièrement provisionnée). Le Skill marque ce milestone dans le plan et calcule la date cible de TTV pour que le kickoff ait un chiffre, pas une impression.
Exécutez pour un compte. Collez le contexte du deal — texte ou résumé du SOW, date de début du contrat, notes de handoff de l’AE et nom du template — dans Claude avec le Skill actif. Il renvoie le plan Markdown plus onboarding-plan.csv. Pour l’import optionnel vers Rocketlane, dans Rocketlane ouvrez le projet, choisissez Import et mappez les colonnes du CSV (milestone, phase, owner_role, target_date, is_ttv_milestone) aux champs de tâches de Rocketlane ; les noms de colonnes du fichier de référence correspondent déjà au schema d’import de Rocketlane.

Ce que le Skill fait réellement

Le Skill s’exécute en deux passes parce que l’extraction du scope et la construction du plan sont des travaux différents et que les fusionner produit des plans qui hallucinent des livrables. La passe un est l’extraction : Claude lit le contexte du deal et en extrait les livrables concrets, les stakeholders nommés et leurs roles, la date de début du contrat et toute date ou contrainte explicite à laquelle le SOW s’engage déjà (une date de go-live, un milestone contractuel assorti d’une pénalité). Il écrit cela dans un scratchpad interne et compte les livrables. Si le compte est inférieur à trois, il s’arrête ici et renvoie SCOPE_TOO_THIN plus le template nu — le garde-fou contre la transformation d’un order form maigre en un plan qui paraît assuré mais inventé.

La passe deux est la construction. Claude prend le template choisi dans references/1-onboarding-templates.md, superpose les livrables extraits sur les phases du template, attribue à chaque milestone un role d’owner depuis references/2-owner-roster.md et calcule les dates cibles en ajoutant l’offset en jours de chaque milestone au début du contrat. Là où le SOW s’est engagé sur une date explicite, cette date écrase l’offset calculé et le Skill signale le milestone comme fixé contractuellement pour que le CSM ne le déplace pas à la légère. Le milestone de TTV de references/3-ttv-definition.md est marqué, et sa date cible est remontée en haut du plan comme le chiffre phare du kickoff.

Séparer l’extraction de la construction importe pour la même raison que le Skill QBR sépare la synthèse du mapping de slots : une seule passe surpondère l’input qu’elle a lu en dernier et produit des plans où les dates dérivent du scope. Deux passes gardent l’extraction du scope honnête et le calcul des dates déterministe.

L’output est un plan Markdown groupé par phase avec un tableau de milestones (milestone, role d’owner, date cible, flag TTV, origine — template vs engagé-au-SOW) plus un résumé TTV d’une ligne, et un onboarding-plan.csv jumeau mis en forme pour l’import Rocketlane. Le CSM édite toujours avant le kickoff. Le Skill est un moteur de draft, pas un créateur de projets.

Réalité des coûts

Un seul plan coûte environ 6 000 à 15 000 tokens d’input (la majeure partie étant le SOW et les notes de handoff) et 2 000 à 4 000 tokens d’output sur Claude Sonnet — disons 3 à 6 centimes par plan aux prix actuels de Sonnet. Un long SOW enterprise avec un transcript de discovery complet atterrit en haut de fourchette ; un order form SMB serré avec un paragraphe de notes atterrit bien en dessous. Le temps réel est inférieur à une minute ; il n’y a pas d’appels API externes dans le flux principal, donc aucun plafond de rate-limit à contourner par conception.

Un CSM construisant un plan d’onboarding à partir de zéro — lire le SOW, mapper les livrables sur un template, attribuer les owners, calculer les dates — passe généralement 30 à 60 minutes par compte. Le Skill ramène cela à 5 à 15 minutes (la passe d’édition plus la préparation du kickoff). Pour un onboarding manager qui lance 8 à 12 nouveaux comptes par mois, c’est de l’ordre de 6 à 10 heures par mois récupérées, et plus important encore, les plans sont cohérents d’un CSM à l’autre plutôt que le template idiosyncrasique de chacun.

À quoi ressemble le succès

Suivez deux chiffres. Premièrement, le temps entre « deal closed-won » et « plan de kickoff prêt » — le Skill devrait ramener la médiane sous un jour ouvré dès le premier mois d’usage ; les équipes qui laissaient auparavant cela glisser de trois à cinq jours sont celles qui voient la plus grande amélioration du TTV, parce que l’onboarding démarre plus tôt. Deuxièmement, la proportion de milestones générés qui survivent à la passe d’édition du CSM — visez 70 % ou plus. En dessous, les templates de references/1-onboarding-templates.md ne correspondent pas à la façon dont l’équipe fait réellement l’onboarding, et le correctif est le template, pas le Skill. Au-dessus de 90 %, le CSM sous-édite probablement et n’adapte pas le plan au compte.

Un indicateur avancé à surveiller est le taux de SCOPE_TOO_THIN. Si une grande part des deals conclus le déclenche, le problème upstream est que les ventes font le handoff de comptes sans SOW scopés — le Skill remonte un défaut d’hygiène de deal-desk, il n’échoue pas.

vs alternatives

vs Rocketlane Nitro. La couche agentique propre à Rocketlane, Nitro, construit des plans de projet à partir des SOW et des appels de discovery au sein de Rocketlane. Si vous êtes déjà client de Rocketlane et que vous y vivez entièrement, Nitro est la voie de moindre friction — aucun Skill à installer et le plan atterrit nativement en tant que projet. Le compromis est que la logique de plan de Nitro est celle de Rocketlane, pas la vôtre : la règle de résolution d’owner, la définition du TTV et les offsets de template sont les fichiers de référence de ce Skill, que vous contrôlez et versionnez. Utilisez Nitro si vous voulez zéro setup et acceptez ses défauts ; utilisez ce Skill quand vous voulez que la logique de template soit la vôtre et réutilisable, ou quand tout onboarding ne vit pas dans Rocketlane. Les deux ne sont pas mutuellement exclusifs — générez avec le Skill, importez le CSV et laissez Rocketlane gérer l’exécution et le portail client.

vs un template statique. La plupart des équipes commencent ici — un Google Doc ou un template Rocketlane qu’elles copient par compte et éditent à la main. Le template est gratuit et prévisible, mais chaque copie est une transcription manuelle du SOW dans le template, et c’est précisément le travail de 30 à 60 minutes que le Skill supprime. Le template est le bon choix pour la long tail d’onboardings SMB identiques où le SOW n’ajoute rien que le template ne suppose déjà ; le Skill gagne sa place sur les comptes à variation de scope réelle, où mapper le SOW à la main est là où passe le temps.

vs un script custom. Un script maison qui parse le SOW et écrit le CSV est plausible si vos SOW sont rigidement structurés, mais la plupart des SOW sont en prose, et parser la prose de façon fiable est la partie que les scripts ratent. Le Skill gère la prose ; le script ne gère rien que le Skill ne fasse. Ne recourez à un script que si vos SOW sont générés par un système structuré de deal-desk et arrivent en champs propres — auquel cas vous n’avez pas du tout besoin de la passe d’extraction.

Points de vigilance

Milestones inventés à partir d’un scope maigre. Un order form vague tente le modèle de gonfler le plan avec des milestones qui sonnent plausibles que personne n’a scopés. Garde-fou : la passe d’extraction compte les livrables concrets et renvoie SCOPE_TOO_THIN avec le template nu quand il y en a moins de trois, plutôt que de construire un plan qui engage l’équipe sur du travail inventé.
Dates présentées comme des promesses. Les dates cibles sont début-du-contrat plus un offset de template — un défaut de planification, pas un engagement de delivery. Garde-fou : l’en-tête du plan indique que les dates sont draft et pré-kickoff, chaque date engagée-au-SOW est signalée comme fixée contractuellement et séparée visuellement des dates calculées, et le Skill n’écrit jamais de dates dans un portail client — c’est une étape humaine délibérée après que le kickoff les a confirmées.
Mauvais template choisi silencieusement. Exécuter le template SMB sur un compte enterprise produit un plan trop court et sous-staffé. Garde-fou : le nom du template est un input requis — le Skill ne le devine pas — et l’en-tête du plan répète le template choisi et son segment pour qu’un mismatch soit visible en haut avant que quiconque lise les milestones.
Roles d’owner laissés non résolus. Un plan avec des roles d’owner mais sans personnes nommées n’est pas actionnable. Garde-fou : le Skill attribue un role à chaque milestone et applique la règle de résolution côté client de references/2-owner-roster.md ; tout milestone dont l’owner ne peut être résolu depuis le contexte du deal est signalé OWNER_TBD plutôt que laissé vide, de sorte que le CSM voit exactement quoi remplir avant le kickoff.
Offsets périmés après un changement de motion. Quand l’équipe change son motion d’onboarding, les plans continuent d’hériter des anciens offsets en jours jusqu’à ce que le fichier de référence soit mis à jour. Garde-fou : le fichier de template porte sa propre date last_reviewed, et l’en-tête du plan la remonte ; un offset réglé il y a plus de 6 mois est une invitation à re-confirmer le motion avant de faire confiance aux dates.

Stack

Claude — génération de plan en deux passes : extraction du scope, puis construction du plan avec calcul de dates (Sonnet recommandé ; le travail n’a pas besoin d’Opus)
Rocketlane — destination optionnelle de dernier kilomètre ; le CSV se mappe sur l’import de projets de Rocketlane pour que les milestones atterrissent sans ressaisie, et Rocketlane gère l’exécution et le portail client
Les trois fichiers de référence — 1-onboarding-templates.md (phases, milestones, roles d’owner, offsets en jours), 2-owner-roster.md (role-vers-personne et résolution côté client), 3-ttv-definition.md (milestone de première valeur par template)

Modifier cette page sur GitHub