Gere um plano de onboarding de cliente com Claude

Uma Claude Skill que transforma o contexto do deal —a oportunidade closed-won, o SOW, as notas da call de discovery— em um plano de onboarding baseado em milestones com owners nomeados, datas-alvo ancoradas ao início do contrato e uma meta explícita de time-to-value (TTV). O output é um plano em Markdown estruturado mais um CSV de milestones que mapeia de forma limpa para o import de projetos do Rocketlane, então o CSM vai de “o deal acabou de fechar, sem plano” para um draft pronto para o kickoff em minutos em vez de encarar um template em branco. O bundle do artifact inclui o SKILL.md mais três arquivos de referência que o time de onboarding adapta uma vez e reusa em cada conta nova.

Quando usar

Você é um CSM ou onboarding manager que acabou de herdar uma conta recém-fechada e precisa de um plano para levar à call de kickoff. O contexto do deal existe —há um SOW assinado ou uma order form, o AE deixou notas de handoff, talvez uma transcrição da call de discovery— mas ninguém o transformou em um plano sequenciado com owners e datas. Esta Skill faz essa conversão. Ela é construída para o caso comum em que o onboarding é templatizado por segmento (um motion padrão de 30/60/90 para SMB, um rollout em fases mais longo para enterprise) e o trabalho é adaptar o template ao scope, às integrações e aos stakeholders específicos desta conta.

Ela produz o output mais útil quando o SOW nomeia entregáveis concretos, a data de início do contrato é conhecida e você consegue dizer a ela qual template de onboarding (segmento, edição do produto, tipo de deployment) se aplica. Dê esses três e ela devolve um plano que você edita em vez de redigir. É uma Skill de nível beginner de propósito: nenhum wiring de API é necessário para obter o primeiro plano —você cola o contexto do deal no Claude e recebe de volta o plano e o CSV. O import para o Rocketlane é a última milha opcional que coloca os milestones no seu PSA sem re-digitação manual.

Quando NÃO usar

Não use para auto-criar projetos do Rocketlane sem uma passada humana. A Skill escreve um plano draft; o CSM é dono do compromisso. As datas-alvo que a Skill calcula a partir do início do contrato são pontos de partida, não promessas ao cliente —um CSM que empurra o CSV direto para o Rocketlane e para um portal voltado ao cliente sem revisão vai enviar datas que o time de delivery nunca acordou.

Não use para contas onde não há SOW nem lista de entregáveis com scope —um plano gerado a partir de uma order form de uma linha é um template genérico com o nome da conta colado, e você ficaria melhor começando direto do template. A Skill sinaliza isso: se o contexto do deal contém menos de três entregáveis concretos, ela devolve um aviso SCOPE_TOO_THIN e o template pelado em vez de inventar milestones que se leem plausíveis e comprometem seu time com trabalho que ninguém colocou no scope.

Não use para planejamento de renewal ou expansão —esses são guiados por uso e progresso do success plan, não por um SOW novo, e a lógica de milestones aqui assume uma implementação greenfield. Para health contínuo e expansão os artifacts relevantes são os workflows de customer health score e de detecção de sinais de expansão, não este.

Não use como substituto da conversa de kickoff. O plano é o input para o kickoff, onde o cliente confirma owners, datas e sequência. Um plano que pula essa confirmação é um plano que o cliente nunca acordou.

Setup

Aproximadamente 30 a 45 minutos na primeira vez, quase todo gasto adaptando os três arquivos de referência ao motion de onboarding do seu time. Depois disso, cada plano novo é colar-e-rodar.

1. Instale a Skill. Coloque o bundle de apps/web/public/artifacts/onboarding-plan-generator-skill/ em ~/.claude/skills/onboarding-plan-generator/. O SKILL.md define um comportamento de entrada —dado o contexto do deal e um nome de template, produza um plano— mais os helpers de parsing e de cálculo de datas. Nenhuma credencial é necessária para o fluxo principal.
2. Adapte os templates de milestones. Abra references/1-onboarding-templates.md e substitua os templates de exemplo pelos reais. Inclua pelo menos dois: um motion curto de SMB e um motion enterprise em fases. Cada template é uma lista de fases, os milestones dentro de cada fase, o role de owner default por milestone (CSM, onboarding-manager, customer-champion, solutions-engineer) e o offset em dias a partir do início do contrato. Os offsets são o que a Skill transforma em datas-alvo; acerte-os uma vez e cada plano os herda.
3. Defina o roster de owners. Abra references/2-owner-roster.md e mapeie os roles de owner para como seu time os nomeia, mais a regra para resolver o owner do lado do cliente (geralmente “o economic buyer nomeado no SOW” ou “o sponsor do projeto das notas de handoff”). A Skill atribui um role de owner a cada milestone; este arquivo é como um role vira uma pessoa nomeada.
4. Configure a definição de TTV. Abra references/3-ttv-definition.md e declare, por template, o que “time to value” significa para o seu produto —o milestone específico cuja conclusão é o primeiro valor (primeira integração no ar, primeiro relatório enviado, primeiro time totalmente provisionado). A Skill marca esse milestone no plano e calcula a data-alvo de TTV para que o kickoff tenha um número, não uma sensação.
5. Rode para uma conta. Cole o contexto do deal —texto ou resumo do SOW, data de início do contrato, notas de handoff do AE e o nome do template— no Claude com a Skill ativa. Ela devolve o plano em Markdown mais onboarding-plan.csv. Para o import opcional para o Rocketlane, no Rocketlane abra o projeto, escolha Import e mapeie as colunas do CSV (milestone, phase, owner_role, target_date, is_ttv_milestone) para os campos de tarefas do Rocketlane; os nomes de colunas no arquivo de referência já batem com o schema de import do Rocketlane.

