Descontinuação de Funcionalidades: Como Retirar Funcionalidades Sem Perder os Clientes que Dependem Delas

Eis o cenário que transforma uma decisão de produto simples em uma crise de retenção: uma funcionalidade utilizada por 4% das contas, mas da qual três dos seus dez maiores clientes dependem. O Produto decide descontinuá-la. O custo de manutenção é desproporcional ao uso, uma capacidade mais recente faz mais sentido arquitetonicamente, e 96% das contas não vão perceber a ausência. A decisão faz sentido no papel.

Então o aviso de 30 dias é enviado. O CS descobre na mesma semana que os clientes. Os clientes que dependem da funcionalidade não são os 4% de usuários ocasionais. São aqueles que construíram fluxos de trabalho em torno dela, treinaram suas equipes com ela e, em alguns casos, a integraram via API. São também aqueles cujo ARR representa um percentual significativo da sua carteira de renovações. Eles escalam. O Customer Success (CS) está atendendo chamadas sem linguagem aprovada, sem um playbook de migração e sem entender quando a decisão foi tomada ou por quê. Este é um caso exemplar de gestão de clientes em risco. As contas com maior probabilidade de rotatividade após uma descontinuação são exatamente aquelas que deveriam estar em uma lista de acompanhamento antes de o aviso ser enviado.

A rotatividade que se segue não é inevitável. É o resultado de uma falha de processo: o CS foi envolvido tarde demais.

Por que Funcionalidades São Descontinuadas e Por que Isso Importa para a Comunicação

A razão pela qual uma funcionalidade está sendo descontinuada determina como o CS deve enquadrar a conversa com os clientes. Errar na razão, ou usar uma explicação genérica, faz com que a comunicação pareça corporativa e desconectada da experiência real do cliente. O framework de retirada de produtos do Gartner usa os "6Ms" (mensagem, motivo, significado, mitigação, migração e método) exatamente porque cada razão para a descontinuação exige um enquadramento diferente nas seis dimensões.

Dívida técnica: a funcionalidade custa mais para manter do que o seu uso justifica. O enquadramento honesto é: "Estamos realocando os recursos de engenharia para construir capacidades que atendam mais clientes." Isso é defensável, e clientes que entendem a economia de produtos SaaS vão aceitar, desde que seja dito diretamente.

Mudança estratégica: o produto está indo em uma direção com a qual a funcionalidade não se encaixa. Os clientes podem perceber isso como o produto se afastando deles. O CS precisa ser capaz de explicar a direção estratégica em termos que o cliente valoriza: o que a mudança significa para as capacidades que eles mais usam? O que está sendo construído em substituição?

Consolidação: uma nova funcionalidade substitui duas antigas, mas a substituição não é de um para um. Este é o cenário mais perigoso para o CS, porque "construímos algo melhor" frequentemente não é verdade da perspectiva do cliente individualmente. Se a nova funcionalidade não atender ao caso de uso específico dele, a consolidação representa uma perda líquida. Seja honesto sobre isso.

Conformidade ou segurança: a funcionalidade tornou-se uma responsabilidade. Esta é a razão mais fácil de comunicar porque é externa, não uma preferência de produto, mas uma exigência. Os clientes entendem conformidade. Podem não gostar, mas vão aceitar uma explicação clara.

Cada uma dessas razões exige uma abertura diferente na conversa com o cliente. A linguagem genérica do tipo "estamos sempre melhorando" não serve a nenhuma delas. O padrão que produz os piores resultados, porém, não é apenas a mensagem errada. É o processo errado.

Fatos Relevantes: Descontinuação de Funcionalidades e Risco de Retenção

• 79% da rotatividade de clientes B2B SaaS relacionada à descontinuação de funcionalidades é evitável com o envolvimento antecipado do CS no processo de descontinuação, de acordo com a pesquisa de retenção de clientes da Gainsight.
• Empresas que notificam clientes sobre descontinuações com mais de 90 dias de antecedência registram taxas de rotatividade 3,2 vezes menores entre as contas afetadas em comparação com aquelas com aviso de 30 dias, segundo dados de benchmark da ChurnZero.
• Contas em janelas de renovação no momento de uma descontinuação têm 2,7 vezes maior probabilidade de rotatividade do que contas sem renovação iminente, a menos que recebam uma conversa proativa de migração com seu CSM, de acordo com a análise de retenção da Totango.

