Una Claude Skill que convierte el contexto del deal —la oportunidad closed-won, el SOW, las notas de la llamada de discovery— en un plan de onboarding basado en milestones con owners nombrados, fechas objetivo ancladas al inicio del contrato y una meta explícita de time-to-value (TTV). El output es un plan en Markdown estructurado más un CSV de milestones que se mapea limpiamente al import de proyectos de Rocketlane, así que el CSM pasa de “el deal acaba de cerrar, sin plan” a un borrador listo para el kickoff en minutos en vez de mirar una plantilla en blanco. El bundle del artifact incluye el SKILL.md más tres archivos de referencia que el equipo de onboarding adapta una vez y reusa en cada cuenta nueva.

Cuándo usarla

Eres un CSM u onboarding manager que acaba de heredar una cuenta recién cerrada y necesitas un plan para llevar a la llamada de kickoff. El contexto del deal existe —hay un SOW firmado o una order form, el AE dejó notas de handoff, tal vez una transcripción de la llamada de discovery— pero nadie lo ha convertido en un plan secuenciado con owners y fechas. Esta Skill hace esa conversión. Está construida para el caso común donde el onboarding está plantillado por segmento (un motion estándar de 30/60/90 para SMB, un rollout por fases más largo para enterprise) y el trabajo es adaptar la plantilla al scope, las integraciones y los stakeholders específicos de esta cuenta.

Produce el output más útil cuando el SOW nombra entregables concretos, la fecha de inicio del contrato se conoce y puedes decirle qué plantilla de onboarding (segmento, edición del producto, tipo de despliegue) aplica. Dale esos tres y devuelve un plan que editas en vez de redactar. Es una Skill de nivel beginner a propósito: no se requiere wiring de API para obtener el primer plan —pegas el contexto del deal en Claude y recibes de vuelta el plan y el CSV. El import a Rocketlane es la última milla opcional que mete los milestones en tu PSA sin re-tipeo manual.

Cuándo NO usarla

No la uses para auto-crear proyectos de Rocketlane sin una pasada humana. La Skill escribe un plan borrador; el CSM posee el compromiso. Las fechas objetivo que la Skill computa desde el inicio del contrato son puntos de partida, no promesas al cliente —un CSM que empuja el CSV directo a Rocketlane y a un portal de cara al cliente sin revisión enviará fechas que el equipo de delivery nunca acordó.

No la uses para cuentas donde no hay SOW ni lista de entregables con scope —un plan generado a partir de una order form de una línea es una plantilla genérica con el nombre de la cuenta pegado, y estarías mejor arrancando desde la plantilla directamente. La Skill marca esto: si el contexto del deal contiene menos de tres entregables concretos, devuelve un aviso SCOPE_TOO_THIN y la plantilla pelada en vez de inventar milestones que se leen plausibles y comprometen a tu equipo a trabajo que nadie puso en scope.

No la uses para planeación de renewal o expansión —esas se manejan por uso y progreso del success plan, no por un SOW fresco, y la lógica de milestones aquí asume una implementación greenfield. Para health continuo y expansión los artifacts relevantes son los workflows de customer health score y de detección de señales de expansión, no este.

No la uses como sustituto de la conversación de kickoff. El plan es el input al kickoff, donde el cliente confirma owners, fechas y secuencia. Un plan que se salta esa confirmación es un plan que el cliente nunca acordó.

Setup

Aproximadamente 30 a 45 minutos la primera vez, casi todo gastado adaptando los tres archivos de referencia al motion de onboarding de tu equipo. Después de eso, cada plan nuevo es pegar-y-correr.

Instala la Skill. Coloca el bundle de apps/web/public/artifacts/onboarding-plan-generator-skill/ en ~/.claude/skills/onboarding-plan-generator/. El SKILL.md define un comportamiento de entrada —dado el contexto del deal y un nombre de plantilla, produce un plan— más los helpers de parseo y de cálculo de fechas. No se requieren credenciales para el flujo principal.
Adapta las plantillas de milestones. Abre references/1-onboarding-templates.md y reemplaza las plantillas de muestra con las reales. Incluye al menos dos: un motion corto de SMB y un motion enterprise por fases. Cada plantilla es una lista de fases, los milestones dentro de cada fase, el rol de owner por default por milestone (CSM, onboarding-manager, customer-champion, solutions-engineer) y el offset en días desde el inicio del contrato. Los offsets son lo que la Skill convierte en fechas objetivo; hazlos bien una vez y cada plan los hereda.
Define el roster de owners. Abre references/2-owner-roster.md y mapea los roles de owner a cómo tu equipo los nombra, más la regla para resolver el owner del lado del cliente (usualmente “el economic buyer nombrado en el SOW” o “el sponsor del proyecto de las notas de handoff”). La Skill asigna un rol de owner a cada milestone; este archivo es cómo un rol se vuelve una persona nombrada.
Configura la definición de TTV. Abre references/3-ttv-definition.md y declara, por plantilla, qué significa “time to value” para tu producto —el milestone específico cuya finalización es el primer valor (primera integración en vivo, primer reporte enviado, primer equipo totalmente provisionado). La Skill marca ese milestone en el plan y computa la fecha objetivo de TTV para que el kickoff tenga un número, no una sensación.
Corre para una cuenta. Pega el contexto del deal —texto o resumen del SOW, fecha de inicio del contrato, notas de handoff del AE y el nombre de la plantilla— en Claude con la Skill activa. Devuelve el plan en Markdown más onboarding-plan.csv. Para el import opcional a Rocketlane, en Rocketlane abre el proyecto, elige Import y mapea las columnas del CSV (milestone, phase, owner_role, target_date, is_ttv_milestone) a los campos de tareas de Rocketlane; los nombres de columnas en el archivo de referencia ya coinciden con el schema de import de Rocketlane.