O que a Skill realmente faz

A Skill roda em duas passadas porque a extração de scope e a construção do plano são trabalhos diferentes e combiná-los produz planos que alucinam entregáveis. A passada um é extração: o Claude lê o contexto do deal e puxa os entregáveis concretos, os stakeholders nomeados e seus roles, a data de início do contrato e qualquer data ou restrição explícita à qual o SOW já se compromete (uma data de go-live, um milestone contratual com penalidade). Ele escreve isso em um scratchpad interno e conta os entregáveis. Se a contagem for menor que três, ele para aqui e devolve SCOPE_TOO_THIN mais o template pelado —a guarda contra transformar uma order form fina em um plano que parece confiante mas é inventado.

A passada dois é construção. O Claude pega o template escolhido de references/1-onboarding-templates.md, sobrepõe os entregáveis extraídos sobre as fases do template, atribui a cada milestone um role de owner de references/2-owner-roster.md e calcula datas-alvo somando o offset em dias de cada milestone ao início do contrato. Onde o SOW se comprometeu com uma data explícita, essa data sobrescreve o offset calculado e a Skill sinaliza o milestone como fixado contratualmente para que o CSM não o mova sem cuidado. O milestone de TTV de references/3-ttv-definition.md é marcado, e sua data-alvo é trazida ao topo do plano como o número de destaque para o kickoff.

Separar a extração da construção importa pela mesma razão pela qual a Skill de QBR separa a síntese do mapeamento de slots: uma única passada superpondera o input que leu por último e produz planos onde as datas se desviam do scope. Duas passadas mantêm a extração de scope honesta e o cálculo de datas determinístico.

O output é um plano em Markdown agrupado por fase com uma tabela de milestones (milestone, role de owner, data-alvo, flag de TTV, origem —template vs comprometido-no-SOW) mais um resumo de TTV de uma linha, e um onboarding-plan.csv irmão com o formato para o import do Rocketlane. O CSM sempre edita antes do kickoff. A Skill é um motor de draft, não um criador de projetos.

Realidade de custos

Um único plano custa aproximadamente 6,000 a 15,000 tokens de input (a maior parte o SOW e as notas de handoff) e 2,000 a 4,000 tokens de output com Claude Sonnet —chame de 3 a 6 centavos por plano aos preços atuais do Sonnet. Um SOW enterprise longo com uma transcrição completa de discovery aterrissa no extremo alto; uma order form de SMB enxuta com um parágrafo de notas aterrissa bem abaixo. O tempo de relógio é menos de um minuto; não há chamadas externas de API no fluxo principal, então não há teto de rate-limit ao redor do qual desenhar.

Um CSM construindo um plano de onboarding do zero —lendo o SOW, mapeando entregáveis para um template, atribuindo owners, calculando datas— normalmente gasta 30 a 60 minutos por conta. A Skill leva isso a 5 a 15 minutos (a passada de edição mais o prep do kickoff). Para um onboarding manager subindo 8 a 12 contas novas por mês, isso é da ordem de 6 a 10 horas por mês recuperadas, e mais importante, os planos são consistentes entre CSMs em vez do template idiossincrático de cada pessoa.

Métrica de sucesso

Acompanhe dois números. Primeiro, o tempo de “deal closed-won” até “plano de kickoff pronto” —a Skill deve puxar a mediana para menos de um dia útil dentro do primeiro mês de uso; os times que antes deixavam isso escorregar três a cinco dias são os que veem a maior melhora de TTV, porque o onboarding começa mais cedo. Segundo, a proporção de milestones gerados que sobrevivem à passada de edição do CSM —mire em 70% ou mais. Abaixo disso, os templates em references/1-onboarding-templates.md não batem com como o time realmente faz onboarding, e o fix é o template, não a Skill. Acima de 90% e o CSM provavelmente está sub-editando e não adaptando o plano à conta.

