O churn foi decidido três sinais atrás

O email de renovação volta com um educado “decidimos seguir outro caminho”, e todo mundo age surpreso. Ninguém deveria. A conta não decidiu sair naquela manhã. Decidiu três semanas antes, quando os logins diários despencaram, o thread de suporte ficou frio e cortado, e um champion que costumava responder em minutos ficou quieto. Os sinais estavam todos lá. Só estavam em três ferramentas diferentes, e nenhum humano os estava lendo juntos.

Esse é o problema inteiro em uma frase. Churn raramente é surpresa. Só parece uma porque o aviso estava distribuído por sistemas que não conversam.

A conta não morre na renovação. Morre três sinais atrás, e a única pergunta que importa é se alguém estava observando quando aconteceu.

Este post é sobre o papel operacional que faz o observar: aquele que correlaciona a queda de uso, a mudança de sentimento, e o pico de tickets numa única trava, com a razão de ter disparado e a jogada a rodar, antes da renovação, não depois.

A versão ingênua: um dashboard que ninguém abre na hora certa

A resposta óbvia para “nossos clientes estão saudáveis?” é um dashboard de health-score. Você já viu. Uma coluna de contas, um ponto colorido ao lado de cada uma, verde-amarelo-vermelho, ordenado por um número que alguém computou de logins e adoção de features. Parece a resposta.

Não é, por uma razão que não tem nada a ver com a matemática.

Um dashboard é um lugar aonde você vai. Ele espera você abri-lo, e você o abre quando lembra, o que é praticamente nunca na terça que importa. O ponto vermelho estava vermelho na terça. Você olhou na sexta, depois do cancelamento. O score estava certo; o timing foi fatal. Pior, o score é geralmente construído de um stream só, uso de produto, porque esse é o stream que é fácil de canalizar num número. Então a conta onde o uso parece bem mas os três últimos tickets de suporte estavam furiosos aparece verde, e você confia no verde, e a perde mesmo assim.

Deixe-me nomear as duas falhas claramente, porque são diferentes. A primeira é que um dashboard é reativo: ele segura a verdade mas nunca a entrega para você, então você descobre indo até ele depois do fato. A segunda é que um score de sinal único é cego: uso sozinho perde a conta que ainda está logando por hábito enquanto sua paciência se esgota na fila de suporte. Um ponto verde numa conta morrendo não é um erro pequeno. É o tipo mais caro, porque te diz para relaxar.

O gargalo nunca foi computar o score. Era que o score ficava numa caixa, alimentado por um cano, esperando ser visitado.

No que “customer health” de fato se decompõe

Tire o dashboard e pergunte o que um customer-success person afiado de fato está fazendo na cabeça quando sente uma conta indo de lado. Ele não está lendo um número. Está correlacionando três streams que cada um conta um terço da história.

Uso é o sinal comportamental: eles ainda estão no produto, fazendo a coisa para a qual o produto serve? Uma queda aqui significa que o hábito está quebrando. Sentimento é o sinal emocional: como a última rodada de conversa soa, as respostas de suporte, o tom da reunião, o email que costumava terminar com “obrigado!” e agora termina com um ponto final. Uma mudança aqui significa que a boa vontade está drenando. Tickets são o sinal de atrito: quantos problemas, quão severos, resolvidos quão rápido? Um pico aqui significa que o produto está ativamente custando esforço a eles.

Qualquer um desses, sozinho, mente. Uso cai numa semana de feriado e nada está errado. Um único email seco é só uma terça corrida. Um ticket é um ticket. A inteligência não está em nenhum stream único, está na conjunção. Uso caindo e sentimento azedando e tickets disparando, na mesma conta, nas mesmas duas semanas, não são três coincidências. É um cliente indo embora em câmera lenta.

Então o trabalho real não é “computar um health score”. O trabalho é: observar três streams continuamente, notar quando se curvam juntos, e no momento em que se curvam, falar, a uma pessoa, com a razão e a jogada.

O papel operacional: uma vigília que fala primeiro

Aqui está a virada, e é a mesma virada que separa um chatbot de um colega de trabalho: quem se move primeiro.

Um dashboard espera ser perguntado. O papel que estamos descrevendo não pergunta nada. Ele roda continuamente, segura os três streams num lugar só, e quando a conjunção dispara, ele abre a conversa, do jeito que um bom account manager se inclinaria e diria “ei, estou preocupado com esta aqui”. Ele não substitui o julgamento do humano sobre o que fazer. Substitui a parte em que o humano é estruturalmente ruim: notar, através de três ferramentas, no momento em que importa, toda vez, para cada conta, sem cansar.

A versão de automação ingênua disso é um alerta de threshold. “Me avise quando o uso cair 40%.” Razoável, até você conviver com ele. Alertas de threshold único são ou altos demais ou quietos demais. Configure sensível e cada semana de feriado te soterra em alarmes falsos até você silenciar o canal. Configure estrito e eles só disparam depois que a conta já se foi. Um threshold num stream não consegue distinguir entre um cliente de férias e um cliente a caminho da saída, porque a diferença não está na magnitude de uma queda. Está em se os outros dois streams se moveram com ela.

A conjunção é o que torna a trava confiável. Uma quedinha de uso com sentimento estável e zero tickets é provavelmente férias, fique quieto. Uma quedinha de uso com um último email frio e dois tickets escalados é um incêndio, fale agora. O mesmo número de uso significa coisas opostas dependendo da companhia que mantém. É por isso que isto tem que ser uma vigília que raciocina sobre a conjunção, não um gatilho ligado a uma única métrica.