O Padrão de Desalinhamento

O padrão que produz os piores resultados de retenção é consistente entre empresas. É também um dos sinais de alerta em 8 sinais de desalinhamento CS-Produto: quando o CS é copiado em e-mails para clientes ao mesmo tempo que os próprios clientes os recebem, o relacionamento já está comprometido no nível do processo.

1. O Produto toma a decisão de descontinuação em uma reunião de roadmap, sem a contribuição do CS
2. Jurídico ou ops de produto redigem o aviso de descontinuação
3. O CS é copiado no e-mail quando ele é enviado aos clientes (simultaneamente, não antes)
4. Os CSMs recebem escalamentos de clientes sem linguagem aprovada e sem contexto de produto
5. As contas em risco não são identificadas até as conversas de renovação, que chegam com 30 a 90 dias de atraso
6. CSMs individuais negociam extensões informais ou soluções alternativas que criam precedentes que ninguém pretendia estabelecer

O processo correto inverte isso completamente: o CS é envolvido antes de a decisão de descontinuação ser finalizada, as contas em risco são identificadas antes de qualquer comunicação externa ser enviada, e os CSMs recebem orientação com linguagem aprovada antes da primeira conversa com o cliente.

Etapa 1: Identificar Quem Depende da Funcionalidade

Esta é a etapa que deve acontecer antes que o cronograma de descontinuação seja definido, não depois.

A distinção que importa é entre uso e dependência. Um cliente que usou uma funcionalidade uma vez no último ano é um usuário. Um cliente que construiu um fluxo de trabalho em torno dela, a utiliza em um processo repetível ou a integrou via API é dependente. Esses são perfis de risco completamente diferentes.

Dados de uso informam quem a tocou. Sua análise de produto pode mostrar quais contas usaram a funcionalidade nos últimos 90 dias, a frequência de uso e se o uso tem aumentado ou diminuído. Isso é necessário, mas não suficiente.

Dados de dependência informam quem não pode removê-la. O CS sabe coisas que os dados de produto não mostram: quais clientes mencionaram esta funcionalidade em QBRs, quais fizeram perguntas sobre ela em chamados de suporte, quais treinaram suas equipes com ela. Essa é a inteligência que o CS traz para a conversa de descontinuação que o Produto não possui apenas com métricas de uso.

O processo de contribuição do CS antes da descontinuação deve funcionar assim: o Produto compartilha o candidato à descontinuação com a liderança de CS. Os líderes de CS têm 5 a 7 dias úteis para revisar registros de clientes, notas de QBR e histórico de suporte, e retornam uma lista de contas classificada por risco. Nível 1 (alta dependência, alto ARR) requer contato pessoal proativo do CSM antes de qualquer e-mail ser enviado. Nível 2 (dependência moderada) recebe o e-mail de descontinuação com acompanhamento do CSM em até 48 horas. Nível 3 (baixa ou sem dependência) recebe o e-mail padrão de descontinuação. Conduzir uma revisão conjunta de contas em risco com Vendas antes de as comunicações de descontinuação serem enviadas ajuda a identificar quais contas de Nível 1 também têm conversas de expansão em andamento que precisam ser protegidas separadamente.

Essa classificação só funciona se o CS tiver acesso aos dados certos. A pontuação de impacto para o cliente formaliza esse processo construindo um framework repetível para quantificar quais contas estão mais expostas a qualquer mudança de produto, não apenas às descontinuações.

O que "dependência" significa na prática:

• A funcionalidade está referenciada nos critérios de sucesso documentados do cliente
• Ela foi mencionada em um QBR ou revisão de saúde nos últimos 12 meses
• Existe uma integração via API utilizando a funcionalidade
• O cliente abriu um chamado de suporte sobre ela nos últimos 90 dias
• A pontuação de saúde do CS do cliente tem alguma correlação com o uso desta funcionalidade

Etapa 2: Definir o Cronograma de Descontinuação

Quanto de prazo é suficiente? A resposta honesta é: depende de quão dependentes são as contas afetadas e de quão fácil é a migração. A pesquisa de prevenção de rotatividade do Gartner indica que 60% dos compradores de software que cancelam contratos o fazem por causa de uma decisão de compra da qual se arrependeram mais tarde, e migrações forçadas sem aviso adequado são um gatilho clássico para esse arrependimento.

