Por que os clientes de SaaS realmente cancelam (e como descobrir)

Aqui está uma frase que um verdadeiro testador disse durante um fluxo de cancelamento.

"o preço é honestamente o problema todo para nós, somos uma equipa de três e o próximo nível custa mais do que todo o nosso orçamento de ferramentas para o trimestre."

Agora aqui está o que um menu suspenso teria registado da mesma pessoa. Too expensive. Duas palavras, uma linha numa folha de cálculo, e todos os detalhes acionáveis desaparecidos.

A frase não é uma reclamação sobre o seu preço. É uma reclamação sobre o tamanho do salto entre dois dos seus níveis, de alguém que é três pessoas e não se encaixa no nível acima. Isso é um problema da página de preços. A resposta do menu suspenso, "too expensive", aponta para um desconto em vez disso, que é a correção errada e uma cara. Mesmo cliente, mesmo código de razão, conclusões opostas.

Este artigo está organizado em torno das sete categorias de razões que Outro classifica como cancelamentos. A taxonomia é deliberadamente pequena e fixa, porque um conjunto pequeno e fixo é o que torna a contagem possível. O argumento é que as categorias só se tornam úteis quando algo por baixo delas preserva a frase que o cliente realmente disse.

As sete razões, e o que cada uma realmente esconde

Outro classifica cada cancelamento em uma das sete razões. O conjunto não muda e você não o configura.

• Too expensive : o cliente está lhe dizendo algo sobre o preço, mas quase nunca sobre o número absoluto. Geralmente é a diferença entre os níveis, um orçamento que foi cortado, ou um preço que parecia bom até o uso cair. Registrado como uma categoria, parece um problema. Registrado como uma frase, divide-se em três, com três responsáveis diferentes.
• Missing features : a palavra crucial é quais. Uma integração ausente que bloqueou todo um fluxo de trabalho é uma decisão de roteiro. Um recurso desejável que surgiu uma vez é ruído. A categoria trata-os de forma idêntica.
• Not using it : ninguém foi prejudicado pelo seu produto, eles simplesmente nunca o incorporaram na sua rotina semanal. Esta é a razão pela qual um cliente tem menos incentivo para se voluntariar e mais incentivo para relatar como "too expensive", já que pagar por algo que você nunca abre realmente parece caro demais.
• Too hard to use : fricção que impediu o cliente antes que o valor o fizesse. Configuração, um conceito na sua interface que não corresponde ao conceito na cabeça deles. Distinto de "not using it" porque aqui eles tentaram.
• Technical issues : bugs, interrupções, coisas que quebraram a confiança. A categoria mais corrigível e a que mais vale a pena ler literalmente, porque você precisa do caminho de reprodução e não da contagem.
• Switching : eles foram para outro lugar. A categoria é quase inútil por si só. Para onde eles foram e o que os atraiu é todo o sinal.
• Other : nenhuma razão clara de produto, incluindo uma resposta ininteligível ou algo genuinamente fora das outras seis, como o fechamento do negócio. Uma taxonomia sem esse balde é pior do que uma com ele, porque um classificador forçado a escolher arquivará o ruído sob qualquer razão real que menos se encaixe mal.

Os valores subjacentes são armazenados como identificadores em vez dos rótulos exibidos acima, e nem sempre são lidos da mesma forma que o rótulo. O conjunto completo é too_expensive, missing_features, not_using, too_complex, technical_issues, switching e other, então "Too hard to use" chega como too_complex e "Not using it" como not_using. Vale a pena saber antes de construir um relatório em uma exportação CSV.

Observe que quatro das seis razões reais podem plausivelmente ser relatadas pelo cliente como a primeira. Essa assimetria é todo o problema com menus suspensos, e prevê que uma pesquisa de caixa de seleção tenderá para o preço por razões que têm muito pouco a ver com o seu preço.

Porque "too expensive" absorve tudo o resto

Um menu suspenso pede ao cliente para fazer um trabalho de tradução em seu nome. Eles têm uma situação específica, e você lhes dá cinco categorias predefinidas e pede que escolham a mais próxima. Isso é um passo de compressão com perda, e o cliente não está motivado a fazê-lo cuidadosamente, porque está a sair.

