Un Customer Success Qualified Lead (CSQL) est une opportunité d’expansion au sein d’un compte existant qu’un CSM a signalée comme prête pour une conversation commerciale — un upsell, un cross-sell, un ajout de sièges ou une montée de tier — et transmise à l’équipe revenue pour la clôturer. C’est l’équivalent CS-sourced d’un MQL : un lead qui a franchi un seuil défini et mérité un follow-up de sales. Le trait qui le définit est l’origine. Un CSQL provient de la relation après-vente — signaux d’usage, conversation de roadmap, nouveau stakeholder, besoin exprimé — et non d’une campagne marketing ou d’une séquence d’outbound d’un SDR.
Ce qu’un CSQL n’est pas
Un CSQL n’est pas un renouvellement. Le renouvellement, c’est le contrat de base qui continue ; un CSQL, c’est de l’ARR incrémental par-dessus. Confondre les deux laisse les équipes revendiquer du crédit d’expansion pour du revenue qui allait recur de toute façon.
Un CSQL n’est pas non plus un signal produit brut. Un pic d’utilisation des sièges est un input vers un CSQL, pas le CSQL lui-même. Le lead n’existe qu’une fois qu’un humain (le CSM) ou un modèle de scoring calibré a jugé le compte à la fois capable et disposé à acheter davantage, et a nommé la motion précise. « Ce compte est à 95 % des sièges sous licence » est un signal ; « ce compte a besoin de 40 sièges de plus avant sa vague d’onboarding du Q3 et le champion a confirmé le budget » est un CSQL.
Et un CSQL n’est ni un MQL ni un SQL. Un MQL est un contact qui a engagé avec le marketing ; un SQL est un prospect net-new que sales a accepté. Un CSQL est un client existant que l’organisation CS connaît par son nom. La preuve de qualification est une réalité opérationnelle, pas un remplissage de formulaire.
Les critères de qualification
Une définition de CSQL exploitable filtre sur trois choses, toutes requises :
- Un signal produit ou relationnel. Une utilisation des sièges au-dessus d’un seuil (couramment 80-90 % des sièges sous licence), un blocage sur un feature-gate, l’onboarding d’un nouveau département, un besoin exprimé en QBR, ou un nouveau stakeholder senior apparaissant sur le compte.
- Une santé de compte qui soutient l’expansion. Vendre davantage à un compte en mauvaise santé accélère le churn. Filtrez le CSQL sur un health score sain ou en amélioration, à jour de ses paiements, et sans escalade critique de support ouverte.
- Une motion nommée et un champion. Le CSM nomme ce qui est vendu (sièges, module, tier) et identifie qui, à l’intérieur du compte, le parrainera. Sans ces deux éléments, sales hérite d’une intuition, pas d’un lead.
Écrivez la définition et versionnez-la. Un CSQL qui signifie une chose pour CS et autre chose pour sales produit des bagarres d’attribution et un taux de conversion auquel personne ne croit.
Le handoff vers sales
Décidez qui clôture avant de générer le premier CSQL. Trois modèles courants : le CSM clôture directement les petites expansions (le plus rapide, mais ponctionne du temps de CSM sur la rétention) ; un Account Manager ou un AE d’expansion possède tout le CSQL-to-close (la séparation la plus nette) ; ou un hybride où le CSM clôture sous un seuil en dollars et route les deals plus gros. Choisissez-en un et instrumentez-le.
Le handoff lui-même est un enregistrement structuré, pas un message Slack. Capturez-le comme une étape dans le CRM ou une plateforme CS comme Gainsight ou Planhat : le signal qui l’a déclenché, la motion nommée, l’ARR attendu, le champion et un snapshot de santé. Définissez un SLA — le rep qui reçoit accepte ou rejette dans une fenêtre fixe (48-72 heures est typique) — et une taxonomie de raisons de rejet pour que CS apprenne quels CSQL convertissent et lesquels étaient prématurés.
Attribution
L’attribution des CSQL est l’endroit où le modèle gagne ou perd sa crédibilité. Suivez trois taux : CSQL-vers-accepté (sales a-t-il convenu que c’était réel), accepté-vers-closed-won, et l’ARR CSQL-sourced en part de l’ARR d’expansion total. Si CS reçoit le crédit de l’influence et sales celui de la clôture, le double comptage gonfle les deux chiffres ; convenez d’une seule règle sourced-versus-influenced en amont. La plupart des équipes créditent CS comme la source et le rep qui clôture du win, reportés sur des lignes séparées pour qu’aucune organisation ne manipule le chiffre de l’autre.
Pièges courants
- Définir le CSQL uniquement sur l’usage. Un seuil d’utilisation sans gate de santé et sans champion inonde sales de leads qui ne convertissent pas. Guard : les trois critères requis, à chaque fois.
- Pas de boucle de rejet. Sans taxonomie de raisons de rejet et sans chemin de feedback vers CS, le seuil ne se calibre jamais. Guard : faites de l’accept/reject avec une raison un champ requis du CRM, revu chaque mois.
- Compter les renouvellements comme des CSQL. Gonfle les métriques d’expansion et cache les comptes à plat. Guard : l’ARR CSQL est incrémental uniquement — la base de renouvellement est exclue par définition.
- Le temps de CSM grignoté par la clôture. Si les CSM possèdent la clôture, le travail de rétention en pâtit en silence. Guard : plafonnez les deals clôturés par les CSM en valeur dollar et routez le reste vers un AM.
Connexes
- NRR vs GRR — le pipeline de CSQL est ce qui alimente le terme d’expansion dans le NRR