Qué hace la Skill en realidad

La Skill corre en dos pasadas porque la extracción de scope y la construcción del plan son trabajos distintos y combinarlos produce planes que alucinan entregables. La pasada uno es extracción: Claude lee el contexto del deal y saca los entregables concretos, los stakeholders nombrados y sus roles, la fecha de inicio del contrato y cualquier fecha o restricción explícita a la que el SOW ya se compromete (una fecha de go-live, un milestone contractual con una penalización). Escribe esto a un scratchpad interno y cuenta los entregables. Si la cuenta es menor a tres, se detiene aquí y devuelve SCOPE_TOO_THIN más la plantilla pelada —la guarda contra convertir una order form delgada en un plan que se ve confiado pero inventado.

La pasada dos es construcción. Claude toma la plantilla elegida de references/1-onboarding-templates.md, superpone los entregables extraídos sobre las fases de la plantilla, asigna a cada milestone un rol de owner de references/2-owner-roster.md y computa fechas objetivo sumando el offset en días de cada milestone al inicio del contrato. Donde el SOW se comprometió a una fecha explícita, esa fecha sobrescribe el offset computado y la Skill marca el milestone como fijado contractualmente para que el CSM no lo mueva a la ligera. El milestone de TTV de references/3-ttv-definition.md se marca, y su fecha objetivo se saca a la superficie en la parte superior del plan como el número titular para el kickoff.

Separar la extracción de la construcción importa por la misma razón por la que la Skill de QBR separa la síntesis del mapeo de slots: una sola pasada sobrepondera el input que leyó al último y produce planes donde las fechas se desvían del scope. Dos pasadas mantienen la extracción de scope honesta y el cálculo de fechas determinista.

El output es un plan en Markdown agrupado por fase con una tabla de milestones (milestone, rol de owner, fecha objetivo, flag de TTV, origen —plantilla vs comprometido-en-SOW) más un resumen de TTV de una línea, y un onboarding-plan.csv hermano con la forma para el import de Rocketlane. El CSM siempre edita antes del kickoff. La Skill es un motor de borrador, no un creador de proyectos.

Realidad de costos

Un solo plan cuesta aproximadamente 6,000 a 15,000 tokens de input (la mayoría el SOW y las notas de handoff) y 2,000 a 4,000 tokens de output con Claude Sonnet —llámalo 3 a 6 centavos por plan a precios actuales de Sonnet. Un SOW enterprise largo con una transcripción completa de discovery aterriza en el extremo alto; una order form de SMB ajustada con un párrafo de notas aterriza muy por debajo. El tiempo de reloj es menos de un minuto; no hay llamadas externas a API en el flujo principal, así que no hay techo de rate-limit alrededor del cual diseñar.

Un CSM construyendo un plan de onboarding desde cero —leyendo el SOW, mapeando entregables a una plantilla, asignando owners, computando fechas— típicamente gasta 30 a 60 minutos por cuenta. La Skill lleva eso a 5 a 15 minutos (la pasada de edición más la preparación del kickoff). Para un onboarding manager levantando 8 a 12 cuentas nuevas al mes, eso es del orden de 6 a 10 horas al mes recuperadas, y más importante, los planes son consistentes entre CSMs en vez de la plantilla idiosincrásica de cada persona.

Métrica de éxito

Rastrea dos números. Primero, el tiempo desde “deal closed-won” hasta “plan de kickoff listo” —la Skill debe jalar la mediana bajo un día hábil dentro del primer mes de uso; los equipos que antes dejaban que esto se deslizara tres a cinco días son los que ven la mayor mejora de TTV, porque el onboarding arranca más pronto. Segundo, la proporción de milestones generados que sobreviven la pasada de edición del CSM —apunta a 70% o más. Por debajo de eso, las plantillas en references/1-onboarding-templates.md no coinciden con cómo el equipo realmente hace onboarding, y el fix es la plantilla, no la Skill. Por encima de 90% y el CSM probablemente está sub-editando y no adaptando el plan a la cuenta.