A categoria que escolhem é a socialmente aceitável. Dizer "too expensive" não custa nada ao cliente, pois não implica crítica ao produto, não admite que nunca chegaram a configurá-lo, e não há obrigação de explicar. Compare isso com clicar em "too hard to use", que soa como uma acusação, ou "not using it", que soa como uma admissão. Dada uma escolha livre, as pessoas evitam as opções embaraçosas.

Assim, "too expensive" absorve silenciosamente pelo menos três casos não relacionados, incluindo "I never set it up", "the one feature I needed was missing", e "my budget got cut". Esses três exigem respostas completamente diferentes de você. Agrupados numa categoria, eles resultam numa recomendação para baixar o preço, que é a única ação que não ajuda nenhum deles.

A página de cancelamento da Outro mantém os botões de rádio e adiciona a opção de voz ao lado deles, o que é um compromisso deliberado em vez de uma postura purista. Os botões dão-lhe uma categoria para cada cancelamento, incluindo de clientes que não falarão. A resposta de voz dá-lhe a frase por trás da categoria para aqueles que o farão.

Mecanicamente, é uma pergunta falada curta no lugar do botão de cancelamento. A resposta é transcrita e classificada à medida que chega, e uma oferta correspondente aparece antes que o cancelamento seja concluído. A gravação é transcrita em tempo real em vez de mantida como um ficheiro de áudio reproduzível, embora a transcrição e a análise derivada dela sejam armazenadas como qualquer outro registo de cliente, e a página mostra a linha "Your voice will be transcribed by AI" antes da gravação. Essa linha de consentimento é fixa e não configurável, o que é o padrão correto para algo que captura a voz de um cliente no momento menos generoso da relação. Para uma visão mais ampla do formato, veja Entrevistas de saída com IA.

Como as razões se apresentam como saída real

Abaixo está o painel "Needs attention" de uma execução ao vivo. Cada resumo nele foi gerado a partir de uma resposta falada real.

Leia os três resumos como instâncias da taxonomia em vez de como prosa.

"O utilizador expressa preocupação sobre o preço ser um problema significativo para a sua pequena equipa" é o resumo gerado a partir da frase falada no início deste artigo. Enquadra-se na categoria de preço e traz o qualificador que importa, que é para a sua pequena equipa. Um menu suspenso teria dado a categoria com o qualificador eliminado.

"O utilizador encontrou um bug com o dashboard que não carrega e uma resposta lenta do suporte, afetando a sua confiança" é um caso de technical issues que nomeia duas falhas separadas. Uma é um bug, outra é um problema de latência do suporte, e pertencem a pessoas diferentes na sua equipa. Um único código de razão teria forçado o cliente a descartar uma.

"O utilizador experimentou confusão durante a configuração e teve dificuldades com a incorporação de widgets e configuração de ofertas" é um caso de too-hard-to-use associado a uma etapa específica. Não "o produto é confuso", mas confusão durante a configuração, especificamente em torno da incorporação e configuração de ofertas. Esse é um ticket que pode abrir esta tarde.

Nenhum dos três poderia ter sido reconstruído a partir de uma caixa de seleção, e todos os três são a diferença entre conhecer a sua taxa de churn e saber o que mudar.

A classificação de razões e a classificação de feedback são duas coisas diferentes

Isto confunde as pessoas, por isso mantenha as duas separadas. A Outro executa dois sistemas de classificação independentes sobre cada resposta.

O primeiro é a taxonomia de churn de sete valores acima, que responde por que a subscrição terminou. O segundo é uma classificação de feedback, abrangendo Relatório de bug, Pedido de funcionalidade, Elogio, Pergunta e Outro, que responde que tipo de mensagem é esta. Além disso, cada resposta carrega um sentimento de Positivo, Neutro ou Negativo.