Um framework inicial útil:

A tensão entre Produto e CS em relação ao cronograma é normal. O Produto quer avançar rápido: a dívida técnica tem um custo, e quanto mais tempo a funcionalidade depreciada fica ativa, mais esforço de engenharia ela consome. O CS quer mais tempo porque conversas de migração levam tempo, e forçar uma conta de alto ARR a uma migração acelerada cria risco de rotatividade.

A contribuição do CS na conversa sobre cronograma não é um veto. Mas é um sinal de risco obrigatório. O formato correto: "Aqui estão as três contas que acreditamos estar em maior risco de rotatividade com esta descontinuação, seu ARR, suas datas de renovação e nossa avaliação da dificuldade de migração. Com base nisso, recomendamos uma janela de 90 dias em vez de 30." Isso não é pedir mais tempo porque mudanças são difíceis. É fazer um caso de negócios com ARR anexado.

A distinção entre depreciação e corte definitivo também importa. Um aviso de depreciação diz: "Esta funcionalidade ficará indisponível após [data]." O corte definitivo é a data real de aplicação. Para contas de alta dependência, considere se o aviso de depreciação e o corte definitivo precisam ser separados por mais do que o período padrão de aviso. Algumas empresas oferecem a contas empresariais uma extensão negociada, mas isso precisa ser tratado com cuidado (veja os antipadrões abaixo).

Etapa 3: Comunicação, O Quê, Quando e Quem

Quem entrega a notícia:

Para contas de Nível 1 (alto ARR, alta dependência), o CSM entrega a notícia em uma conversa ao vivo: uma ligação dedicada, não um e-mail. O CSM liga para a conta, explica a situação, e o e-mail de descontinuação vem como confirmação escrita do que foi discutido. O cliente não deve ver o e-mail antes de falar com seu CSM.

Para contas de Nível 2, o e-mail de descontinuação vai primeiro, seguido de contato do CSM em até 48 horas. O trabalho do CSM nesse acompanhamento é entender o impacto e iniciar a conversa de migração.

Para contas de Nível 3, o e-mail de descontinuação é a comunicação principal. O CS trata as perguntas recebidas conforme chegam.

O que a mensagem inclui:

• A funcionalidade que será retirada, descrita com clareza (não apenas pelo nome interno)
• A razão, em linguagem simples (veja as quatro razões acima)
• A data efetiva, incluindo tanto a data do aviso de depreciação quanto a data do corte definitivo
• O que a substitui, se houver, com uma descrição honesta sobre se a substituição é equivalente
• Qual suporte de migração está disponível: documentação, sessões dedicadas, suporte de engenharia para migrações via API
• Com quem entrar em contato com dúvidas

O que a mensagem não inclui:

• Pedidos de desculpas que implicam que a decisão foi errada ("Lamentamos qualquer inconveniência que isso possa causar" sinaliza arrependimento pela decisão, não empatia pelo cliente)
• Cronogramas vagos ("em algum momento nos próximos meses" não dá ao cliente nada para planejar; eles merecem uma data específica)
• Alternativas não solicitadas que o cliente não pediu ("Você também poderia usar nossa nova ferramenta de relatórios!" parece uma tentativa de venda durante um anúncio negativo)
• Enquadramento de otimismo corporativo ("Estamos animados em simplificar nossa plataforma!" não soa bem quando os clientes estão sendo solicitados a mudar seus fluxos de trabalho)

Modelos de comunicação para três cenários:

Cenário A: Funcionalidade sendo retirada com substituto direto "[Nome da funcionalidade] será retirada em [data]. Construímos [substituto] para atender a mesma necessidade, e acreditamos que ela é uma base mais sólida para [caso de uso principal]. [Substituto] lida com [função específica] de [forma específica]. Preparamos documentação de migração e nossa equipe está disponível para sessões dedicadas de migração. Entre em contato com seu CSM para agendar uma."

Cenário B: Funcionalidade sendo retirada sem substituto direto "[Nome da funcionalidade] será retirada em [data]. Esta funcionalidade não está sendo substituída por um equivalente único. [Explicação honesta do motivo.] Com base em como sua equipe a utiliza, acreditamos que [solução alternativa ou abordagem] pode atender à sua necessidade central. Seu CSM entrará em contato esta semana para entender sua situação específica e garantir que você tenha um caminho a seguir."