E quando ela fala, não pode só dizer “Conta X está em risco”. Uma trava nua é um palpite que te entregam e mandam confiar. Ela tem que carregar duas coisas que um número nunca carrega: a razão e a jogada.

A razão é metade do produto

Imagine que a trava chegue assim. Não “Conta X: health 41, vermelho”. E sim: “Esta conta está em risco. Os logins estão acentuadamente em queda ao longo de duas semanas depois de rodar estáveis o trimestre todo. Os dois últimos threads de suporte escalaram e ficaram sem resolução por dias. O tom na resposta mais recente ficou seco, frases curtas, sem assinatura, nada do calor de antes na relação. A renovação é em cerca de cinco semanas.”

Leia isso e note o que acabou de acontecer. Você não tem que ir verificar o alarme. O alarme se verificou. Ele nomeou os três streams, te disse para que lado cada um se curvou, e os conectou à data que torna isso urgente. Você pode discordar, talvez você saiba que o champion acabou de ter um bebê e a secura não tem relação, mas agora você está discordando com evidência, não com um ponto colorido.

Esta é a parte que scores de sinal único nunca conseguem. Um número comprime a história inteira em um dígito e joga fora a razão. A razão é o valor, porque a razão é o que te diz qual jogada rodar.

Porque a jogada depende inteiramente do porquê. Uma conta em risco por um pico de tickets precisa de um engenheiro e um pedido de desculpas, o produto está machucando-os. Uma conta em risco por uma queda de uso sem tickets precisa de re-onboarding, eles não estão recebendo valor, talvez esqueceram como. Uma conta azedando no tom antes de uma renovação precisa da relação humana, uma ligação de verdade de uma pessoa de verdade, não outro nudge in-app. Mesma trava vermelha, três respostas completamente diferentes. Um score que só diz “vermelho” te manda cego. Uma trava que diz por que está vermelho te entrega a jogada antes de você pedir.

Por que isto tem que morar no company brain, não numa ferramenta de CS

Você poderia imaginar parafusar isto numa plataforma de customer success. Seria uma melhoria real, e ainda bateria numa parede, porque os três streams não moram todos na ferramenta de CS.

Uso mora no analytics de produto. Sentimento mora na inbox de suporte e nas notas de reunião e nos threads de email. Tickets moram no helpdesk. A data de renovação mora num contrato numa pasta em algum lugar, ou no sistema de billing, ou numa nota de vendas de nove meses atrás. Para correlacioná-los, você precisa de um sistema que já leia através de tudo isso, que segure o comportamento de produto do cliente, suas conversas, seu histórico de suporte, e suas datas de contrato numa memória contínua, e observe essa memória em busca da conjunção.

Isso não é uma feature que você adiciona a um dashboard. É uma propriedade do substrato sobre o qual a coisa toda roda. A razão de a Apollo conseguir observar customer health é a mesma razão de conseguir fazer qualquer trabalho cruzando cantos: não é uma ferramenta que você consulta, é um sistema operacional para a empresa que já tem a inbox, o calendário, o histórico de relações, e os documentos num lugar só. A vigília é só uma das coisas que você consegue erguer sobre um brain que não esquece e não espera ser perguntado. Suponha que os streams já estivessem unificados e já sendo lidos, então “sinalize a conta em risco, com a razão e a jogada, antes da renovação” para de ser um projeto de integração e vira uma instrução.

A parte difícil nunca foi o alerta. A parte difícil era ter os três streams numa mente só ao mesmo tempo, continuamente, para que a conjunção seja sequer visível.

A virada: pare de descobrir na renovação

Aqui está a parte que não é sobre software.

Agora, na maioria das empresas, alguém descobre que uma conta está infeliz quando o cancelamento aterrissa, ou, se tiver sorte e for diligente, quando um account manager heroico por acaso lembra de checar três ferramentas na terça certa. Essa diligência parece o trabalho. Na verdade é um imposto sobre a pessoa mais habilidosa em relações que você tem, gastando sua atenção em notar em vez de na coisa que só ela consegue: tomar a decisão, ter a conversa, salvar o cliente.

O ponto de uma vigília que fala primeiro não é substituir essa pessoa. É devolver a atenção dela. Deixe o sistema fazer a parte em que é bom, ler três streams através de cada conta, todo dia, sem perder uma, para que o humano faça a parte que só um humano consegue: entrar na conversa de risco já sabendo o que está errado e o que tentar, enquanto ainda há tempo de tentar.

Um cliente que você salva na semana um da queda é uma renovação. O mesmo cliente que você descobre na renovação é um postmortem. A diferença entre esses dois desfechos nunca foi um modelo mais esperto ou um dashboard mais bonito. Era se alguém estava observando os três sinais quando se curvaram juntos, e se a vigília falou primeiro.

---

É isso que estamos construindo na Apollo Space, não mais uma coluna de health-score que você lembra de checar no dia errado, mas uma vigília que lê o uso, o tom, e os tickets juntos e diz a uma pessoa de verdade, esta, agora, aqui está por quê, aqui está a jogada. A conta que te deixou na terça já estava saindo em março. A única coisa que muda o final é quem estava observando em março.