Um Customer Success Qualified Lead (CSQL) é uma oportunidade de expansão dentro de uma conta existente que um CSM sinalizou como pronta para uma conversa comercial — um upsell, cross-sell, adição de assentos ou upgrade de tier — e entregou ao time de revenue para fechar. É o equivalente CS-sourced de um MQL: um lead que passou de um critério definido e ganhou um follow-up de sales. O traço que o define é a origem. Um CSQL vem da relação pós-venda — sinais de uso, uma conversa de roadmap, um novo stakeholder, uma necessidade declarada — não de uma campanha de marketing nem de uma sequência de outbound de um SDR.
O que um CSQL não é
Um CSQL não é uma renovação. A renovação é o contrato base continuando; um CSQL é ARR incremental por cima disso. Confundir os dois deixa os times reivindicarem crédito de expansão por revenue que já ia recorrer de qualquer forma.
Um CSQL também não é um sinal de produto cru. Um pico na utilização de assentos é um input para um CSQL, não o CSQL em si. O lead existe apenas quando um humano (o CSM) ou um modelo de scoring calibrado julgou a conta tanto capaz quanto disposta a comprar mais, e nomeou a motion específica. “Esta conta está em 95% dos assentos licenciados” é um sinal; “esta conta precisa de mais 40 assentos antes da onda de onboarding do Q3 e o champion confirmou orçamento” é um CSQL.
E um CSQL não é um MQL nem um SQL. Um MQL é um contato que engajou com marketing; um SQL é um prospect net-new que sales aceitou. Um CSQL é um cliente existente que a organização de CS conhece pelo nome. A evidência de qualificação é realidade operacional, não preenchimento de formulários.
Os critérios de qualificação
Uma definição de CSQL funcional filtra por três coisas, todas obrigatórias:
- Um sinal de produto ou de relacionamento. Utilização de assentos acima de um limite (comumente 80-90% dos assentos licenciados), uma batida contra um feature-gate, o onboarding de um novo departamento, uma necessidade declarada num QBR, ou um novo stakeholder sênior aparecendo na conta.
- Saúde de conta que sustenta a expansão. Vender mais para uma conta sem saúde acelera o churn. Filtre o CSQL por um health score saudável ou melhorando, em dia com pagamentos, e sem escalonamento crítico de suporte aberto.
- Uma motion nomeada e um champion. O CSM nomeia o que está sendo vendido (assentos, módulo, tier) e identifica quem dentro da conta vai patrociná-la. Sem esses dois, sales herda um palpite, não um lead.
Escreva a definição e versione-a. Um CSQL que significa algo diferente para CS do que para sales produz brigas de atribuição e uma taxa de conversão na qual ninguém confia.
O handoff para sales
Decida quem fecha antes de gerar o primeiro CSQL. Três modelos comuns: o CSM fecha expansões pequenas diretamente (o mais rápido, mas tira tempo de CSM da retenção); um Account Manager ou um AE de expansão é dono de todo o CSQL-to-close (a separação mais limpa); ou um híbrido onde o CSM fecha abaixo de um limite em dólares e roteia os deals maiores. Escolha um e instrumente-o.
O handoff em si é um registro estruturado, não uma mensagem de Slack. Capture-o como um estágio no CRM ou numa plataforma de CS como Gainsight ou Planhat: o sinal que o disparou, a motion nomeada, o ARR esperado, o champion e um snapshot de saúde. Defina um SLA — o rep que recebe aceita ou rejeita dentro de uma janela fixa (48-72 horas é o típico) — e uma taxonomia de razões de rejeição para que CS aprenda quais CSQLs convertem e quais foram prematuros.
Atribuição
A atribuição de CSQL é onde o modelo ganha ou perde confiança. Acompanhe três taxas: CSQL-para-aceito (sales concordou que era real?), aceito-para-closed-won, e ARR CSQL-sourced como fração do ARR total de expansão. Se CS recebe crédito por influência e sales pelo fechamento, a contagem dupla infla ambos os números; combine uma única regra de sourced-versus-influenced de antemão. A maioria dos times credita CS como a fonte e o rep que fecha com o win, reportados em linhas separadas para que nenhuma organização manipule o número da outra.
Erros comuns
- Definir o CSQL só por uso. Um limite de utilização sem gate de saúde e sem champion inunda sales com leads que não convertem. Guard: os três critérios obrigatórios, sempre.
- Sem loop de rejeição. Sem uma taxonomia de razões de rejeição e um caminho de feedback de volta para CS, o critério nunca se calibra. Guard: torne aceitar/rejeitar com razão um campo obrigatório do CRM, revisado mensalmente.
- Contar renovações como CSQLs. Infla as métricas de expansão e esconde contas estagnadas. Guard: o ARR de CSQL é só incremental — a base de renovação é excluída por definição.
- Tempo de CSM tomado pelo fechamento. Se os CSM são donos do fechamento, o trabalho de retenção sofre em silêncio. Guard: limite os deals fechados por CSM por valor em dólares e roteie o resto para um AM.
Relacionados
- NRR vs GRR — o pipeline de CSQL é o que impulsiona o termo de expansão no NRR