Cenário C: Funcionalidade sendo retirada por conformidade ou segurança "[Nome da funcionalidade] será retirada em [data]. Esta decisão é exigida por [regulamentação/requisito de segurança] e afeta todos os clientes. Entendemos que isso requer ajustes da sua parte. [Caminho de migração]. Seu CSM entrará em contato para ajudá-lo a navegar pela transição."

Etapa 4: A Conversa de Migração

Quando existe uma funcionalidade substituta: não assuma que o substituto é melhor para cada cliente. Diga isso explicitamente: "A nova capacidade lida com [X] de forma diferente. Para a maioria dos clientes, isso é uma melhoria, mas quero entender seu fluxo de trabalho específico antes de falarmos sobre migração." Essa abordagem é mais honesta e produz melhores resultados de migração, porque você está identificando lacunas antes que o cliente as descubra. O playbook de estratégia de adoção de funcionalidades se aplica aqui. Migrar clientes para uma funcionalidade substituta requer a mesma abordagem estruturada de adoção que lançar uma nova, não apenas uma notificação única.

Quando não existe substituto direto: o CS pode oferecer três coisas: documentação de soluções alternativas, suporte de configuração customizada e visibilidade do roadmap sobre o que está sendo construído e que pode atender à necessidade subjacente no futuro. O que o CS não pode oferecer é uma promessa de que o substituto está chegando em breve, a menos que isso esteja factualmente confirmado no nível adequado.

Quando um cliente diz que o caminho de migração não funciona para o seu caso de uso: esta é uma conversa de Produto, não apenas de CS. O trabalho do CSM nesse momento é capturar a lacuna específica e escalá-la para o Produto: "Nosso cliente em [empresa] tem uma dependência de [capacidade específica] que o substituto não cobre. Aqui está o que eles precisam. Podemos ter uma ligação de 30 minutos com o PM para discutir?" Se o resultado é uma acomodação de produto, um cronograma negociado ou uma solução alternativa documentada é uma decisão do Produto. Mas o CSM é quem coloca isso diante das pessoas certas.

Etapa 5: Gestão do Risco de Retenção

A zona de risco: contas que são dependentes da funcionalidade a ser descontinuada e estão em uma janela de renovação. Essas contas precisam ouvir do seu CSM antes do aviso de depreciação ser enviado, e o CSM precisa de um plano de retenção para cada uma delas antes de qualquer comunicação externa. A educação do cliente é uma alavanca fundamental nesse plano. Guias de migração que abordam os pontos de confusão mais comuns reduzem significativamente os escalamentos de suporte durante uma janela de transição.

O plano de retenção não precisa ser complexo. Ele precisa responder: qual é o caminho de migração da conta, qual é o cronograma, quem no lado do CS é responsável por conduzi-la até a conclusão e qual é o escalamento se o cliente sinalizar que está considerando a descontinuação como razão para não renovar?

O que a liderança de CS apresenta ao Produto antes de qualquer descontinuação que afete contas de alto ARR:

Antes de uma descontinuação ser finalizada, a liderança de CS deve apresentar ao Produto: uma lista classificada das 10 contas mais afetadas por ARR, suas datas de renovação, seu nível de dependência e a dificuldade estimada de migração. Isso não é um pedido de veto. É uma apresentação de risco de negócio. A informação muda o cálculo de risco da equipe de Produto sobre o cronograma de descontinuação e se certas contas precisam de tratamento customizado.

Extensões negociadas: oferecer a uma conta específica de alto ARR mais tempo do que a janela padrão de aviso pode ser a decisão certa. Mas precisa ser gerenciado com cuidado. Uma extensão informal define um precedente que todas as outras contas afetadas descobrirão eventualmente. Se você estender para uma conta, decida em nível de liderança se a extensão está disponível para todas as contas de Nível 1 ou apenas para essa, e documente essa decisão.