Os dois sistemas não se fundem. Um Relatório de bug combina naturalmente com problemas técnicos, mas pode igualmente encaixar-se em "not_using" quando o bug é a razão pela qual pararam de abrir o produto há dois meses. Um Pedido de funcionalidade pode chegar anexado a uma razão de preço, já que "o nível que tem o que eu preciso custa demasiado" é genuinamente ambos.

A tabela de Respostas Recentes é onde os dois sistemas estão lado a lado. Analise as etiquetas de sentimento e classificação juntas em vez de uma de cada vez, porque as combinações são mais informativas do que qualquer coluna isolada. Um Pedido de funcionalidade com sentimento Neutro é uma entrada para o roteiro. O mesmo pedido com sentimento Negativo é um cliente que se sentiu ignorado, o que é uma conversa diferente e muitas vezes recuperável.

Os temas transformam as categorias numa lista de prioridades

As categorias indicam como a rotatividade se distribui. Os temas dizem-lhe o que fazer na segunda-feira. A Outro extrai temas através das respostas e conta-os.

Estes são os números reais dessa execução, com cancelamento em 7, preços em 6, custo em 3, orçamento em 2, tamanho da equipa em 2, qualidade do produto em 2, missing features em 2, e feedback do utilizador em 2.

Seja claro sobre o que isto é e não é. Isto são dezasseis respostas numa conta de teste, nove faladas e sete digitadas. As contagens são reais e a extração de temas é real, mas dezasseis respostas não podem dizer-lhe se as reclamações sobre preços estão a aumentar, e um gráfico desenhará alegremente uma linha de tendência confiante através delas de qualquer forma. Dizê-lo claramente é mais útil do que a linha de tendência, e se estiver a avaliar qualquer ferramenta de rotatividade, o tamanho da amostra é a reivindicação a pressionar mais fortemente.

O que as contagens demonstram é o mecanismo. Preços, custo, orçamento e tamanho da equipa aparecem como quatro temas separados em vez de um. Um menu suspenso teria fundido todos os quatro em "too expensive". Separados, eles lêem-se como uma história coerente sobre pequenas equipas a enfrentar um salto acentuado de nível, que é exatamente o que a frase falada original disse. Os temas recuperaram a estrutura que a categoria destruiu. Uma vez que tenha isso, reduzir a rotatividade torna-se uma lista ordenada de correções em vez de um palpite, e pode atribuir números ao valor de cada correção com a calculadora de rotatividade.

Correspondência da oferta com o motivo em vez do clique

Conhecer o motivo durante o cancelamento, em vez de uma semana depois num relatório, significa que a oferta pode responder a ele. Na execução acima, a oferta apresentada após a objeção ao preço foi "50% de desconto por 3 meses".

Duas coisas a notar nesse ecrã. A oferta aparece antes de o cancelamento ser concluído, enquanto a intenção de sair ainda é suave. E "Não obrigado, cancelar mesmo assim" permanece visível e claro. Qualquer aumento que obtenha ao esconder a saída volta como chargebacks, carga de suporte e reclamações públicas. Exemplos de fluxo de cancelamento cobre onde essa linha se situa na prática.

A recuperação é contada de forma conservadora. Um salvamento só conta após um período de graça de 14 dias ter passado e apenas se a subscrição ainda estiver ativa nesse ponto. Um cliente que aceita um desconto e cancela uma semana depois não é um salvamento, e o número não finge o contrário. A alternativa, contar o clique na oferta, produz uma taxa de salvamento que parece impressionante e não prevê nada.

A categoria de churn que nenhum fluxo de cancelamento pode ver

Há uma sétima razão, e ela está fora da taxonomia completamente porque nunca chega ao fluxo. O churn involuntário é a subscrição que termina porque um cartão expirou, um pagamento falhou, ou um banco recusou uma cobrança. O cliente não decidiu sair. Eles nunca clicaram em cancelar, então nunca viram uma página de cancelamento, nunca responderam a uma pergunta, e nunca apareceram em nenhuma das capturas de tela acima.

