MQLを営業が受け取ったか分かる？判定・通知・引受を分ける表

25人の製品説明会社・春野ラボのマーケティング担当加藤は、森製作の相談L56をMQLと判定しました。営業佐々木へ通知しましたが、本人はまだ内容を確認していません。

通知済みを営業引受済みとして数えると、担当の作業待ちが見えません。

マーケティング判定・営業への通知・営業引受を別時刻と状態で残し、MQL条件の根拠を受渡し票へ添えます。 参照資料「HubSpot: Contact and company lifecycle stages」で確認した範囲は、マーケティング判定MQL、営業判定SQL、商談という状態の区別。 この節の会社・担当・社内基準は架空の教材です。

この章の根拠：出典1

「MQL判定」の入力は、10月10日9時、対象条件を確認です。ここでは確認項目と資料を残します。記録の判断欄には「マーケティングの判断」と残します。

「営業通知」の入力は、同日9時5分です。ここでは通知到達だけで引受にしません。記録の判断欄には「引受依頼済み」と残します。

「営業確認」の入力は、同日11時、佐々木が内容確認です。ここでは結果と不足情報を返します。記録の判断欄には「引受または差戻し」と残します。

比較表は横に動かして全ての列を確認できます。

加藤はMQL条件を対象地域・対応可能な用途・具体質問ありとする社内案へ定義します。どの条件を何で確認したかをL56へ添え、点数だけで受渡しを完了にしません。

9時5分の通知と11時の引受なら95分の待ちがあります。MQL数一件と引受一件は別の節目であり、二件のリードとして足しません。

通知から引受までの95分は連携工程の待ち時間です。MQL判定から引受までは9時から11時の120分なので、起算を混ぜないことが必要です。引受の時刻には営業が内容を確認した記録を使います。

営業が用途情報の不足を返した場合はMQL判定を無かったことにせず、当時の判定と現在の保留を残します。加藤が不足項目を確認して再度引受を依頼します。

MQLは自社のマーケティング判定区分です。問い合わせや閲覧だけから購入意思、連絡同意、SQLへの移行を確定しません。

加藤は不足した用途情報を確認する担当を持ちます。営業が保留した理由を判定時点の履歴へ追記し、再引渡しは同じ受付IDで行います。引受時刻を通知の時刻で埋めません。

加藤が判定資料と通知時刻を記し、佐々木が引受結果を返却します。管理担当吉田は通知待ちと内容確認待ちを一覧で分けます。

メール通知の自動完了で営業引受が設定されず、差戻し理由が同じL56へ残るか確認します。判定条件が変わった際は使用した版も記します。

吉田は判定条件と佐々木の引受理由を別々に照合します。通知済みを引受済みと誤記した場合は営業の確認記録を探し、見つからなければ引受未確認へ訂正します。

MQL判定、通知、営業の引受を三つの出来事として記します。具体的な条件がそろった時点を判定の根拠へ残します。

待ち時間を報告するなら起算と終了の欄を固定します。同じリードの節目を件数へ足して二件と数えません。

加藤は不足情報を戻し、佐々木は引受結果を返します。判定と引受の根拠が両方読めることを今回の連携の完了条件にします。