Alimentar os resultados de retenção de volta ao Produto: após a conclusão da descontinuação, acompanhe o que aconteceu com as contas afetadas. Quantas migraram com sucesso? Quantas tiveram rotatividade? Quantas exigiram exceções ou negociações? Esses dados pertencem a uma retrospectiva com o Produto, e devem informar o processo para a próxima descontinuação, incluindo quanto prazo de aviso é adequado e com que antecedência a contribuição do CS precisa acontecer. A pesquisa da HBR sobre retenção de clientes argumenta que o custo de perder os clientes certos é quase sempre maior do que aparece nas métricas de rotatividade, tornando os dados de retenção pós-descontinuação um dos insumos mais subvalorizados no planejamento de produto.

Antipadrões

Esconder a descontinuação em notas de versão e torcer para que ninguém perceba. Alguns clientes podem não perceber por meses. Mas os clientes que dependem da funcionalidade vão perceber imediatamente, e vão se sentir surpreendidos porque não receberam aviso antecipado. Os clientes que não perceberam ficarão bem. Aqueles que perceberam e não foram avisados são o seu risco de rotatividade.

Oferecer uma solução alternativa customizada que o CS terá que suportar para sempre. Na conversa de migração, a tentação é resolver o problema imediato do cliente com uma solução alternativa que funciona apenas para o caso específico dele. Essa solução então se torna uma obrigação de suporte indefinidamente. Qualquer solução alternativa que o CS oferecer em uma migração de descontinuação deve ser revisada pelo Produto quanto à escalabilidade. Se exigir esforço contínuo do CS para ser mantida, não é uma solução alternativa, é uma acomodação permanente que ninguém concordou em fazer.

Conceder extensões informais de prazo a clientes empresariais que estabelecem precedentes. "Vamos mantê-la ativa para vocês até o final do ano do contrato," dito informalmente por um CSM em uma ligação de retenção, cria uma obrigação que o Produto não concordou, que a engenharia tem que manter e que outros clientes eventualmente vão descobrir e solicitar para si mesmos. Extensões devem passar pela liderança de CS e ter aprovação explícita do Produto.

Enquadrar a descontinuação como "novidade animadora" no e-mail de comunicação. Clientes que estão sendo solicitados a mudar seus fluxos de trabalho não estão animados. Linguagem como "estamos entusiasmados em avançar nossa plataforma retirando [funcionalidade]" sinaliza uma desconexão entre como o fornecedor vê a mudança e como o cliente a experimenta. Seja direto. A notícia é o que é.

O Checklist Conjunto CS-Produto para Descontinuação

Antes da decisão de descontinuação ser finalizada:

• O CS revisou os dados de uso e retornou uma avaliação de risco de dependência para as contas afetadas
• As contas na janela de renovação foram identificadas e sinalizadas
• A liderança de CS apresentou ao Produto as contas de maior risco por ARR
• O cronograma de descontinuação foi definido com a contribuição do CS sobre a dificuldade de migração

Antes de a comunicação externa ser enviada:

• As contas de Nível 1 foram contactadas por seu CSM em conversa ao vivo
• Os modelos de comunicação aprovados estão prontos e revisados pelo Produto e pelo Jurídico
• O briefing dos CSMs foi concluído: cada CSM conhece a razão da descontinuação, o caminho de migração e a linguagem aprovada
• O caminho de escalamento está definido para contas que recusam o caminho de migração

Durante a janela de migração:

• Check-in semanal entre CS e Produto sobre o progresso da migração das contas de Nível 1
• Qualquer lacuna de produto identificada nas conversas de migração foi escalada para o Produto
• Solicitações de extensão de contas empresariais foram revisadas pela liderança de CS e obtiveram aprovação explícita do Produto

Após a conclusão da descontinuação:

• Os resultados de retenção de todas as contas afetadas foram documentados
• Uma retrospectiva foi realizada com CS e Produto para capturar o que funcionou e o que não funcionou
• As melhorias de processo para futuras descontinuações foram acordadas e documentadas

A questão de quem é responsável pelas mudanças visíveis ao cliente e notas de versão conecta-se diretamente a este checklist. A clareza sobre a responsabilidade pelas entregas de comunicação é o que faz cada etapa ser executada no prazo em vez de cair na lacuna entre CS e Produto. E para contas onde a descontinuação está expondo um padrão mais amplo de necessidades não atendidas, o processo de fechamento do ciclo de feedback é onde esses insights vão para produzir uma melhoria permanente na forma como as decisões de produto são tomadas.

O Playbook de Descontinuação em 5 Etapas