Um indicador antecedente que vale a pena observar é a taxa de SCOPE_TOO_THIN. Se uma fatia grande de deals fechados o dispara, o problema upstream é vendas fazendo handoff de contas sem SOWs com scope —a Skill está trazendo à tona um gap de higiene de deal-desk, não falhando.

vs alternativas

vs Rocketlane Nitro. A própria camada agêntica do Rocketlane, o Nitro, constrói planos de projeto a partir de SOWs e calls de discovery dentro do Rocketlane. Se você já é cliente do Rocketlane e vive inteiramente dentro dele, o Nitro é o caminho de menor fricção —não há Skill para instalar e o plano aterrissa nativamente como um projeto. O trade-off é que a lógica de plano do Nitro é do Rocketlane, não sua: a regra de resolução de owner, a definição de TTV e os offsets de template são os arquivos de referência desta Skill, que você controla e versiona. Use o Nitro se quer zero setup e aceita seus defaults; use esta Skill quando quer que a lógica de template seja sua e reusável, ou quando nem todo onboarding vive no Rocketlane. Os dois não são mutuamente exclusivos —gere com a Skill, importe o CSV e deixe o Rocketlane cuidar da execução e do portal do cliente.

vs um template estático. A maioria dos times começa aqui —um Google Doc ou um template do Rocketlane que copiam por conta e editam à mão. O template é grátis e previsível, mas cada cópia é uma transcrição manual do SOW para o template, e esse é exatamente o trabalho de 30 a 60 minutos que a Skill remove. O template é a escolha certa para a long tail de onboardings de SMB idênticos onde o SOW não adiciona nada que o template já não assuma; a Skill ganha seu lugar em contas com variação real de scope, onde mapear o SOW à mão é onde o tempo vai.

vs um script custom. Um script caseiro que parseia o SOW e escreve o CSV é plausível se seus SOWs são rigidamente estruturados, mas a maioria dos SOWs é prosa, e parsear prosa de forma confiável é a parte que os scripts erram. A Skill cuida da prosa; o script não cuida de nada que a Skill não faça. Recorra a um script só se seus SOWs são gerados a partir de um sistema estruturado de deal-desk e chegam como campos limpos —caso em que você não precisa da passada de extração de jeito nenhum.

A vigiar

• Milestones inventados a partir de scope fino. Uma order form vaga tenta o modelo a encher o plano com milestones que soam plausíveis que ninguém colocou no scope. Guarda: a passada de extração conta os entregáveis concretos e devolve SCOPE_TOO_THIN com o template pelado quando há menos de três, em vez de construir um plano que compromete o time com trabalho inventado.
• Datas apresentadas como promessas. As datas-alvo são início-do-contrato mais um offset de template —um default de planejamento, não um compromisso de delivery. Guarda: o cabeçalho do plano declara que as datas são draft e pré-kickoff, cada data comprometida-no-SOW é sinalizada como fixada contratualmente e separada visualmente das datas calculadas, e a Skill nunca escreve datas em um portal voltado ao cliente —esse é um passo humano deliberado depois que o kickoff as confirma.
• Template errado escolhido silenciosamente. Rodar o template de SMB em uma conta enterprise produz um plano curto demais e com pouca equipe. Guarda: o nome do template é um input obrigatório —a Skill não o adivinha— e o cabeçalho do plano ecoa o template escolhido e seu segmento para que um mismatch seja visível no topo antes de alguém ler os milestones.
• Roles de owner deixados sem resolução. Um plano com roles de owner mas sem pessoas nomeadas não é acionável. Guarda: a Skill atribui um role a cada milestone e aplica a regra de resolução do lado do cliente de references/2-owner-roster.md; qualquer milestone cujo owner não possa ser resolvido a partir do contexto do deal é sinalizado OWNER_TBD em vez de deixado em branco, então o CSM vê exatamente o que preencher antes do kickoff.
• Offsets obsoletos após uma mudança de motion. Quando o time muda seu motion de onboarding, os planos continuam herdando os offsets de dias antigos até o arquivo de referência ser atualizado. Guarda: o arquivo de template carrega sua própria data last_reviewed, e o cabeçalho do plano a traz à tona; um offset configurado há mais de 6 meses é um aviso para re-confirmar o motion antes de confiar nas datas.

Stack

• Claude —geração de plano em duas passadas: extração de scope, depois construção do plano com cálculo de datas (Sonnet recomendado; o trabalho não precisa de Opus)
• Rocketlane —destino opcional de última milha; o CSV mapeia para o import de projetos do Rocketlane para que os milestones aterrissem sem re-digitação, e o Rocketlane roda a execução e o portal do cliente
• Os três arquivos de referência —1-onboarding-templates.md (fases, milestones, roles de owner, offsets de dias), 2-owner-roster.md (role-para-pessoa e resolução do lado do cliente), 3-ttv-definition.md (milestone de primeiro valor por template)