Casos de Uso

A Apollo consegue rodar seu customer onboarding?

Onboarding é um checklist observado com prazos e riscos, a janela de maior churn que você tem, e um agent proativo persegue cada passo até o cliente chegar ao primeiro valor.

ASR

Apollo Space Research

Apollo Space

· 11 min de leitura

Um cliente assina numa segunda. Até sexta ele logou uma vez, não conectou nada, não convidou ninguém, e viu o produto fazer exatamente zero da coisa pela qual ele comprou. Ninguém deixou a bola cair. O email de boas-vindas saiu, a call de kickoff aconteceu, o checklist existe nas notas de alguém. O cliente só silenciosamente travou no passo dois, e o passo dois não tem dono, não tem prazo que morde, e ninguém observando.

Essa trava é onde a maior parte do churn de fato nasce. Não no mês nove, quando eles cancelam. Na semana um, quando nunca chegaram à parte que valia a pena pagar.

Então: a Apollo consegue rodar seu customer onboarding? Sim, porque onboarding é um checklist observado com prazos e riscos, e um agent proativo persegue cada passo até o cliente chegar ao primeiro valor. Essa frase é a resposta inteira. O resto deste post a merece, passo a passo.

Onboarding não é um documento. É um processo sem motor.

Toda empresa escreve o onboarding. Há um checklist em algum lugar: mandar boas-vindas, agendar kickoff, conectar a fonte de dados, convidar o time, completar a primeira tarefa de verdade, atingir o marco que prova que a coisa funciona. É uma boa lista. Quase sempre está correta.

E quase sempre apodrece, porque um checklist é uma descrição de um processo, não o processo em si.

Um documento não consegue notar que o cliente conectou seus dados na terça e aí ficou em silêncio. Não consegue dizer que o passo quatro está “em andamento” há nove dias. Não consegue distinguir entre um cliente disparando na frente e um que está travado, envergonhado, e a três dias de decidir que isso foi um erro. A lista sabe os passos. Não tem ideia de onde qualquer cliente em particular está neles, e esse gap é o problema inteiro.

Então o trabalho recai sobre um humano. Alguém, um founder, um especialista de onboarding, um account manager usando quatro chapéus, segura o estado real de cada novo cliente na cabeça. Quem está na frente. Quem travou. Quem recebeu as boas-vindas mas nunca marcou a call. Quem precisa de um nudge hoje e quem precisa de um na quinta. Eles carregam, e carregam bem, até terem mais que um punhado de clientes ao mesmo tempo. Aí a lista para de ser um processo e vira uma reza.

A correção ingênua é encher mais o saco. Mais emails automáticos. Uma sequência de drip que dispara num timer quer o cliente precise ou não. Todos nós já recebemos essa sequência, o “só passando para ver!” do dia três que chega no dia depois de você terminar, o lembrete do dia sete para um passo que você completou na hora dois. Ela trata cada cliente como o mesmo cliente se movendo na mesma velocidade. Não está observando. Está transmitindo num cronograma e torcendo para o cronograma por acaso estar certo.

Um timer não é um observador. Um timer dispara quer algo esteja errado ou não; um observador dispara porque algo está errado. Essa diferença é o produto inteiro.

A correção é dar ao checklist um motor que observa

Aqui está a ideia-chave, e é simples. Pare de armazenar onboarding como um documento que um humano lê. Armazene como um processo que um sistema roda, um passo por estado, cada passo com um dono, um prazo que morde, e uma definição de pronto que o sistema de fato consegue checar.

Uma vez que é um processo e não uma página, três coisas se tornam possíveis que nunca foram possíveis no papel.

Primeiro, o sistema sempre sabe onde cada cliente está. Não “mandamos o email de onboarding”. E sim: este cliente está no passo três, conectou seus dados quatro dias atrás, não convidou um único colega de time, e o passo de convite está aberto além do prazo desde esta manhã. Estado, não histórico.

Segundo, cada passo tem um prazo que significa algo. Um prazo num documento é decoração. Um prazo dentro de um processo rodando é um gatilho, quando ele passa e o passo não está pronto, algo acontece sem ninguém lembrar de fazer acontecer.

