IS→FSパス品質のバラつきが商談化率低下を招く
ISからFSへのパス後に商談化率が低い、パスの品質にバラつきがあるという課題を解決したいなら、IS→FSパスの品質は「担当者の勘」ではなく、SFA/MAの設定と運用ルールで標準化でき、専門家の支援で短期間に仕組み化できます。
BtoB企業では、営業フォローが必要な情報を正確に連携できていないケースで、商談化の可能性が高い情報を取りこぼす課題が報告されています。BtoB企業におけるIS専任組織の設置率は約35〜40％程度（2023年時点）であり、IS/FS分業が進む中でパス品質の重要性が増しています。
この記事で分かること
- IS/FSの役割分担と商談パスの基本的な考え方
- パス時に必須の引き継ぎ項目と標準化の方法
- 商談化率を高めるパス設計のポイント
- SFA/MAを活用したパス品質の仕組み化
SQL（Sales Qualified Lead） とは、営業が商談化の可能性が高いと判断した見込み顧客で、ISからFSへ引き渡す基準となるリードです。商談化率は、リード（見込み顧客）のうち、商談（FSがフォローする案件）に進んだ割合を指します。
IS/FSの役割分担と商談パスの基本
IS/FS分業を機能させるには、それぞれの役割を明確にし、どのような基準でリードを引き渡すかを定義することが不可欠です。
ISの役割は、マーケティングが獲得したリードに対する一次接触、スクリーニング（見極め）、ナーチャリング（育成）です。一方、FSの役割は、SQLとして引き渡されたリードに対する提案活動とクロージングです。
MQL（Marketing Qualified Lead） は、マーケティング施策で獲得し、一定の条件を満たした見込み顧客で、ISがフォローする対象となります。MQLからSQL、そして商談へと進むプロセスにおいて、IS→FSパスの品質が商談化率を大きく左右します。
IS担当者の経験則だけでパス判断をしている状態では、「この顧客は筋が良さそう」という属人的な判断に依存し、パス品質のバラつきは解消できません。これが商談化率低下の一因となっています。
ISの役割とFSへの引き渡し基準
ISがどこまで担当し、どのような基準でFSに引き渡すかを明確にすることがパス品質の基盤です。
BANT情報とは、予算（Budget）・決裁者（Authority）・ニーズ（Need）・導入時期（Timing）の4要素で、ISがヒアリングする基本項目です。BANT情報のヒアリングがISの主な役割であり、これらの情報をどこまで確認できたかがSQL判定の基準となります。
SQL判定の基準例としては、以下のような条件が考えられます。
- 役職が課長以上、または意思決定に関与できる立場
- 予算化の見込みがある、または予算確保済み
- 導入時期が6ヶ月以内に想定されている
- 課題が明確で、解決意欲がある
これらの基準は企業ごとに定義が異なるため、自社のSQL定義を明文化しておくことが重要です。
FSが求めるパス品質とは
FS視点で「案件化しにくい」と感じるパスには共通の特徴があります。FSが求めるパス品質を理解することで、IS/FS間の期待値ギャップを解消できます。
FSが案件化しにくいと感じるパスの特徴:
- 顧客の課題・ニーズが曖昧なまま引き渡されている
- 過去のやり取り（刺さったコンテンツ、NG事項）が共有されていない
- 予算・導入時期など基本的なBANT情報が不明
- 担当者以外の意思決定者情報がない
一方で、引き継ぎ項目を増やしすぎるとISの入力負荷が高まり、結果的に入力されないというトレードオフもあります。必須項目は絞り込み、任意項目は別途設けるといった設計が必要です。
IS→FSパス時に必須の引き継ぎ項目
パス時に共有すべき具体的な情報項目を標準化することで、パス品質のバラつきを解消できます。営業フォローが必要な情報を正確に連携できていないケースでは、商談化の可能性が高い情報を取りこぼすリスクがあります。
以下に、IS→FSパス時の必須引き継ぎ項目をチェックリスト形式で整理します。
【チェックリスト】IS→FSパス時の必須引き継ぎ項目チェックリスト
- 会社名・部署名
- 担当者名・役職
- 連絡先（電話・メール）
- リードソース（流入経路）
- SQL判定日と判定理由
- 予算化の有無・概算予算
- 導入希望時期
- 決裁者・意思決定プロセス
- 顕在化している課題
- 導入目的・期待する成果
- 競合検討状況
- 過去のコンタクト履歴（日付・内容）
- 刺さったコンテンツ・資料
- NG事項（地雷・避けるべき話題）
- 次回アクション予定
- 補足メモ（定性情報）
顧客情報と案件ステータス
基本情報と状況・温度感に関する項目は、パスの第一歩となる必須情報です。
会社名・担当者・連絡先は当然として、リードソース（どのチャネルから流入したか）の情報は、FSがアプローチ方法を検討する上で重要です。SQL判定日と判定理由を明記することで、FSはそのリードがなぜSQLと判断されたかを理解できます。
予算化の有無、導入希望時期といった温度感に関する情報は、FSが優先順位を判断する上で不可欠です。
課題・ニーズとコンタクト履歴
顧客の課題・導入目的・意思決定プロセス・過去のやり取りは、FSが提案内容を検討する上で最も重要な情報です。
特に、過去のコンタクトで「刺さったコンテンツ」や「NG事項（地雷）」の共有は見落とされがちですが、FSにとっては商談の成否を左右する情報です。たとえば「価格の話は避けてほしいと言われた」「〇〇の事例に興味を示した」といった定性情報は、商談化率向上に直結します。
商談化率を高めるパスのポイント
商談化率を高めるには、パスの「何を」だけでなく「いつ」「どれくらい」も重要です。初回接触スピードと接触回数の設計がポイントとなります。
ある事例では、SQLの定義と引き継ぎルールを見直した結果、商談化率が18％から36％へ向上したことが報告されています。SQL数を追うのではなく、定義の精度を高めることで商談化率が倍増した例です。
初回接触スピードと接触回数の設計
リード発生から初回接触までのスピードは、商談化率に大きく影響します。
商談化率50％以上のBtoB企業では、約半数が当日中〜2日以内に初回接触を行っていることが調査で示されています。また、高商談化率企業では、初回接触からアポイント獲得までの平均接触回数が3回（回答企業の25.4％で最多）というデータもあります。
海外の調査では、問い合わせから5分以内に架電する企業は、24時間以内に架電する企業に比べて商談化率が最大10倍高いとされていますが、日本市場での再現性については検証が必要です。いずれにせよ、初動のスピードが商談化率に影響することは明らかです。
SQLの定義見直しによる商談化率改善
商談化率を高めるためにSQLを増やそうとする考え方は誤りです。SQLの「数」ではなく「定義の精度」を高めることが重要です。
前述の事例では、SQLの定義と引き継ぎルールを見直した結果、商談化率が18％から36％へ向上しました。SQL数は減少しましたが、パス品質が向上したことで商談化率が倍増したのです。
「とにかくアポを増やせ」という方針では、FSの案件化率が下がり、結果的に受注効率が悪化するリスクがあります。IS→FSパスの評価は、商談化率（IS側）と案件化率・受注率（FS側）をセットでモニタリングすべきです。
SFA/MAを活用したパス品質の標準化
パス品質を属人化から脱却させるには、SFA/MAの入力項目設計とスコアリング設定が鍵となります。
リードスコアリングとは、属性や行動に基づきリードに点数を付け、優先度を判定する手法で、MAツールで実装されることが多いです。スコアリングを活用することで、SQL判定の属人性を減らすことができます。
SFAを導入しても引き継ぎ項目を個人任せにしている状態では、パス品質のバラつきは解消できません。SFAの必須入力項目として引き継ぎ項目を設定し、入力されていないとパスできない仕組みにすることが有効です。
IS/FS連携をモニタリングする指標設計
商談化率だけでなく、案件化率・受注率をセットで追う必要があります。
広告経由リードの商談化率については、BtoB調査によると11〜20％が最多（回答企業の31.3％）であり、15％前後が及第点とされています。ただし、業種・チャネル・SQL定義により大きく変動するため、あくまで目安として参考にしてください。
商談化率だけを追うと、無理やりアポを増やしてFS案件化率が下がる問題が起きやすくなります。IS→FSパスの評価は、商談化率（IS）と案件化率・受注率（FS）をセットでモニタリングし、パイプライン全体で最適化を図ることが重要です。
まとめ｜IS→FSパスの仕組み化で商談化率を改善する
IS→FSパスの品質向上には、担当者の経験則に依存するのではなく、引き継ぎ項目の標準化とSFA/MAによる仕組み化が不可欠です。
本記事のポイントを整理します。
- IS/FSの役割分担とSQL定義を明確化する
- 引き継ぎ項目をチェックリスト化し、必須項目を標準化する
- 初回接触スピードと接触回数を設計する
- SFA/MAの入力項目設計でパス品質を仕組み化する
- 商談化率と案件化率・受注率をセットでモニタリングする
SQLの定義と引き継ぎルールを見直した結果、商談化率が18％から36％へ向上した事例が示すように、パス品質の標準化は商談化率改善に直結します。
IS→FSパスの品質は「担当者の勘」ではなく、SFA/MAの設定と運用ルールで標準化でき、専門家の支援で短期間に仕組み化できます。自社のパス品質に課題を感じている場合は、まず現状のSQL定義と引き継ぎ項目を棚卸しすることから始めてみてください。