商談を「作る」ことと「動かす」ことは別のスキルだ。多くの組織でパイプラインが機能しない理由は、商談レコードの記録が形骸化し、マネージャーが感覚でレビューし、「次のアクション」が曖昧なままになっているからだ。この章では、商談レコードの正しい使い方・MEDDIC による商談品質の評価・AI Deal Risk の活用・クローズ計画の立て方・受注後の CS ハンドオフまで、商談を「動かし続ける」ための実践技法を体系化する。
HubSpot の商談レコードは「情報を記録する場所」ではなく、「チーム全員が商談の現在地を共有する指揮センター」として設計されている。担当者が離職しても・マネージャーが変わっても・CS にバトンパスしても、商談レコードを見ればすべての経緯がわかる——それが理想の状態だ。
| 項目 | 記録のタイミング | 放置した場合のリスク |
|---|---|---|
| 次のアクション（期日付き） | すべてのミーティング・通話の直後に記録 | 「次に何をすべきか」が不明確になり商談が止まる。マネージャーのレビューでも指摘できない |
| バイイングコミッティの役割 | 各コンタクトとやり取りするたびに更新 | 意思決定者を把握せずに商談が進み、最後で「上の承認が必要」と言われてクローズが遅れる |
| 競合の状況 | 競合への言及があったミーティング・通話後 | 「いつの間にか競合に負けていた」という状況になる。早期対処の機会を失う |
| 懸念・ブロッカー | バイヤーが懸念を示したタイミングで即記録 | 懸念が「解決済み」か「未解決」かがわからなくなる。クローズ直前に再燃するリスクがある |
| クローズ予定日の根拠 | クローズ日を設定・変更するたびに | 「なんとなく月末」の希望的観測クローズ日がフォーキャストを歪める |
HubSpot に Google Meet・Zoom を連携すると、ミーティング終了後に Breeze AI が自動で議事録サマリを生成し、商談レコードのタイムラインに保存してくれる。決定事項・アクションアイテム・リスク項目を自動抽出するため、ミーティング後の手入力メモがほぼ不要になる。2026年3月時点で日本語の精度も実用レベルに達している。
「この商談、本当に受注できるのか？」——この問いに答えるために多くのエンタープライズ営業組織が使っているのが MEDDIC（またはその拡張版 MEDDPICC） フレームワークだ。HubSpot の商談プロパティと組み合わせることで、直感ではなくデータで商談品質を評価できる。
MEDDIC の各項目を商談レコードのカスタムプロパティとして設定することで、パイプラインレビューで「MEDDIC が揃っているか」を定量評価できるようになる。
| MEDDIC 項目 | プロパティ名（例） | タイプ | レビューでの確認ポイント |
|---|---|---|---|
| Metrics | success_metrics | テキスト | 「〇〇%削減」など定量目標が書かれているか |
| Economic Buyer | economic_buyer_confirmed | チェックボックス | チェックが入っているか（＝特定済みか） |
| Decision Criteria | decision_criteria | テキスト | 評価軸が記録されており、自社優位な軸が含まれているか |
| Decision Process | decision_process | テキスト | 承認フローと期間が明記されているか |
| Identify Pain | identified_pain | テキスト | 具体的な課題と現状維持コストが書かれているか |
| Champion | champion_contact | コンタクト関連付け | Champion が商談に紐づいており、最近アクティビティがあるか |
HubSpot の Playbooks 機能に MEDDIC の各項目をチェックリスト形式で登録しておくと、担当者がミーティング中に画面を見ながら「確認できていない項目」を把握できる。マネージャーはパイプラインレビューで「MEDDIC のどこが欠けているか」を会話の軸にすることで、「感想」ではなく「情報の欠如」を指摘するコーチングが実現できる。
2025年秋に本格稼働した Conversation-powered Deal Risks は、通話録音・メール・ミーティング内容を AI が分析し、商談に潜むリスクシグナルを自動検知して商談レコード上に表示する機能だ。担当者が気づかないリスクを早期に可視化することで、手遅れになる前に対処できる。
Deal Risk（リスクシグナル）と AI Deal Score（受注確率スコア）は補完関係にある。「AI Deal Score は高いが Deal Risk が複数ある」商談が最も要注意だ——スコアは過去の類似パターンから算出されるため、現在進行中のリスクを反映しにくい場合がある。週次レビューでは「スコアが高いのにリスクが2つ以上ある商談」を優先的にピックアップし、マネージャーが深掘りする運用が効果的だ。
Mutual Action Plan（MAP）とは、「受注するまでに何をどの順番で誰が実施するか」を営業担当者とバイヤーが合意した共同行動計画だ。一方的なクローズプランではなく、バイヤーも「自分たちの作業」として納得して進めるため、クローズ率と予測精度が大幅に向上する。
現時点（2026年3月）で HubSpot には専用の MAP ツールは実装されていない。実務的には以下の方法で代替・管理する。
| 管理方法 | メリット | デメリット・注意点 |
|---|---|---|
| HubSpot タスク＋商談プロパティ | CRM と完全統合。担当者への自動リマインダーが設定できる | バイヤーへの共有ができないため「共同」感が薄い |
| Google ドキュメント・Notion 共有 | バイヤーと同じドキュメントをリアルタイム共同編集できる | HubSpot のタイムラインに自動記録されないため、手動でリンクを貼る運用が必要 |
| HubSpot の Quote ページ | 見積書＋次のステップを1ページで表示できる | MAP 全体の管理には不向き。あくまで最終段階のクローズに向けた補助ツール |
| 専用 MAP ツール（Aligned・Dealroom など） | バイヤーポータル機能・タスク管理・進捗追跡が充実 | 別途ツール費用が発生。HubSpot との連携設定が必要 |
受注はゴールではなくスタートだ。しかし多くの組織で「営業が商談中に把握した顧客情報」が CS に伝わらず、顧客が「また最初から説明しなければならない」という体験をする。CRM ネイティブである HubSpot の最大の強みのひとつは、商談レコードに蓄積されたすべての情報が自動的に CS チームと共有されることだ。
商談が Closed Won になった瞬間を起点に、以下のアクションをワークフローで自動実行できる。
| トリガー | 自動アクション | 目的 |
|---|---|---|
| 商談ステージが Closed Won に変わった | ライフサイクルステージを「Customer」に更新 | マーケのナーチャリングメールが顧客に届かないようにする |
| 商談ステージが Closed Won に変わった | CS 担当者をコンタクト・会社レコードの Owner に割り当て | CS が担当顧客として認識し、フォローアップのオーナーシップを持つ |
| 商談ステージが Closed Won に変わった | CS チームへの Slack 通知（顧客名・金額・担当営業・主要課題を含む） | CS がリアルタイムで受注を把握しキックオフ準備を開始できる |
| 商談ステージが Closed Won に変わった | 更新パイプラインに新規商談を自動作成（クローズ日 = 契約期間終了日） | 更新対応が漏れなく追跡される。90日前に自動アラートが発火する |
| Closed Won から 72 時間後 | CS 担当者に「キックオフ未設定」タスクを作成 | キックオフ設定を忘れるリスクを防ぐ。早期オンボーディングを促進する |
次のアクション・バイイングコミッティ・競合状況・懸念点を常に最新の状態に保つ。Breeze AI のミーティングサマリを活用して手入力工数をゼロに近づける。
各項目をカスタムプロパティ化し、Playbooks にチェックリストとして登録する。マネージャーは「感想」ではなく「MEDDIC の欠如」を指摘するコーチングに転換する。
競合言及・予算懸念・意思決定者不在・エンゲージメント低下の4シグナルが最頻出。AI Deal Score が高くてもリスクが複数ある商談を最優先でレビューする。
クローズ計画を一方的に作るのではなく、バイヤーと合意した行動計画に仕上げる。承認プロセス・法務レビュー期間を事前把握し、クローズ日の根拠を明確にする。
商談レコードへの記録が CS への引き継ぎドキュメントになる。Closed Won トリガーのワークフローで CS への通知・Owner 変更・更新商談作成を自動化する。
担当者は毎日15分のタスク消化、マネージャーは週次パイプラインレビュー、RevOps は月次健全性分析——役割ごとに異なるリズムでデータを活用する習慣を作る。