SOP de handoff de Sales para CS

O handoff de Sales para CS é onde nascem a maioria dos problemas de onboarding. O AE fecha, passa para o próximo deal, e o CSM herda um registro de HubSpot com um estágio closed-won, um valor de contrato e quase nada sobre por que o cliente comprou ou o que foi prometido a ele. O CSM gasta a primeira call de kickoff redescobrindo o deal em vez de tocar o onboarding. Este SOP resolve isso com três coisas: um conjunto fixo de campos de handoff que o AE preenche antes de o deal ser marcado como closed-won, uma regra de timing que amarra o handoff ao estágio do deal em vez de à memória, e uma sequência de kickoff que roda igual toda vez. É deliberadamente chato. Um handoff que depende de o AE lembrar de escrever uma boa mensagem no Slack é um handoff que falha na semana em que o AE está de PTO.

O bundle do artifact fica em apps/web/public/artifacts/sales-to-cs-handoff-sop/. Ele inclui handoff-sop.md (o procedimento em si, pronto para colar no Notion ou numa base de conhecimento do HubSpot), handoff-fields.csv (o manifesto de campos com tipos e flags de obrigatório/opcional para o admin do HubSpot provisionar), e slack-handoff-template.md (a mensagem canônica de canal que o AE posta). Adapte os três aos seus nomes de campos e convenções de canal antes do rollout.

Quando usar isto

Use este SOP quando você tem um time de Sales e um time de CS distintos —um AE que é dono do deal até o fechamento e um CSM que é dono do cliente depois— e o handoff entre eles é informal ou não documentado. O sintoma clássico é um CSM abrindo cada call de kickoff perguntando ao cliente coisas cuja resposta o AE já sabia: quem é o sponsor executivo, como o sucesso se parece em 90 dias, por que escolheram você em vez do incumbente. Cada uma dessas perguntas é um pequeno imposto sobre o relacionamento, e o cliente paga.

Encaixa melhor para times na faixa de 100 a 2.000 clientes rodando sobre HubSpot como o CRM e Slack como a camada de comunicação interna. Abaixo de ~100 clientes o AE e o CSM costumam ser a mesma pessoa ou sentar perto o bastante para um SOP documentado ser overhead. Acima de ~2.000 você provavelmente precisa de uma plataforma de CS (Gainsight, Catalyst, Vitally, ChurnZero) tocando o handoff via uma CTA em vez de uma propriedade de deal do HubSpot e um post de Slack —nessa escala o post manual é o que acaba sendo pulado. Este SOP é a ferramenta certa na faixa onde o processo importa mas o orçamento de tooling ainda não justifica um CSP dedicado.

Quando NÃO usar isto

Não adote isto se seus AEs não são responsáveis pela qualidade de dados no fechamento. O SOP é tão bom quanto os campos, e os campos só são preenchidos se “closed-won exige o bloco de handoff completo” for imposto —por uma regra de campo-obrigatório do HubSpot, um gate de estágio de deal, ou um gestor que segura a comissão até estar pronto. Sem essa imposição você fica com campos pela metade que são piores que nenhum, porque o CSM confia neles e se queima.

Não o use como substituto de o AE e o CSM realmente conversarem. Os campos carregam os fatos estruturados; não carregam a textura —o champion que está em particular nervoso com a adoção, o contato de procurement que brigou contra o deal, a feature que o AE meio prometeu na última call. A call de warm handoff de 15 minutos na sequência abaixo é onde esse contexto é transferido. Pulá-la e confiar só nos campos produz handoffs tecnicamente-completos que ainda assim perdem aquilo que afunda o renewal.

Não cole isto num motion de renewal ou expansão. Este SOP tem escopo no handoff de logo novo: AE para CSM, uma vez, no fechamento. Renewals e expansões têm donos diferentes e sinais diferentes, e forçá-los por esta template produz ruído.

Os campos de handoff

Estes vivem como propriedades de deal ou company do HubSpot para que viajem com o registro e sejam consultáveis depois. O manifesto em handoff-fields.csv os provisiona. O conjunto obrigatório, cada um preenchido antes de closed-won:

• Sponsor executivo (referência de contato) —a pessoa de quem é esse orçamento e que vai pegar a call de renewal. Não o champion do dia a dia; o comprador econômico.
• Champion do dia a dia (referência de contato) —com quem o CSM trabalha semanalmente. Frequentemente diferente do sponsor.
• Por que compraram (texto longo) —o trigger de negócio real em uma ou duas frases. “O renewal da ferramenta legacy era 3x nosso preço” é útil; “queriam analytics melhor” não.
• Sucesso definido / a métrica (texto longo) —o que o cliente disse que se parece com ganhar, idealmente um número com uma data. Isto vira a estrela-guia do success plan.
• Prometido no deal (texto longo) —qualquer coisa a que o AE se comprometeu que não está no contrato padrão: uma integração custom, uma data específica de go-live, uma feature no roadmap. Este é o campo que previne as piores falhas de handoff.
• Escopo contratado (estruturado) —seats, produtos/SKUs, ARR, datas de início e renewal de contrato.
• Ambiente técnico (texto longo) —o CRM, data warehouse, provedor de SSO, e qualquer integração que o cliente espera no dia um.
• Riscos conhecidos (texto longo) —o contato de procurement que empurrou de volta, a ferramenta interna concorrente, o time de usuários finais cético. Trazido à luz agora ou descoberto na marra depois.

Dois campos opcionais ganham seu lugar quando presentes: gravações de calls (link para a biblioteca de Gong/gravações das calls-chave do deal) e timeline de decisão (quanto tempo a avaliação rodou e quem mais estava na sala), que diz ao CSM quanto peso organizacional a compra carrega.

