SAL を置くべきか、置かなくてよいか

置く目的は「受け取った」を記録すること

MQL と SQL の間に段階を1つ挟むのが SAL です。挟む理由は分類を細かくするためではありません。渡したのに何も起きていない状態を、可視化するためです。

MQL と SQL しかないと、次の2つが同じ「SQL になっていない」に見えます。

• 営業が接触したが、案件にならなかった
• 営業がまだ接触していない

前者は基準の問題、後者は運用の問題で、打ち手がまったく違います。SAL はこの2つを分けます。

置いたほうがよいのは、こういうとき

• マーケと営業が別の組織で、渡したあとの動きが見えない
• インサイドセールスがいる。MQL → IS → 営業と手が変わる
• 「リードの質が低い」と「リードを触れていない」のどちらなのかが分からない

3つ目が本命です。この議論は多くの会社で起きますが、SAL がないとどちらの主張も裏付けられません。

置かなくてよいのは、こういうとき

• 同じ人がマーケも営業もやっている。 渡す相手がいないので、記録する意味がありません
• リードが月に数十件で、全件に接触している。 取りこぼしが構造的に起きない
• 段階を増やしても、入力する人がいない

SAL と SQL の間で何を確認するか

SAL は「受け取った」だけを表します。そこから SQL に進めるかの判断で見るのは、次の4つです。

4つ全部を SAL の時点で揃える必要はありません。 SQL に進めるときに揃っていればよく、SAL は「確認を始めた」地点です。

運用で決めておくこと

• 受け取ってから接触するまでの期限。 これがないと SAL が滞留します
• 差し戻しの理由の選択肢。 自由記述にすると集計できず、基準の改善に使えません
• 誰が SAL にするか。 営業本人か、システムの自動更新か。両方を許すと入力が揺れます

期限は「3営業日以内」のような形で置きます。守られているかを見ること自体が、SAL を置いた効果になります。

段階を増やす前に

SAL・SQL・商談・受注と段階を細かくすると、管理が精緻になったように見えます。しかし段階の数と、営業が動く速さは関係ありません。

増やす前に確認します。その段階が変わったとき、誰が何をするのか。 答えられない段階は、記録のためだけの手間になります。