Terceiro, o sistema consegue agir no gap. Consegue mandar o nudge, mas o nudge certo, ao cliente certo, sobre o único passo em que ele de fato está travado, no momento em que está travado e não num dia três arbitrário de um calendário. E quando o nudge é a ferramenta errada, consegue fazer a coisa que só um humano deveria: sinalizar uma pessoa de verdade para entrar, com o contexto completo já montado.

Duas maneiras de rodar onboarding. À esquerda, um checklist de papel que sabe os passos mas não onde cada cliente está, então um humano cansado carrega o estado real na cabeça e um drip baseado em timer dispara num cronograma que ignora a realidade. À direita, o checklist vira um processo rodando: cada passo é um estado com um dono e um prazo que morde, um observador rastreia onde cada cliente de fato está, e o motor cutuca o cliente travado ou escala para um humano no momento exato em que um passo fica atrasado.

Essa é a virada sobre a qual a resposta inteira se apoia. Onboarding é um checklist observado com prazos e riscos, e um agent proativo persegue cada passo até o cliente chegar ao primeiro valor. Um documento não consegue perseguir. Um timer persegue o calendário. Só um processo com um observador persegue o cliente.

Passo a passo: o que “perseguir cada passo” de fato significa

Abstrações são fáceis de concordar e difíceis de confiar, então vamos percorrer um formato real. Digamos que o onboarding tenha seis passos, boas-vindas, kickoff agendado, dados conectados, time convidado, primeira tarefa completa, marco de primeiro valor atingido. Os números aqui são ilustrativos; escolha qual for o seu fluxo real. O mecanismo é o mesmo.

O cliente assina. O processo começa. O passo um, boas-vindas, dispara imediatamente e marca como pronto. O passo dois, kickoff agendado, abre com um prazo de, digamos, dois dias úteis. Esta é a parte que um documento não consegue: o prazo não é uma nota, é um relógio.

Dois dias passam. O kickoff não está no calendário. No papel, isto é invisível, ninguém rola um checklist procurando passos que silenciosamente não aconteceram. Num processo rodando, o prazo passando é um evento. O observador vê que o passo dois ficou atrasado, e agora o sistema tem uma decisão a tomar: cutucar, ou escalar?

Esta é a parte que as pessoas subestimam. A decisão não é “sempre mandar email”. Um bom motor de onboarding sabe a diferença entre um passo que um cliente consegue destravar sozinho, “aqui está um link de um clique para marcar seu kickoff”, e um passo que precisa de um humano, onde a jogada certa é entregar ao dono da conta um aviso pronto: este cliente não marcou, aqui está o link para mandar a ele, aqui está tudo que você gostaria de saber antes de entrar em contato. O primeiro é um nudge. O segundo é uma escalação. Tratar cada passo atrasado como um ou outro é como você ou faz spam com clientes ou os perde silenciosamente.

O cliente marca o kickoff. O passo dois vira pronto. O passo três abre. O relógio reseta. E o loop roda de novo, abre o passo, observa o prazo, checa a definição de pronto, cutuca ou escala quando escorrega, avança quando é cumprido, para cada cliente, em paralelo, sem um humano segurando nada disso na cabeça.

O loop de onboarding para um único passo, rodando para cada cliente ao mesmo tempo. O passo abre com um prazo. Um observador checa se a definição de pronto é cumprida antes de o relógio esgotar. Se for, o próximo passo abre e o relógio reseta. Se o prazo passar primeiro, o motor decide entre um nudge self-serve ao cliente e uma escalação que entrega a um humano a conta, o passo bloqueado, e o contexto completo, e então segue observando até o passo limpar.

Note o que o loop nunca faz. Ele nunca esquece um cliente porque o humano que o rastreava ficou ocupado. Nunca cutuca alguém sobre um passo que já terminou. Nunca deixa um passo ficar “em andamento” por nove dias porque ninguém rolou o suficiente para baixo na lista para vê-lo. O observar é contínuo e o observar é o ponto.

Por que “primeiro valor” é a única linha de chegada que conta

Há uma armadilha no onboarding que vale nomear, porque a versão checklist anda direto nela. A armadilha é medir conclusão em vez de valor.