A regra de timing

O handoff é gated no estágio do deal, não no calendário do AE. A regra: o bloco de handoff deve estar completo antes de o deal poder mover para closed-won, e a call de warm handoff deve acontecer dentro de três dias úteis do fechamento. Amarrá-lo ao estágio em vez de a um lembrete é o ponto inteiro —um lembrete é adiado; um gate de estágio é imposto pelo pipeline. No HubSpot isto é uma regra de propriedade-obrigatória-no-estágio mais um workflow que posta no Slack na mudança de estágio.

A sequência de kickoff

1. O AE completa o bloco de handoff antes de marcar closed-won. O gate de estágio do HubSpot recusa o movimento caso contrário.
2. O workflow do HubSpot posta em #cs-handoffs na mudança de estágio para closed-won, usando a template em slack-handoff-template.md: company, ARR, sponsor, champion, por-que-compraram, a métrica, qualquer coisa prometida, e um link para o registro do deal. O post @-menciona o CSM atribuído.
3. O CSM confirma na thread dentro de um dia útil —uma reação não é confirmação; um CSM tem que confirmar que leu o campo de prometido-no-deal especificamente.
4. O AE + CSM rodam uma call de warm handoff de 15 minutos dentro de três dias úteis. Agenda: percorrer os riscos conhecidos, confirmar os itens prometidos, transferir a textura do relacionamento que os campos não conseguem conter. Isto é registrado como uma meeting do HubSpot no registro.
5. O CSM agenda o kickoff externo com o cliente, tendo já lido o deal. O cliente nunca re-explica por que comprou.

Como o sucesso se parece

Acompanhe três números. Primeiro, completude do handoff —a porcentagem de deals closed-won com cada campo obrigatório preenchido. O gate de estágio deve levar isto a quase 100% dentro de duas semanas; se ficar mais baixo, o gate não está realmente sendo imposto e você está rodando no sistema de honra. Segundo, tempo-até-kickoff —dias de closed-won até a call de kickoff externo. Mire numa mediana abaixo de sete dias úteis; um lag mais longo significa que o momentum de compra do cliente está decaindo antes de o onboarding começar. Terceiro, a taxa de redescoberta —pesquise os CSMs mensalmente: “nos seus últimos cinco kickoffs, quantas vezes você teve que perguntar ao cliente algo que o AE deveria ter registrado?” Mire em zero. Qualquer coisa acima de um por kickoff significa que os campos estão presentes mas não são confiados, o que geralmente se rastreia a AEs preenchendo-os com enchimento para passar o gate.

Versus as alternativas

Versus um handoff de Slack em texto livre. O status quo na maioria dos times é o AE postando uma mensagem não estruturada num canal quando lembra. É mais rápido de escrever e pior em tudo o mais: não é consultável, não é imposto, sua qualidade oscila com o humor do AE, e some no scroll do canal. A versão de campos estruturados custa ao AE talvez três minutos extras por deal e torna o handoff auditável. Escolha texto livre só se seu volume for tão baixo (abaixo de ~5 handoffs por mês) que a estrutura não compense o setup.

Versus uma CTA de plataforma de CS (Gainsight, Catalyst, Vitally, ChurnZero). Um CSP pode disparar uma CTA de handoff automaticamente no closed-won, roteá-la, e rastrear a completude nativamente —mecânica estritamente melhor que HubSpot-mais-Slack. O trade-off é custo e setup: um CSP roda cinco dígitos anuais e semanas para implementar. Se você já tem um, toque o handoff por ele e use a lista de campos e a sequência deste SOP como o conteúdo. Se não, este SOP te dá 80% do valor ao custo de provisionar oito propriedades do HubSpot e um workflow.

Versus não fazer nada. Viável só se o AE e o CSM forem a mesma pessoa ou dividirem a mesa. No momento em que os dois papéis se separam, o handoff não documentado vira a maior fonte individual de churn precoce evitável —o cliente que faz churn no mês quatro porque a integração que o AE prometeu nunca esteve no roadmap.

Pontos de atenção

• Campos preenchidos com enchimento para passar o gate. No momento em que closed-won é gated na completude de campos, os AEs têm um incentivo de digitar “n/a” ou “ver notas” para passá-lo. Guarda: torne a call de warm handoff obrigatória e faça o CSM rejeitar o handoff na thread se os campos de prometido-no-deal ou métrica-de-sucesso estiverem vazios ou lixo —o AE não consegue que o deal seja contado como limpamente entregue até o CSM aceitá-lo.
• O campo de prometido-no-deal deixado em branco. Esta é a omissão de maior custo: um compromisso verbal que o AE fez e esqueceu, que o cliente lembra e espera. Guarda: torne este campo obrigatório mesmo quando vazio forçando uma entrada explícita de “nada prometido além do contrato”, para que um branco seja uma declaração deliberada em vez de um descuido.
• O post de Slack dispara mas ninguém é dono da confirmação. Um handoff postado num canal ao qual nenhum CSM está atribuído é um handoff no vazio. Guarda: o workflow do HubSpot @-menciona o CSM atribuído específico por mapeamento de deal-owner-para-CSM, e o SOP exige uma confirmação na thread dentro de um dia útil, rastreada pelo lead de CS.
• O SOP deriva conforme o schema do CRM muda. Uma propriedade do HubSpot renomeada ou um novo estágio de deal quebra silenciosamente o workflow que posta no Slack. Guarda: revise o manifesto de campos em handoff-fields.csv contra as propriedades vivas do HubSpot uma vez por trimestre, e mantenha a lista de campos da template de Slack em sync com os nomes das propriedades de deal.