Un indicador líder que vale la pena observar es la tasa de SCOPE_TOO_THIN. Si una porción grande de deals cerrados lo dispara, el problema upstream es ventas haciendo handoff de cuentas sin SOWs con scope —la Skill está sacando a la superficie un gap de higiene de deal-desk, no fallando.

vs alternativas

vs Rocketlane Nitro. La propia capa agéntica de Rocketlane, Nitro, construye planes de proyecto desde SOWs y llamadas de discovery dentro de Rocketlane. Si ya eres cliente de Rocketlane y vives enteramente dentro de él, Nitro es el camino de menor fricción —no hay Skill que instalar y el plan aterriza nativamente como un proyecto. El trade-off es que la lógica de plan de Nitro es de Rocketlane, no tuya: la regla de resolución de owner, la definición de TTV y los offsets de plantilla son los archivos de referencia de esta Skill, que tú controlas y versionas. Usa Nitro si quieres cero setup y aceptas sus defaults; usa esta Skill cuando quieres que la lógica de plantilla sea tuya y reusable, o cuando no todo onboarding vive en Rocketlane. Las dos no son mutuamente excluyentes —genera con la Skill, importa el CSV y deja que Rocketlane maneje la ejecución y el portal del cliente.

vs una plantilla estática. La mayoría de los equipos arrancan aquí —un Google Doc o una plantilla de Rocketlane que copian por cuenta y editan a mano. La plantilla es gratis y predecible, pero cada copia es una transcripción manual del SOW a la plantilla, y ese es exactamente el trabajo de 30 a 60 minutos que la Skill elimina. La plantilla es la elección correcta para la long tail de onboardings de SMB idénticos donde el SOW no agrega nada que la plantilla no asuma ya; la Skill se gana su lugar en cuentas con variación real de scope, donde mapear el SOW a mano es donde se va el tiempo.

vs un script custom. Un script casero que parsea el SOW y escribe el CSV es plausible si tus SOWs están rígidamente estructurados, pero la mayoría de los SOWs son prosa, y parsear prosa de forma confiable es la parte que los scripts hacen mal. La Skill maneja la prosa; el script no maneja nada que la Skill no haga. Recurre a un script solo si tus SOWs se generan desde un sistema estructurado de deal-desk y llegan como campos limpios —en cuyo caso no necesitas la pasada de extracción en absoluto.

A vigilar

Milestones inventados desde scope delgado. Una order form vaga tienta al modelo a rellenar el plan con milestones que suenan plausibles que nadie puso en scope. Guarda: la pasada de extracción cuenta los entregables concretos y devuelve SCOPE_TOO_THIN con la plantilla pelada cuando hay menos de tres, en vez de construir un plan que compromete al equipo a trabajo inventado.
Fechas presentadas como promesas. Las fechas objetivo son inicio-del-contrato más un offset de plantilla —un default de planeación, no un compromiso de delivery. Guarda: el encabezado del plan declara que las fechas son borrador y pre-kickoff, cada fecha comprometida-en-SOW se marca como fijada contractualmente y se separa visualmente de las fechas computadas, y la Skill nunca escribe fechas a un portal de cara al cliente —ese es un paso humano deliberado después de que el kickoff las confirma.
Plantilla equivocada elegida silenciosamente. Correr la plantilla de SMB en una cuenta enterprise produce un plan que es demasiado corto y con poco staff. Guarda: el nombre de la plantilla es un input requerido —la Skill no lo adivina— y el encabezado del plan hace eco de la plantilla elegida y su segmento para que un mismatch sea visible en la parte superior antes de que alguien lea los milestones.
Roles de owner dejados sin resolver. Un plan con roles de owner pero sin personas nombradas no es accionable. Guarda: la Skill asigna un rol a cada milestone y aplica la regla de resolución del lado del cliente de references/2-owner-roster.md; cualquier milestone cuyo owner no se pueda resolver desde el contexto del deal se marca OWNER_TBD en vez de dejarse en blanco, así el CSM ve exactamente qué llenar antes del kickoff.
Offsets obsoletos tras un cambio de motion. Cuando el equipo cambia su motion de onboarding, los planes siguen heredando los offsets de días viejos hasta que el archivo de referencia se actualiza. Guarda: el archivo de plantilla carga su propia fecha last_reviewed, y el encabezado del plan la saca a la superficie; un offset configurado hace más de 6 meses es un aviso para re-confirmar el motion antes de confiar en las fechas.

Stack

Claude —generación de plan en dos pasadas: extracción de scope, luego construcción del plan con cálculo de fechas (Sonnet recomendado; el trabajo no necesita Opus)
Rocketlane —destino opcional de última milla; el CSV se mapea al import de proyectos de Rocketlane para que los milestones aterricen sin re-tipeo, y Rocketlane corre la ejecución y el portal del cliente
Los tres archivos de referencia —1-onboarding-templates.md (fases, milestones, roles de owner, offsets de días), 2-owner-roster.md (rol-a-persona y resolución del lado del cliente), 3-ttv-definition.md (milestone de primer valor por plantilla)

Editar esta página en GitHub