A maioria dos times de CS interpreta errado o churn. Será que você sabe analisar?
Um caso real de como decisões precipitadas podem pôr em risco o futuro do negócio.
Na edição de hoje vou contar uma história pessoal real sobre a importância de entender o contexto do negócio e saber enxergar as coisas com uma visão 360.
Todo mundo fala sobre a importância do CS - e até mesmo a empresa - tomar “decisões baseadas em dados”. O problema é: será que as pessoas estão prontas para isso?
Vou contar uma experiência real minha para ilustrar.
Contexto
Quando se fala em controle de churn em negócios SaaS (como o que eu faço parte), praticamente todo mundo sabe de duas coisas:
O churn costuma ser muito ligado ao onboarding: se o cliente ultrapassa a barreira da adoção, a chance do cliente sair é muito menor.
O churn de clientes menores costuma ser maior, por diversos fatores: volatilidade, sazonalidade, orçamento, etc.
Essas duas afirmações são fato em quase todos os negócios. Eu já analisei dados suficientes, de produtos diferentes, para poder afirmar isso.
Então, não é incomum times de CS fazendo análises que chegam às seguintes conclusões:
“50% do meu churn está concentrado em clientes até 1 ano”
“70% do meu churn é em clientes pequenos”
Logo, devemos parar de vender para clientes pequenos demais! Eles são um problema!
Calma. Essa análise é interessante, certo?
Mas o que exatamente essas duas informações me dizem, estatisticamente falando? A resposta é simples: quase nada. Mesmo as conclusões mais aparentemente simples, podem ser falhas:
Elas não dizem que clientes menores saem mais
Elas não dizem que clientes novos saem mais
Sabe porque? Falta uma referência.
Imagine que 70% dos seus clientes são pequenos. Se 50% dos seus churns vêm dos pequenos, então você deve ter um problema nos clientes grandes! A mesma lógica vale para o tempo de casa.
O nome disso é grupo de controle. Você precisa sempre comparar com uma referência para tirar suas conclusões. Isso é método científico.
Há diversas outras coisas que prejudicam as análises feitas pelos times de CS por aí, por exemplo a qualidade dos dados:
Dados faltantes
Problemas de preenchimento
Erros de digitação
Origem dos dados ruim
E pela falta de “perícia” nas análises, a maior parte das análises feitas são simplesmente… pouco significativas. E isso não é nem uma coisa só de times de CS. Falando bem a verdade pra vocês:
A maioria das análises feitas por profissionais de negócios está fundamentalmente errada.
Caso real
Quando eu comecei a cuidar do CS na minha empresa, eu ouvia muito falar sobre os problemas relacionados ao churn. Mas, logo de cara eu vi o quanto não adiantava analisar os dados naquela altura:
Os dados de churn eram registrados em uma planilha pelo CS e não eram validados em lugar nenhum
Não havia processo algum para captura de dados de uma forma mais estruturada
Não havia dado histórico de nada.
Não existia sequer uma regra de negócio que definisse com clareza o que era um cliente e o que era um churn. Pode parecer besteira, mas isso influencia MUITO no número. Duvida? Então responda:
Um cliente só é cliente se pagar? E clientes isentos? E se os clientes que ainda não começaram a pagar já têm contato com seu time e com o produto?
Um cliente é um CNPJ? Mas e os grupos econômicos? São um cliente só ou vários?
Quando o churn acontece? No momento do pedido de cancelamento? No momento da confirmação? No momento da desativação do sistema? No momento que o cliente para de pagar? E os clientes que voltam?
Havia um erro simples na conta do churn: o churn era calculado em relação à base de clientes do fim do mês, não do começo.
Quer ver como essas coisas importam? Vou mostrar:
Quando eu fui comparar a planilha de churn do CS com os dados do financeiro de licenças desativadas, o número era completamente diferente. Com o tempo, passamos a usar o dado do financeiro como dado real de cancelamento.
Eu não conseguia fazer uma boa análise de características ou motivos de churn, porque a planilha era uma aberração. Só pra tornar os dados analisáveis, já era uma catástrofe de erros de digitação e falta de padrão.
Fui analisar os dados de implantação e vi que tínhamos 16% de churn em implantação. Mas aí, descobri que 7% desses 16 vinham de clientes que sequer tinham pagado o primeiro boleto, mas já eram considerados no número porque caíam no pipe de implantação para agendamento de kickoff imediatamente após contrato assinado (e não boleto pago).
Sem dados históricos, eu não conseguia fazer nenhuma previsão baseada no comportamento passado.
Em um dos nossos produtos, o churn era registrado no momento da solicitação (esse método foi “herdado” de uma empresa adquirida), o que fazia com que não desse para comparar os churns dos diferentes produtos.
Agora alguns exemplos mais genéricos:
Imagine que você tem um cliente (um único empreendedor) que tem 4 negócios. Se esse cliente sair, ele é 1 logo churn ou 4? Isso pode mudar muito sua taxa de churn.
Agora pense se seu produto bloqueia o acesso de um cliente com 7 dias de atraso, se no 15º dia o cliente pagar e voltar a usar, ele deu churn ou não?
Enfim, detalhes assim são importantes de avaliar.
Você pode achar que não é tão importante assim, mas, se sua empresa resolver fechar um investimento ou for vendida e descobrirem que vocês reportaram 2% de churn, mas no due diligence (etapa onde são auditados os números) for descoberto que o churn real (financeiro) é 3%, isso pode por em risco o valor da sua empresa e até a concretização do negócio.
Então eu dediquei bastante tempo a definir essas regras de negócio, documentá-las e compartilhar com a companhia toda.
O que eu fiz:
Estruturei os processos
Criei todos dentro do Hubspot
Comecei a registrar histórico dos dados e acumular massas de dados para análises
Esse processo de “criar as bases” pra fazer boas análises durou uns bons 2 anos. Depois disso, as análises começaram a nascer.
As análises
Para fazer uma análise de churn excelente, você precisa de:
Pelo menos 24 meses de dados históricos de churn sobre a base de clientes (logo churn e churn rate, churn rate por recorte de clientes)
Uma “fotografia” da base de clientes em um determinado momento e algum tempo depois (idealmente 12 meses)
Um registro de TODOS os clientes que entraram em um determinado período, se estão ativos ou inativos e, em caso de churn, data da saída.
Com cada uma dessas massas de dados, você consegue:
Com o primeiro, você consegue projetar tendências futuras e analisar sazonalidades (será que seu churn é geralmente maior em janeiro? Em média quantos % maior?)
Com o segundo, você tem uma visão PERFEITA do Net Revenue Retention, comparando as duas fotografias e vendo qual a receita dos clientes remanescentes da primeira.
Com o terceiro, você consegue fazer:
Análise de cohort de churn e de receita
Levantar a curva de churn (como as imagens que mostrei lá em cima), o que te possibilita entender comportamento e estimar churn com uma precisão assustadora
Fazer análises de LTV/CAC por safra
Continuação da história real
No primeiro trimestre de 2023, depois de 1 ano colhendo os dados que eu precisava para começar a analisar o churn com maturidade, eu fiz minha primeira análise robusta.
Primeiro, eu fiz uma análise de Cohort de clientes, para entender a probabilidade de perder um cliente a cada mês de permanência dele. Dessa análise eu levantei o seguinte gráfico:
(Caso você não conheça, essa é a curva normal do início da vida de um cliente de SaaS)
Dessa análise, eu descobri algumas coisas:
Se meus clientes rompessem a barreira dos 10 meses, dificilmente eles sairiam.
Se eu conseguisse controlar meu churn dos primeiros 5 meses, o problema do churn seria muito menor.
Essa curva em clientes menores era muito maior: eu perdia a maioria dos clientes pequenos em até 6 meses.
Então, minha primeira conclusão foi:
“Não devemos vender mais para clientes pequenos, não faz sentido! É muito custo para perder a maioria”
Mas aí, eu resolvi olhar pra coisa de outro aspecto: do LTV/CAC. Resolvi levantar o mesmo cohort, mas com dados reais de receita e comparando com o investimento feito em marketing. Aqui estão algumas imagens das análises da época:
O que eu descobri foi:
A perda de receita era muito menor que a de clientes. Primeiro pelo perfil dos clientes menores saindo, mas também porque os clientes cresciam muito em receita.
O LTV pagava o CAC em TODOS os recortes: apesar dos clientes pequenos saírem muito, os que ficavam, ficavam para sempre (e pagavam, inclusive, pelos que saíram).
E aí, eu fui olhar para o pipeline do comercial. Lá eu vi duas coisas:
A maioria dos clientes entrantes eram pequenos. Nosso sistema, na maioria das vezes, era o primeiro software do cliente.
Tínhamos uma conversão muito baixa em clientes de concorrentes.
Aí, com a visão do todo, eu me dei conta:
Parar de vender para clientes pequenos poderia ser a decisão mais idiota do mundo.
Duvida? Vou explicar:
Os clientes pequenos são rentáveis no longo prazo. Se a gente resolvesse parar de vender para eles, não existia garantia nenhuma de que conseguiríamos vender para clientes maiores.
Tentar vender para esses clientes poderia ocasionar uma queda na conversão do time comercial e um aumento drástico do CAC (já que esses clientes precisariam de mais tempo do comercial e da implantação, além do esforço de marketing “jogando fora” os leads pequenos).
O nosso mercado é relativamente pequeno (com aproximadamente 20 mil clientes possíveis), mas se “recicla” rapidamente. Então, tentar penetrar em clientes consolidados pode ser muito mais difícil do que pegar o cliente no começo da jornada e ajudá-lo a prosperar (crescendo junto com o software).
Logo, tentar restringir a venda para clientes pequenos poderia ser extremamente arriscado. Um tiro no pé que colocaria o negócio inteiro em risco.
Basicamente, estávamos enxergando o problema errado.
O problema não era os clientes pequenos.
O problema era o custo para trazê-los e mantê-los.
Se conseguíssemos baixar o custo de aquisição e manutenção desses clientes e encontrássemos uma forma de trazê-los para dentro de forma barata e escalável, isso melhoraria ainda mais a relação LTV/CAC. E se ainda tivéssemos iniciativas que ajudassem esse cliente a prosperar e crescer.
Então, o plano de ação foi:
Tornar o CS mais barato
Melhorar as iniciativas educacionais de formação
Melhorar o processo de onboarding para aumentar a taxa de sucesso dos primeiros 6 meses
E futuramente encontrar formas de capturar esses clientes sem necessidade do comercial.
Feito isso, vale ACELERAR a venda para clientes pequenos, não diminuir.
As melhorias em relação ao onboarding, por exemplo, fizeram com que a curva de perda de clientes reduzisse. E eu consegui chegar a essa conclusão COMPARANDO com períodos anteriores (usando, inclusive, a mesma época do ano):
Então, tome cuidado com as conclusões que você tira a partir das suas análises diárias, elas podem conduzir a decisões precipitadas, ou simplesmente erradas.
Garanta que:
Seus dados são bons
Que a metodologia está correta
Que a análise tem volume de dados suficiente (amostragem relevante)
Que você não está sendo tendencioso(a)
Que a análise tem relevância estatística.
Caso você se interesse por esse tipo de assunto e queira se aprofundar mais, eu recomendo bastante que você comece a aprender um pouco mais sobre estatística.
Para isso, aqui vão alguns livros que recomendo.
Básico:
Como mentir com estatística (um clássico, uma delícia de ler. Li inteiro em uma tarde, não consegui parar. Engraçado, interessante, ótimo para começar)
Estatística: O que é, para que serve, como funciona (esse é quase uma “homenagem” ao primeiro, mas tende a ser um pouquinho mais técnico)
Storytelling com dados: esse é mais sobre visualizações de dados (gráficos mesmo). Este livro vai te ensinar porque você deve matar gráficos de pizza ou 3D.
Intermediário:
Estatística Prática Para Cientistas de Dados: 50 Conceitos Essenciais (minha mais nova aquisição, este aqui traz ferramentas práticas realmente)
Avançado:
Data Science para Negócios: este livro não é para iniciantes. Eu me travei nele várias vezes até conseguir engrenar. Curiosidade: eu gosto tanto de dados que eu ganhei esse livro de aniversário de um amigo.
Mãos à Obra: Aprendizado de Máquina com Scikit-Learn, Keras & TensorFlow: livro beeeem prático e bem avançado em programação de algoritmos de Machine Learning. Ele dá vários exemplos de código reaproveitáveis, inclusive de churn.
Você é genial, sério!