GLOSSARY
SQL の基準を誰が決めるか
営業が案件として追うと決めたリード。基準はマーケが決めるものではなく、営業が受け取れる状態の定義を、両者で言葉にして揃えます。
決めるのは営業。ただしマーケが立ち会う
MQL はマーケが「渡してよい」と判断する線でした。SQL は逆で、営業が「案件として追う」と判断する線です。 したがって基準を決めるのは営業側です。
ただしマーケが席を外すと、基準が言葉にならないまま個人の感覚に残ります。マーケが立ち会う目的は、基準を決めることではなく、決まった基準を文章にすることです。
営業の「これは筋がいい」を、次のような形に翻訳します。
- 「筋がいい」→ 課題が特定できていて、時期が決まっている
- 「まだ早い」→ 情報収集の段階で、予算の話が出ていない
基準は「営業が受け取れる状態」で書く
属性（業種・規模・役職）だけでは SQL の基準になりません。属性は MQL の段階で使い切っています。SQL で見るのは状況です。
| 見るもの | 具体的に何が確認できていればよいか |
|---|---|
| 課題 | 何を解決したいかを、相手の言葉で言える |
| 時期 | いつまでに、という話が出ている |
| 予算 | 金額の桁が合っている。または調達の見通しがある |
| 決裁 | 誰が決めるかが分かっている |
「4つ全部」を必須にすると、SQL がほとんど出ません。 実務では「課題と時期が確認できていれば SQL」のように、2つ程度から始めて、受注率を見ながら足していきます。
基準を厳しくすると、何が起きるか
SQL の基準を厳しくすると、SQL の受注率は上がります。数字はきれいになります。
しかし受注の総数は増えません。 厳しくした分だけ SQL の数が減るためです。基準を動かして改善するのは「見え方」であって、成果ではありません。
補足
受注率だけを目標にすると、基準は際限なく厳しくなります。 「ほぼ決まっている案件だけを SQL にする」が最適解になってしまうためです。受注率と SQL の数は必ずセットで見ます。
差し戻しの経路を先に作る
SQL にしたあと「やはり違った」は必ず起きます。ここで戻せないと、追えない案件が営業のリストに溜まり続けます。
- 戻す先を決める（MQL に戻すのか、育成に回すのか）
- 戻した理由を選択肢で記録する
- 戻した件数を、基準の見直しに使う
理由が残っていれば、基準のどこが甘かったかが分かります。残っていなければ、次も同じ判断を繰り返します。
MQL と SQL の数が合わないとき
MQL は出ているのに SQL が出ない、という相談はよくあります。原因は3つに絞れます。
- MQL の基準が甘い。 属性で切れていない
- 渡したあと触れていない。 SAL を置くと切り分けられます
- SQL の基準が厳しい。 上で書いた「見え方の改善」が起きている
1と2は打ち手が正反対です。 どちらかを確かめずに MQL の基準を締めると、触れていないだけの状態を放置したまま、リードの数だけが減ります。