Outro não aborda isso. Não faz recuperação de pagamento falhado e não faz dunning. Isso é um limite rígido, não um item de roteiro para ler nas entrelinhas. Se o churn involuntário é o seu problema, a solução pertence à camada de faturamento, e as ferramentas de recuperação de receita do Stripe são o lugar certo para procurar. Resolva isso separadamente, e não deixe uma ferramenta de churn voluntário convencê-lo de que seu churn é compreendido quando uma parte dele nunca entrou no fluxo.

Erros comuns

• Ler a distribuição de razões como a verdade : se a distribuição vem de um menu suspenso, o preço é exagerado por construção. Trate isso como uma medida de qual etiqueta foi menos constrangedora de clicar, não de por que as pessoas saíram.
• Descontar em resposta a uma categoria de preço : a frase falada neste artigo parece um caso de desconto e é, na verdade, um caso de estrutura de níveis. Leia algumas respostas verbatim antes de alterar um preço.
• Confundir razão de churn com tipo de feedback : Relatório de bug não é o mesmo que technical issues, e os dois sistemas respondem a perguntas diferentes, então colapsá-los em um só elimina sinais.
• Tirar conclusões de tendências com dados escassos : dezesseis respostas são uma demonstração de mecanismo, não uma tendência. Espere por volume real antes de agir com base na forma de um gráfico, incluindo os gráficos acima.
• Contar o clique na oferta como uma retenção : sem uma janela de graça e uma verificação de subscrição ativa, uma taxa de retenção mede cliques em botões em vez de receita retida.
• Esconder o link de cancelamento para aumentar a taxa de retenção : isso converte um cancelamento em um estorno e uma reclamação, e é a maneira mais rápida de tornar o fluxo de cancelamento uma responsabilidade.
• Esperar que um fluxo de cancelamento cubra churn involuntário : pagamentos falhados precisam de novas tentativas do lado da faturação, e nenhuma entrevista de saída jamais os verá.
• Escrever uma pesquisa com mais de um punhado de opções : cada opção extra adiciona uma etapa de tradução para o cliente e um grupo no qual você nunca agirá. As templates de perguntas de pesquisa de saída são mais curtas do que a maioria das equipas espera por esta razão.

Obter as respostas do painel de controlo

Uma restrição prática a considerar. O egress do Outro hoje é um email de resumo semanal que chega na segunda-feira, além da exportação CSV. Não há API REST pública, webhooks, pacote npm, conector Zapier, n8n ou Make, e nenhuma integração com Slack.

Isso molda o fluxo de trabalho. Não pode canalizar um cancelamento para o seu próprio sistema de alertas ou distribuir respostas para um canal Slack automaticamente. O que pode fazer é ler o resumo de segunda-feira como um ponto de agenda permanente e extrair o CSV quando quiser cruzar respostas com os seus próprios dados de faturação. Para uma pequena equipa, isso geralmente é suficiente. Se o seu processo depende de automação orientada por eventos, saiba disso agora em vez de depois de ter desenhado o seu sistema em torno disso.

Onde isto o deixa

As categorias não são a perceção, são o índice. O seu trabalho é tornar os cancelamentos contáveis, e contar é genuinamente útil, uma vez que não se pode priorizar o que não se pode comparar. Mas cada uma das seis é um recipiente para várias situações diferentes, e "too expensive" é a maior e mais enganadora delas. O trabalho consiste em manter a frase ligada à categoria, para que, quando o balde de preços se encher, possa perceber se está a olhar para um problema de desconto, um problema de estrutura de níveis, um problema de integração, ou um cliente cujo orçamento foi cortado por alguém que nunca usou o seu produto.

Outro é um software de fluxo de cancelamento com entrevistas de saída por voz, criado para faturação SaaS self-service no Stripe ou Lemon Squeezy. Substitui o botão de cancelamento por uma curta pergunta falada, transcreve e classifica a razão, e mostra uma oferta de retenção correspondente antes que o cancelamento seja concluído. Existe um plano gratuito a $0, depois o Starter a $29 por mês, o Pro a $79, e o Scale a $199. Todas as capturas de ecrã neste artigo são saídas reais do produto em vez de maquetes, incluindo as contagens de temas e o aviso de um único dia que as acompanha.