O Playbook de Descontinuação em 5 Etapas nomeia as cinco fases de um processo conjunto CS-Produto para retirada de funcionalidades. As etapas correm em sequência, e pular qualquer uma delas é a fonte mais comum de rotatividade evitável por descontinuação.

Etapa 1: Identificação de dependência. Antes de o cronograma de descontinuação ser definido, o CS revisa os dados de uso e os registros de clientes para distinguir usuários de dependentes. Retorna uma lista de contas classificada por risco: Nível 1 (alta dependência, alto ARR), Nível 2 (dependência moderada), Nível 3 (baixa ou sem dependência). Esta etapa deve acontecer antes que a comunicação externa seja planejada.

Etapa 2: Definição do cronograma. CS e Produto concordam com a janela de aviso usando a matriz dependência-migração (30 dias para migrações fáceis de baixa dependência; 90 a 120 dias para contas de alta dependência integradas via API; 120+ dias com cronogramas negociados para dependências críticas de fluxo de trabalho). A contribuição do CS não é um veto. É um sinal de risco com ARR anexado.

Etapa 3: Projeto da comunicação. Três modelos distintos para três cenários (substituto existe, sem substituto, descontinuação por conformidade). As contas de Nível 1 recebem uma ligação ao vivo do CSM antes de qualquer e-mail ser enviado. As contas de Nível 2 recebem o e-mail seguido de contato do CSM em até 48 horas. As contas de Nível 3 recebem o e-mail padrão. Os modelos são revisados pelo Produto e pelo Jurídico antes que qualquer cliente os veja.

Etapa 4: Conversas de migração. Suporte de migração conta a conta, com um caminho claro de escalamento quando o caminho de migração não cobre o caso de uso específico do cliente. Qualquer solução alternativa oferecida deve ser revisada pelo Produto quanto à escalabilidade antes de se tornar uma obrigação permanente de suporte.

Etapa 5: Acompanhamento de retenção e retrospectiva. Pós-descontinuação: documente quantas contas afetadas migraram com sucesso, tiveram rotatividade ou exigiram exceções negociadas. Realize uma retrospectiva com CS e Produto. Alimente os resultados de volta para o processo da próxima descontinuação.

Análise Rework: A falha de processo mais consistente nas descontinuações de funcionalidades não é o modelo de comunicação ou o período de aviso. É a Etapa 1. Empresas que pulam a etapa de identificação de dependência tratam todas as contas afetadas da mesma forma, o que significa que contas de alto ARR integradas via API recebem o mesmo e-mail de 30 dias que usuários ocasionais recebem. Os dados sobre isso são claros: empresas que notificam clientes com mais de 90 dias de antecedência registram taxas de rotatividade 3,2 vezes menores entre contas afetadas em comparação com aquelas com aviso de 30 dias (dados de benchmark da ChurnZero). Mas o prazo de aviso é apenas parte do resultado. As contas que recebem uma ligação proativa ao vivo de seu CSM antes de o e-mail chegar têm resultados de retenção significativamente melhores do que aquelas que recebem o e-mail primeiro, independentemente do prazo de aviso. É a Etapa 1 que indica quais contas precisam da ligação. Sem ela, toda conta recebe o e-mail.

Perguntas Frequentes

O que é o Playbook de Descontinuação em 5 Etapas?

O Playbook de Descontinuação em 5 Etapas é um processo conjunto CS-Produto para retirar funcionalidades sem perder as contas que dependem delas. As cinco etapas são: identificação de dependência (antes de o cronograma ser definido), definição do cronograma (com contribuição do CS sobre a dificuldade de migração), projeto da comunicação (três modelos, por nível de dependência da conta), conversas de migração (com caminho claro de escalamento para lacunas) e acompanhamento de retenção com retrospectiva pós-descontinuação. Organizações que usam um processo formal de descontinuação com corresponsabilidade CS-Produto relatam 44% melhores resultados de retenção entre contas afetadas do que aquelas que usam comunicação ad hoc, segundo dados de experiência do cliente da TSIA.

Quanto de prazo os clientes devem receber antes de uma funcionalidade ser retirada?

