Customer Success Qualified Lead (CSQL) とは、既存アカウント内の拡張機会のうち、CSM が商談の準備が整ったと判断し（アップセル、クロスセル、シート追加、ティアのアップグレードなど）、クロージングのために revenue チームへ引き渡したものを指します。これは MQL の CS-sourced 版です。つまり、定義された基準を満たし、sales のフォローアップに値すると認められたリードです。それを特徴づけるのは出自です。CSQL は販売後の関係から生まれます。利用シグナル、ロードマップの会話、新しいステークホルダー、表明されたニーズなどであり、マーケティングキャンペーンや SDR のアウトバウンドシーケンスからではありません。
CSQL ではないもの
CSQL は更新ではありません。更新はベースとなる契約が継続することであり、CSQL はその上に乗る増分の ARR です。両者を混同すると、チームはいずれにせよ recur する予定だった revenue に対して拡張のクレジットを主張できてしまいます。
CSQL は生のプロダクトシグナルでもありません。シート利用率の急上昇は CSQL への input であって、CSQL そのものではありません。リードが存在するのは、人間（CSM）または較正されたスコアリングモデルが、そのアカウントがより多く購入する能力と意欲の両方を持つと判断し、具体的な motion を名指ししたときだけです。「このアカウントはライセンスシートの 95% に達している」はシグナルであり、「このアカウントは Q3 のオンボーディングの波の前にあと 40 シート必要で、champion が予算を確認済み」が CSQL です。
そして CSQL は MQL でも SQL でもありません。MQL はマーケティングと engage したコンタクトであり、SQL は sales が受け入れた net-new の見込み客です。CSQL は CS 組織が名前で知っている既存顧客です。認定の証拠はフォーム入力ではなく、運用上の現実です。
認定基準
実用的な CSQL の定義は、いずれも必須の 3 つでゲートします。
- プロダクトまたは関係性のシグナル。 閾値を超えるシート利用率（一般的にはライセンスシートの 80-90%）、feature-gate へのヒット、新部門のオンボーディング、QBR で表明されたニーズ、またはアカウントに現れた新しいシニアのステークホルダー。
- 拡張を支えるアカウントの健全性。 健全でないアカウントにより多く売ることは churn を加速させます。CSQL を、健全または改善中の health score、支払いが最新、未解決の重大なサポートエスカレーションがないことでゲートします。
- 名指しされた motion と champion。 CSM は何が売られているか（シート、モジュール、ティア）を名指しし、アカウント内で誰がそれをスポンサーするかを特定します。この 2 つがなければ、sales が引き継ぐのはリードではなく勘です。
定義を書き下し、バージョン管理します。CS にとっての意味と sales にとっての意味が異なる CSQL は、アトリビューションの争いと、誰も信じないコンバージョン率を生みます。
sales への handoff
最初の CSQL を生成する前に、誰がクロージングするかを決めます。一般的な 3 つのモデル：CSM が小規模な拡張を直接クローズする（最速だが、CSM の時間を retention から奪う）。Account Manager または拡張担当の AE が CSQL-to-close のすべてを所有する（最もクリーンな分離）。あるいは、CSM がドル閾値未満をクローズし、より大きな deal をルーティングするハイブリッド。1 つを選び、計測します。
handoff そのものは Slack のメッセージではなく、構造化された記録です。CRM、または Gainsight や Planhat のような CS プラットフォームのステージとして記録します。トリガーとなったシグナル、名指しされた motion、想定 ARR、champion、そして健全性のスナップショットです。SLA を定義します。受け取る担当者は固定のウィンドウ内（48-72 時間が典型）に受諾または却下します。さらに却下理由の分類体系を用意し、CS がどの CSQL がコンバートし、どれが時期尚早だったかを学べるようにします。
アトリビューション
CSQL のアトリビューションは、モデルが信頼を得るか失うかの分かれ目です。3 つのレートをトラッキングします：CSQL-から-受諾（sales が本物だと同意したか）、受諾-から-closed-won、そして拡張 ARR 全体に占める CSQL-sourced ARR の割合です。CS が影響に対するクレジットを、sales がクローズに対するクレジットを受け取ると、二重カウントが両方の数字を膨らませます。sourced-versus-influenced のルールを事前に 1 つに合意してください。ほとんどのチームは CS を source として、クローズした担当者を win としてクレジットし、どちらの組織も相手の数字を操作できないよう別々の行で報告します。
よくある落とし穴
- CSQL を利用だけで定義する。 健全性のゲートも champion もない利用率の閾値は、コンバートしないリードで sales を溢れさせます。Guard：3 つの基準を毎回すべて必須にする。
- 却下ループがない。 却下理由の分類体系と CS への feedback の経路がなければ、基準は決して較正されません。Guard：理由付きの受諾/却下を CRM の必須フィールドにし、月次でレビューする。
- 更新を CSQL として数える。 拡張メトリクスを膨らませ、横ばいのアカウントを隠します。Guard：CSQL の ARR は増分のみ。更新のベースは定義上除外する。
- クロージングが CSM の時間を圧迫する。 CSM がクロージングを所有すると、retention の仕事が静かに犠牲になります。Guard：CSM がクローズする deal をドル価値で上限設定し、残りを AM にルーティングする。
関連
- NRR vs GRR — CSQL パイプラインは NRR の拡張項を動かすものです