É sedutor chamar o onboarding de “pronto” quando os passos estão marcados. Os dados estão conectados, o time convidado, a primeira tarefa existe, seis checkmarks verdes, manda ver, move para o time de success. Mas um cliente que completou cada passo e ainda não sentiu o produto fazer a coisa valiosa não está onboarded. Ele está configurado. São coisas diferentes. Um cliente configurado dá churn tão rápido quanto um abandonado; ele só dá churn educadamente, tendo preenchido todos os seus campos primeiro.

A métrica ingênua é passos completos, porque passos são fáceis de contar. A métrica honesta é primeiro valor atingido, o momento em que o cliente vê o produto produzir o resultado pelo qual comprou. Esse momento é a linha de chegada de verdade, e um bom motor de onboarding é feito para perseguir isso, tratando cada passo antes dele como um meio, não o fim.

É por isso que o observador não pode só rastrear checkboxes. Ele tem que saber qual passo é o passo de valor, aquele em que o cliente primeiro recebe a coisa, e tem que seguir perseguindo até que esse passo, especificamente, seja atingido. Um cliente travado no passo cinco com tudo antes dele verde está mais em risco que um travado no passo dois, porque investiu mais e não recebeu nada. O motor que só conta caixas não consegue ver isso. O motor que está mirado no primeiro valor não consegue perdê-lo.

A razão de isto importar tanto é que a janela inicial é o jogo inteiro. Um cliente nas suas primeiras semanas pagou mas ainda não acreditou. Ele está decidindo, silenciosamente, se foi uma boa decisão, e está decidindo com base em se o produto já fez algo por ele. Cada dia travado nessa janela é um dia em que a dúvida compõe. Leve-o ao primeiro valor rápido e a relação está feita. Deixe-o travar e você já o perdeu; você só não vai descobrir até a renovação.

A virada: onboarding nunca foi um trabalho administrativo

Tire os passos e os prazos e aqui está o que sobra.

Agora, na maioria das empresas, a pessoa fazendo onboarding na mão é uma das suas melhores pessoas, e o onboarding está comendo a semana dela. Ela é o founder que pessoalmente observa cada nova conta porque não confia no drip e está certa em não confiar. É a success manager carregando “onde está cada um” de trinta clientes na cabeça, sabendo que no momento em que carregar trinta e um, alguém escorrega. Ela está fazendo o trabalho mais humano da empresa, recepcionar alguém, ajudá-lo a ter sucesso, e gastando a maior parte desse trabalho na parte menos humana: lembrar quem está travado e ir atrás.

Essa perseguição não é a relação. É o imposto sobre a relação. O lembrete de marcar a call, a checagem de se os dados conectaram, a nota mental de que este cliente anda quieto, nada disso é o calor ou o julgamento ou o “notei que você talvez queira de verdade esta outra coisa”. É escrituração vestindo a fantasia de cuidado. E é exatamente a parte que um observador pode assumir.

Entregue o observar ao sistema e a conta se inverte. O motor persegue os passos; o humano aparece para os momentos que precisam de um humano, o cliente que está tendo dificuldade por uma razão que nenhum checklist poderia capturar, a conversa de expansão que os dados silenciosamente sugerem, a relação que vale dez minutos de atenção real em vez de trinta segundos de “só passando para ver!” O ponto nunca foi remover o humano do onboarding. É parar de gastar a semana da sua melhor pessoa em lembrar, para que ela possa gastá-la na parte que só uma pessoa consegue.


Então, a Apollo consegue rodar seu customer onboarding? É para isso que estamos construindo a Apollo, não uma sequência de drip mais esperta, mas um company brain que segura o estado real de cada novo cliente, observa os passos que ficam atrasados, persegue o travado com o nudge certo, e puxa um humano no momento em que um humano é o necessário. Onboarding é um checklist observado com prazos e riscos, e um agent proativo persegue cada passo até o cliente chegar ao primeiro valor. Os clientes que deram churn na semana um nunca foram perdidos para um produto ruim. Foram perdidos para um passo que ninguém observava, e isso, finalmente, é uma coisa que você pode parar de perder.

A Apollo cuida da operação repetitiva da sua empresa pro seu time não precisar.

Entre na lista de espera: acesso antecipado, preço de usuário fundador e um lugar na primeira fila enquanto a gente constrói.

Entrar na lista de espera