Um modelo de maturidade do cliente é um mapa por estágios de quão profundamente uma conta usa o seu produto — tipicamente crawl, walk, run — que um time de CS usa para definir a próxima ação certa de cada cliente e para cronometrar a expansão. Não é um health score (o health diz o risco agora; a maturidade diz quão longe a conta chegou rumo ao valor total) e não é o mesmo que o customer journey (o journey é a sequência de momentos do ciclo de vida; a maturidade é a profundidade de adoção dentro deles). O modelo existe para responder uma pergunta sobre cada conta do book: qual é a única coisa de maior impacto que este cliente deveria fazer a seguir?
O framework crawl / walk / run
Defina cada estágio por comportamento observável do produto e um outcome que o cliente alcançou — não por há quanto tempo ele é cliente. O tempo é um proxy fraco; uma conta de seis meses travada em uma feature é menos madura que uma conta de seis semanas que usa o workflow central diariamente.
- Crawl — onboardada e no ar. O cliente completou o setup, o admin principal faz login e pelo menos um workflow central roda com sucesso. A amplitude de adoção é uma ou duas features; o uso é superficial e conduzido pelo admin. O trabalho de CS aqui é o time-to-first-value: leve a conta ao seu primeiro outcome real, não à amplitude de features.
- Walk — adotada em um time. O workflow central é habitual para um time ou caso de uso. O uso ativo semanal é constante, uma segunda feature está em jogo e o cliente consegue descrever o valor com as próprias palavras. O trabalho de CS é aprofundar e documentar o outcome para que ele sobreviva a uma troca de champion, e depois encontrar o próximo time.
- Run — incorporada e em expansão. Múltiplos times ou casos de uso dependem do produto, o uso é diário entre os papéis e a conta o trata como infraestrutura. O trabalho de CS muda de adoção para expansão e advocacy: novos seats, novos módulos, renovação plurianual, referências.
Calibrando os portões de estágio
Estágios genéricos são enchimento. Calibre cada portão com dois ou três thresholds mensuráveis que você consiga puxar do product analytics (Pendo, Amplitude) ou da sua plataforma de CS (Gainsight, Vitally, Planhat). Um exemplo trabalhado para uma ferramenta de colaboração:
| Estágio | Amplitude (features adotadas) | Profundidade (WAU / seats licenciados) | Outcome alcançado |
|---|---|---|---|
| Crawl | 1-2 de 6 features centrais | menos de 20% | primeiro projeto entregue |
| Walk | 3-4 de 6 | 20-50% | um time usa semanalmente |
| Run | 5-6 de 6 | mais de 50% | 2+ times, citado nos docs de processo deles |
Escolha os thresholds dos seus próprios dados: pegue a sua cohort de melhor retenção e maior NRR, veja qual amplitude e profundidade ela atingiu antes de expandir, e fixe o portão de Run logo abaixo disso. Os portões são específicos do produto — copiar os números de outra empresa anula o propósito.
Usar a maturidade para impulsionar a expansão
A maturidade é uma regra de roteamento para plays, não um dashboard de vaidade. Mapeie cada estágio para o único play que move a conta para frente:
- Contas Crawl recebem um play de adoção, nunca um upsell. Vender seats para uma conta que não alcançou o first value é como você fabrica churn — ela compra mais de algo que ainda não usa, e depois ambas as renovações falham. Guard: a motion de expansão fica desabilitada para qualquer conta abaixo do portão de Walk.
- Contas Walk recebem um play de aprofundar e aterrissar um segundo time. É aqui que o pipeline de expansão é criado, não fechado — uma conta Walk que adiciona um segundo time está se graduando sozinha para Run.
- Contas Run recebem o play de expansão. A dependência multi-time mais uma profundidade acima de 50% é o sinal de expansão mais forte que você tem; correlaciona com o NRR muito melhor que o tempo de casa ou o valor do contrato. Cronometre a conversa de upsell para o momento em que uma conta cruza o portão de Run, não para o calendário de renovação.
O benefício composto: a maturidade dá ao RevOps um pipeline de expansão previsível. A contagem de contas no portão de Walk neste trimestre é um indicador antecedente de contas elegíveis para expansão no próximo trimestre.
Erros comuns
- Confundir maturidade com health. Uma conta em estágio Run pode estar não saudável (o champion acabou de sair) e uma conta Crawl pode estar perfeitamente saudável (no caminho, só cedo). Guard: acompanhe os dois, e nunca deixe um estágio de maturidade alto suprimir um alerta de risco de churn.
- Estágios baseados em tempo. “90 dias = Walk” não é um modelo de maturidade; é um calendário. Guard: cada portão é definido por um threshold de produto ou um outcome, nunca só por tempo decorrido.
- Portões sem rebaixamento. As contas regridem — um reorg mata o champion, o uso cai. Guard: recalcule o estágio na mesma cadência do health (semanal é típico) para que uma conta que cai abaixo do threshold de profundidade de Walk volte e reentre no play de adoção.
- Fazer upsell em contas Crawl. Coberto acima; é o erro mais caro que o modelo foi desenhado para prevenir.
Quando o framework quebra
Três estágios são grossos demais para produtos com uma superfície de adoção longa (uma plataforma com vinte módulos precisa de sub-estágios dentro do Run) e finos demais para produtos transacionais ou de uma única feature onde “no ar” é o único estado significativo. Calibre o número de estágios à sua superfície de adoção, não à convenção crawl/walk/run. Para pricing baseado em uso, a maturidade e a receita se movem juntas automaticamente, então o play de expansão é menos sobre uma motion de vendas e mais sobre remover fricção do uso mais profundo.
Relacionados
- NRR vs GRR — as métricas de retenção que a maturidade busca mover
- Gainsight — plataforma de CS para scorear e estagiar contas
- Vitally — plataforma de CS conduzida por uso do produto
- Pendo — product analytics para calibrar os portões de estágio