O prazo de aviso deve corresponder ao nível de dependência e à dificuldade de migração. O mínimo é 30 dias para funcionalidades de baixa dependência com migrações fáceis. Contas de alta dependência (aquelas com integrações via API ou uso crítico ao fluxo de trabalho) precisam de 90 a 120 dias. Contas com processos de negócio críticos construídos em torno da funcionalidade podem precisar de 120+ dias e um cronograma negociado. Empresas que notificam clientes com mais de 90 dias de antecedência registram taxas de rotatividade 3,2 vezes menores entre contas afetadas em comparação com aquelas com aviso de 30 dias, segundo dados de benchmark da ChurnZero. A forma mais confiável de definir o prazo certo é concluir a etapa de identificação de dependência antes de o cronograma ser finalizado.

Por que a maioria dos processos de descontinuação produz rotatividade?

A maioria da rotatividade por descontinuação é evitável e resulta de uma única falha estrutural: o CS é envolvido ao mesmo tempo que os clientes são notificados, ou depois. Apenas 38% das equipes de produto formalmente envolvem o CS antes de finalizar um cronograma de descontinuação, de acordo com o estudo Estado do Gerenciamento de Produto da ProductBoard. Quando o CS descobre a descontinuação na mesma semana que os clientes, os CSMs não têm linguagem aprovada, nenhum playbook de migração e nenhuma forma de identificar quais contas estão em maior risco antes que a primeira ligação de escalamento chegue. O Playbook de Descontinuação em 5 Etapas inverte isso: o CS é envolvido antes de a decisão ser finalizada, as contas classificadas por risco são identificadas antes de qualquer comunicação externa ser enviada e os CSMs recebem briefing antes de qualquer conversa com cliente acontecer.

Qual é a diferença entre um usuário e um dependente para fins de descontinuação?

Um usuário é qualquer conta que tocou na funcionalidade nos últimos 90 dias. Um dependente é uma conta que construiu um fluxo de trabalho em torno dela, a utiliza em um processo repetível ou a integrou via API. Esses são perfis de risco completamente diferentes para uma descontinuação. As análises de produto identificam usuários; o conhecimento do CS identifica dependentes. Os marcadores de dependência são: a funcionalidade aparece nos critérios de sucesso documentados, a conta a mencionou em um QBR nos últimos 12 meses, existe uma integração via API usando-a ou há um chamado de suporte sobre ela nos últimos 90 dias. A etapa de identificação de dependência combina ambas as fontes de dados para produzir a lista de contas classificada por risco.

Como os CSMs devem comunicar uma descontinuação a contas de alto ARR?

Para contas de Nível 1 (alto ARR, alta dependência), o CSM entrega a notícia em uma conversa ao vivo antes do e-mail de depreciação ser enviado. O cliente não deve ver o e-mail antes de falar com seu CSM. A conversa aborda: o que está sendo retirado e quando, a razão em linguagem simples, o que o substitui (se houver, com uma avaliação honesta de se o substituto é equivalente) e qual suporte de migração está disponível. O e-mail de acompanhamento serve como confirmação escrita do que foi discutido. Essa sequência (ligação ao vivo primeiro, e-mail depois) é o que separa uma descontinuação gerenciada de uma notificação em crise.

O que o CS deve fazer quando um cliente diz que o caminho de migração não funciona para seu caso de uso?

Escalar para o Produto imediatamente com detalhes: a empresa, o ARR, a capacidade específica que o substituto não cobre e o que o cliente precisa. Não prometa uma acomodação de produto ou um cronograma. Essas são decisões do Produto. O trabalho do CSM é colocar as pessoas certas na conversa antes que o cliente tome uma decisão de renovação com base em um problema que o CS não pode resolver sozinho. Qualquer solução alternativa que o CS oferecer em uma conversa de migração deve ser revisada pelo Produto quanto à escalabilidade: se exigir esforço contínuo do CS para ser mantida, não é uma solução alternativa, é uma acomodação permanente que ninguém formalmente concordou.

Saiba Mais

• Como o CS Comunica o Roadmap Sem Fazer Promessas Excessivas
• Fechamento do Ciclo de Feedback com Clientes
• Quem É Responsável pelas Mudanças Visíveis ao Cliente (Notas de Versão, In-App)
• O Problema "Construímos, Ninguém Usa"
• Pontuação de Impacto para o Cliente em Decisões de Produto
• Gestão de Clientes em Risco
• Revisão Conjunta de Contas em Risco
• Estratégia de Adoção de Funcionalidades