Vou começar com uma cena que você provavelmente já viveu.
A reunião mensal com o cliente começa. O CSM abre a pauta com entusiasmo: “Vamos falar de adoção, de expansão, de resultados”. O cliente responde com uma lista. Não é uma lista de oportunidades — é uma lista de cobranças. A melhoria prometida há dois trimestres. O bug que já virou piada interna. A funcionalidade que o concorrente lançou e a gente não.
O CSM tenta conduzir, tenta trazer valor, tenta falar de roadmap. Mas não tem como. Quando o único assunto da relação é aquilo que a empresa não entregou, o relacionamento vira um balcão de reclamações, e o CSM vira o porteiro do problema.
E aí o churn estoura. Não por falta de esforço do CS. Por falta de gestão de prioridades em quem decide o que é entregue.
O diagnóstico: responsabilidade difusa
Vamos entender o problema antes de resolver. Na maioria das empresas, o backlog existe, mas ninguém é dono dele. Cada área puxa para o seu lado:
- O time de produto prioriza pelo que acha importante. Muitas vezes pelo que é tecnicamente mais interessante, não pelo que o cliente precisa.
- O comercial promete o que o cliente pediu na negociação, sem consultar se o produto consegue entregar.
- O suporte abre chamado atrás de chamado e cada chamado vira um “pedido” no backlog, sem critério.
- O CS fica no meio, tentando explicar para o cliente por que a promessa do comercial não virou release.
Exemplo prático: imagine a empresa fictícia “SaaSX”, um software de gestão para pequenas indústrias. O comercial vendeu para um cliente prometendo que “o relatório de custos por máquina sai no próximo trimestre”. O produto nunca aprovou essa funcionalidade, ela nem estava no roadmap. O cliente espera, cobra, e o CSM fica sem resposta. Três meses depois, o cliente assina com o concorrente, que tinha o relatório pronto.
O resultado desse cenário é sempre o mesmo:
- Melhorias prometidas que nunca saem
- Bugs que se arrastam por meses
- Lançamentos que chegam atrasados ou depois do concorrente
- Pedidos de cliente que nem recebem resposta
E o CSM, que deveria ser o guardião do relacionamento, vira refém da fila. Ele não consegue atuar porque o único assunto disponível é a dívida.
O problema não é falta de gente. É falta de clareza sobre quem decide o quê.
O framework: três cadeiras, três responsabilidades
A gestão do que é entregue passa por três papéis que precisam conversar. Cada um tem uma responsabilidade que não pode ser terceirizada:
Produto decide o quê e o quando. É do Product Manager a palavra final sobre o que entra no backlog e em qual release. Ele precisa ter critério, e não apenas opinião. É ele quem equilibra pedidos de cliente, visão de mercado, dívida técnica e estratégia.
Exemplo: na SaaSX, o PM recebeu três pedidos na mesma semana: o relatório de custos (pedido do comercial), uma integração com um ERP (pedido de um cliente grande) e a correção de um bug que derruba o sistema (pedido do suporte). Sem critério, ele atende quem grita mais alto. Com critério, ele classifica: o bug é urgente (derruba operação), a integração é estratégica (cliente grande em risco), o relatório é desejável (mas pode esperar).
CS decide o quanto isso importa para o cliente. O CSM não prioriza o backlog, mas é a principal fonte de sinal sobre o que o cliente sente. Ele traz o contexto: qual cliente está em risco, qual pedido é condição de renovação, qual bug está travando a operação do cliente.
Exemplo: o CSM da SaaSX sabe que o cliente “Metalúrgica Silva” está em negociação de renovação e que o relatório de custos é condição para assinar. Esse contexto precisa chegar ao PM com peso, não como “o cliente pediu”, mas como “sem isso, perdemos a conta”. O papel do CS é traduzir a voz do cliente em prioridade com peso, não em pedido solto.
PM/Suporte decide o como e o quando resolve. A gestão de bugs tem dono: um processo claro de triagem, SLA por severidade e comunicação ativa de status.
Exemplo: na SaaSX, um bug crítico (sistema fora do ar) tem SLA de 4 horas para resposta e 24 horas para correção. Um bug menor (botão com texto errado) tem SLA de 5 dias úteis. O cliente não precisa cobrar o CSM para saber o status, ele recebe atualização automática. Bug não é assunto de reunião de CS; é assunto de fluxo operacional.
A regra de ouro: cada um decide dentro da própria cadeira, e ninguém decide sozinho fora dela. O CS não vira PM, o PM não vira CS, e o comercial não promete o que o produto não aprovou.
MoSCoW aplicado a pedido de cliente
Aqui entra a ferramenta que resolve 80% das brigas de prioridade: o MoSCoW. Todo pedido de cliente que entra no backlog precisa ser classificado, e essa classificação é o contrato entre CS e Produto.
Vamos ver como funciona na prática, com os pedidos da SaaSX:
- Must: sem isso, o cliente não renova, não opera ou a conta está em risco. Exemplo: a correção do bug que derruba o sistema da Metalúrgica Silva. Não é desejo, é condição de negócio.
- Should: é importante, agrega valor real, mas tem workaround ou pode esperar um release. Exemplo: a integração com o ERP. O cliente opera hoje com planilha, mas a integração destravaria expansão.
- Could : seria bom ter, mas não muda a decisão do cliente. Exemplo: o relatório de custos por máquina. Nenhum cliente deixou de renovar por causa dele, ainda.
- Won’t: (por enquanto) está fora do escopo atual e precisa ser dito claramente, com motivo. Exemplo: um cliente pediu um app mobile. A SaaSX decidiu que não é prioridade neste ano. A resposta honesta: “não entra este ano, e o motivo é que estamos focados em X”.
O ponto que separa operações maduras de operações caóticas é o Won’t. Empresas que não sabem dizer “não” com transparência acumulam um backlog de promessas silenciosas, pedidos que nunca foram recusados, mas também nunca foram entregues. E promessa não respondida é pior do que recusa: ela vira ressentimento.
Exemplo: o cliente da SaaSX pediu o app mobile. Se a empresa nunca responde, o cliente assume que foi ignorado, e isso pesa na renovação. Se a empresa responde “não entra este ano, porque estamos focados em estabilidade e integrações”, o cliente pode discordar, mas entende. Respeito não é entregar tudo; é ser honesto sobre o que não será entregue.
Quando CS e Produto classificam juntos, o CSM ganha o que ele mais precisa para se relacionar: uma resposta honesta para dar ao cliente. “Não entra neste trimestre, e o motivo é este” preserva a relação muito mais do que “estamos avaliando” por seis meses.
As regras do jogo: ritos que impedem o CS de virar refém
Classificar pedido é o começo. O que sustenta é o rito. Sugiro três acordos mínimos:
1. SLA de resposta para pedido de cliente. Todo pedido registrado tem prazo para resposta, mesmo que a resposta seja “vai para o backlog com prioridade X”.
Exemplo: na SaaSX, todo pedido de cliente recebe resposta inicial em até 5 dias úteis. Pode ser “entra no backlog como Should, revisão no próximo comitê”. O cliente não fica no vácuo. Cliente não abandonado é cliente que ainda dá chance de renovação.
2. Cadência de priorização conjunta. Uma reunião quinzenal (ou mensal) entre CS e Produto para revisar o backlog com o filtro MoSCoW. O CS leva o contexto de risco das contas; o Produto leva o roadmap. A decisão sai registrada, com dono e data.
Exemplo: na reunião de priorização, o CSM apresenta: “A Metalúrgica Silva está em risco de renovação; o relatório de custos é condição”. O PM responde: “Se for Must, ele entra no release de outubro, e tiramos a integração do ERP para novembro”. Decisão registrada, comunicada ao cliente no dia seguinte. O cliente sabe o que esperar e para quando.
3. Roadmap como ferramenta de relacionamento. O CSM não pode descobrir lançamento pelo release note. Ele precisa do roadmap com antecedência para usar como alavanca de valor na conversa com o cliente, e para gerenciar expectativa antes que ela vire cobrança.
Exemplo: em vez de o CSM descobrir que a integração com o ERP saiu lendo o changelog, ele já sabia há um mês. Na reunião com o cliente, ele usa isso como pauta positiva: “no próximo mês sai a integração que vocês pediram”. O cliente sai da reunião falando de valor, não de dívida.
Plano de ação: por onde começar
Se a sua operação vive esse cenário, o caminho prático é:
- Mapeie a dívida. Liste tudo o que foi prometido a clientes e nunca entrou em release. Sem esse inventário, nenhuma priorização é honesta.
- Dê dono ao backlog. Uma pessoa responde pela fila e pelo critério. Sem dono, não há gestão.
- Classifique tudo com MoSCoW, incluindo os pedidos antigos. O que for Won’t precisa ser comunicado ao cliente, com motivo.
- Crie o SLA de resposta para pedidos de cliente, mesmo que comece simples: 5 dias úteis para resposta inicial.
- Estabeleça a cadência CS × Produto e registre as decisões.
- Devolva o CSM para o relacionamento. Com resposta honesta na mão e roadmap na agenda, ele volta a falar de valor, adoção e expansão, que é o trabalho dele.
Conclusão
O CSM não trava porque é ruim de relacionamento. Ele trava porque o sistema entrega para ele um assunto só: a dívida. Quando a empresa organiza quem decide o quê, produto decide o que entra, CS traduz o peso do cliente, e todo pedido tem resposta, o relacionamento volta a ser sobre o que a empresa faz, não sobre o que ela deve.
E é aí que o churn deixa de ser problema do CS e passa a ser, como deveria, problema de todo mundo.