手順を詳しく知る
展示会出展：会期後の営業確認会：引継ぎ不足と進捗を短時間でそろえる
営業へ渡した件数だけでは、その後に動ける状態か分かりません。確認会では一件ずつ感触を報告する代わりに、受入条件、不足情報、約束の残件、変わった状態をそろえます。
こんな方に展示会リードを受け渡すマーケティング・営業の責任者
このページでできること営業が受け入れた記録と保留を分け、不足の種類を改善へ戻せる
会議の目的を、件数報告から判断へ変える
確認会で決めたいのは、誰が何件集めたかだけではなく、営業が対応する条件を満たしたか、情報が足りないのか、本人が望む対応が完了したかです。事前に記録を一覧にし、確認が必要な案件だけを議題へ上げます。全件の会話を読み上げる形式にすると、判断の時間がなくなり、詳細を覚えた人だけが説明する会になりやすくなります。
まず営業側が必要とする情報を具体化します。用途、対象製品、検討の状況、次の希望などから、自社の対応に必要な最小限を決めます。情報が欠けるから全件を戻すのではなく、誰が何を確認すれば進められるかを示します。相手が答えていない項目は、説明員が推測で埋めることを解決策にしないでください。
引渡し済みと、営業が受け入れた状態を分ける
HubSpotの公式資料ではMQLとSQLを異なる部門の判断として区別しています。自社が同じ呼び名を使わなくても、送った状態と受け取って検討した状態を分ける考え方は役立ちます。ただし製品の初期設定をそのまま社内の営業基準とせず、会社が決めた状態の意味を共有してください。
架空の確認例では「用途と希望資料が明確なので資料送付は進めるが、個別見積りは設置条件が不足して保留」と記します。一人の状態を一つの色だけで表すより、どの作業が進み、何が止まるかが分かります。受注に至る確率を根拠なく付けず、確認できた条件と次の行動で優先順位を考えます。
保留や差戻しの理由を、改善できる言葉にする
保留理由は「質が悪い」ではなく、対象用途が違う、質問条件が不足、連絡希望が不明、既存担当がいる、回答待ちなどに分けます。原因によって次回の改善先は、出展先、ブース表示、聞取り項目、データ照合、営業受入のどれかに変わります。同じ理由が多いときは数件の実例を確認し、分類の仕方自体が偏っていないかも見ます。
営業担当がすでに接点を持つ企業では、展示会記録を新規開拓として別送しないよう調整します。一方、既存企業の別部門から新たな相談があった場合は、単純な重複として消しません。個人・会社・相談をどの単位で追っているかをそろえ、必要な履歴を残しながら受持ちを決めます。
営業確認会の判断一覧
編集部作成の記入用ひな形です。例示した条件や値は架空例です。実際の内容を入力してください。入力は送信・自動保存されません。移動前にCSV保存できます。
| 管理ID | 会場での約束 | 受入／保留と理由 | 不足を埋める方法 | 会議後の状態 |
|---|---|---|---|---|
会議後に、変えた状態と残した課題を記録する
会議で決まった受入、追加確認、終了、既存担当への統合は、一覧の状態へ反映します。口頭だけの合意にせず、何を根拠に変えたかが分かる短い記録を残します。途中で状況が変わる場合もあるため、集計日を付け、過去の件数を理由なく上書きしない方法を選びます。
最後に、今回の会議で確認を減らせそうな点を一つ選びます。例えば会場で製品名が残らない記録が多ければ、次回は選択欄を見直します。逆に入力されても営業で使われなかった項目は削減候補です。確認会を追及の場にするのではなく、相手への対応を進め、次の出展で情報不足を減らす作業にします。
参照資料と確認範囲
以下は制度・用語・公式の取扱いを確認した資料です。作業手順、比較の視点、記入例は当サイトの編集提案です。個別の契約・施設・製品には、その条件を確認して適用してください。
- HubSpot：コンタクトと会社のライフサイクルステージ ↗
確認日 2026-10-29 / 2026年9月15日更新の公式製品資料。MQLはマーケティング、SQLは営業による判断として定義され、段階をカスタマイズできることを確認。全企業共通の評価基準や受注確率にはしない。