「営業に渡したはずの情報が、CSに引き継がれていない」。 マーケティングが時間をかけて育てたリードの行動履歴、営業が商談で把握した顧客の懸念事項――こうした情報が部門の境界を越えるたびに少しずつ失われ、最終的にCSが「この顧客は何を期待していたのか」すらわからない状態でオンボーディングを始める。本稿では、マーケ→営業→CSの各移行点で渡すべきデータスキーマを設計し、情報損失を構造的に防ぐ受渡しアーキテクチャをご紹介します。
図1: 部門間の情報は境界点を越えるたびに失われる — 各移行点でのデータスキーマ設計が鍵
部門間連携の構造問題
マーケティング→営業→カスタマーサクセス（CS）の3部門をまたぐ情報連携は、多くの組織で課題を抱えています。
Gartnerの2024年調査によれば、マーケティングと営業の共同実施は15の商用活動のうちわずか3活動に留まります。約80%の活動ではどちらか一方の部門の関与が欠落しており、90%が機能間の優先順位衝突を報告しています。
この問題は「連携意識が低い」という精神論ではなく、部門境界で渡すべき情報が定義されていない構造問題です。各移行点で何の情報を渡すべきかを明示的にスキーマ化し、欠落が生じた場合にその理由を記録する仕組みが必要になります。
Forrester（米国の調査・アドバイザリー企業）は2021年にB2B Revenue Waterfallモデルを更新し、新規リードだけでなく既存顧客からの収益機会も含む一体管理へ拡張しました。マーケ→営業だけでなく、CS段階まで含めた連結設計が求められています。
3つの境界点と部門の責務
マーケ・営業・CSの各部門が担う責務と、部門間の境界点を整理します。
図2で注目すべきは、CSから マーケへの破線（既存顧客機会）です。契約更新時にアップセル・クロスセルの機会が生まれますが、この情報がマーケに戻らないと、既存顧客は新規リードとして再獲得するコストが発生してしまいます。CS→マーケの逆方向の情報連携も設計に含める必要があります。
境界点ごとの情報損失パターン
各境界点で「渡される情報」と「失われやすい情報」を対比します。
情報損失は「渡さなかった」だけでなく、「渡したが構造化されていなかった」ケースも多く発生します。自由記述のメモに埋もれた情報は、受け手が検索・活用できず実質的に失われます。
移行点別データスキーマ
各境界点で渡すべきデータ項目、損失しやすい情報、防止策を整理します。MQL（Marketing Qualified Lead：マーケティング部門が一定基準を満たしたと判定した見込み顧客）からSQL（Sales Qualified Lead：営業部門が商談可能と判定した見込み顧客）への移行が最初の境界点です。
| 境界点 | 渡すべき必須項目 | 損失しやすい情報 | 防止策 |
|---|---|---|---|
| MQL→SQL | リードソース、スコア、直近の反応コンテンツ、想定課題、MQL判定日 | ナーチャリング経緯の詳細、競合検討の兆候、過去の失注歴 | 行動履歴サマリーを構造化フィールドで記録。欠落理由コード必須 |
| SQL→商談化 | 追客判断の根拠、想定予算規模、決裁プロセス、次アクション、期日 | 初回接触時の温度感、マーケ段階での反応傾向 | SQL受入時にマーケ情報の引用フィールドを必須化 |
| 商談→受注 | 契約金額、製品構成、導入スケジュール、決裁者、契約条件 | 失注リスク要因、競合との比較論点、顧客側の懸念事項 | 受注チェックリストに「商談経緯サマリー」を必須項目化 |
| 受注→CS | 契約内容、導入要件、主担当者、商談時の期待値、運用体制の制約 | 商談中に出た懸念・要望、過去の問い合わせ履歴、社内体制の制約 | CS引き継ぎテンプレートに「期待値・懸念事項」欄を設置 |
必須項目の数を増やすほど精度が上がるわけではありません。入力負荷が増えると更新遅延や欠落率が逆に上昇する場合があります。各境界点の必須項目は用途に直結する最小集合に絞り、追加項目は改善ループの中で段階的に検討してください。
欠落理由コードの設計
空欄を許容すると、「情報が存在しなかった」のか「取得を怠った」のかが区別できません。欠落時には以下の理由コードの入力を必須化します。
- NOT_AVAILABLE — 該当情報が現時点で存在しない。次回接触時に取得を試みます
- NOT_ASKED — 確認すべきだったが未確認。プロセス改善の対象として扱います
- DECLINED — 顧客が回答を辞退した。代替情報の有無を検討します
- IN_PROGRESS — 取得中だが未完了。期日を設定して追跡します
特に NOT_ASKED の比率が高い場合は、ヒアリング手順書の見直しや担当者トレーニングが必要なシグナルです。この理由コードを構造化することで、「何が足りないか」ではなく「なぜ足りないか」を改善サイクルに組み込めるようになります。
CRMでのライフサイクル管理
ステージ定義と自動更新
HubSpot（マーケティング・営業・CS統合のCRMプラットフォーム）のライフサイクルステージ定義は、Subscriber→Lead→MQL→SQL→Opportunity→Customerの段階を標準提供しています。各ステージに対して、Date entered（進入日）、Date exited（退出日）、Cumulative time（累積滞在時間）の履歴プロパティが記録され、境界点の滞留計測に活用できます。
HubSpotのオブジェクト間ライフサイクル自動同期設定により、連絡先・会社・商談のステージ更新を連動させることも可能です。ただし、自動更新は原則として前進方向のみであり、後退（差し戻し）の理由は別途記録する設計が必要です。
Lead変換時のデータ生成
Salesforce（クラウド型CRMプラットフォーム）では、Lead変換時にAccount（取引先）・Contact（取引先責任者）・Opportunity（商談）が同時に生成されます。この変換がMQL→SQL/商談化の境界点にあたり、変換時に情報が適切に引き継がれるよう、変換前のLead情報とConverted Status、Record Ownerの設計が重要になります。
受渡しの運用フロー
CRMを共通基盤として、各境界点で必須項目と理由コードを記録する流れを整理します。
- マーケ → CRM: MQL判定時に必須5項目と理由コードをCRMに記録し、ステージを更新します。Date enteredが自動記録されます
- CRM → 営業: SQL通知とともにリード情報・行動履歴が営業に送られます。営業はSQL受入か差し戻しを判断し、差し戻しの場合は理由コードを必須入力します
- 営業 → CRM: 商談化（提案・見積）から受注確定（契約情報・導入要件）まで、各段階でCRMを更新します。滞留時間の計測が自動で進みます
- CRM → CS: 受注確定後、契約内容・商談経緯・顧客の期待値をまとめたCS引き継ぎ通知が発行されます。CSはオンボーディングチケットを起票します
このフロー全体を通じて、CRMが全境界点の通過率・滞留日数・欠落率を集計し、月次レビューの基盤となります。
境界点KPIと改善ループ
受渡し品質を継続的に改善するために、3つの境界点KPIを設定します。
| KPI | 定義 | 計測方法 | 改善トリガー |
|---|---|---|---|
| 境界点通過率 | 各境界点を通過したレコードの比率 | ステージ変更数/前ステージ在籍数 | 通過率が前月比で10%以上低下 |
| 境界点滞留日数 | 境界点のステージに滞在した日数 | Date entered/exited の差分 | 中央値が基準日数を超過 |
| 欠落項目率 | 必須項目が欠落（理由コードのみ）の比率 | 理由コード入力数/全レコード数 | NOT_ASKEDの比率が20%超 |
図4: 改善ループ — 計測→分析→改善→実行の4ステップで受渡し品質を継続的に向上させる
運用は週次と月次の2層で回します。週次では欠落項目の補完、アサイン調整、滞留アラートへの対応を行います。月次では境界点KPIをレビューし、スキーマ改定の要否やしきい値の見直しを判断します。週次は「日々の品質維持」、月次は「構造的な改善」という役割分担です。
HubSpotのジャーニーレポートでは、Contacts・Deals・Ticketsをまたぐ顧客ジャーニーの可視化が可能です。境界点を跨いだ連続性の検証に活用できます。
あわせて読みたい
まとめ：受渡しアーキテクチャの3原則
- 境界点ごとに必須スキーマを固定します。 各移行点で渡すべき最小必須項目を定義し、欠落時には理由コードの入力を必須化します。項目を増やしすぎず、用途に直結する項目に限定してください
- 損失を定量化し改善可能にします。 境界点KPI（通過率・滞留日数・欠落率）を月次でレビューし、どの境界点で何が恒常的に失われているかを可視化します
- CS段階まで含む連結設計にします。 マーケ→営業の接続だけでなく、受注→CS、さらに既存顧客からの再循環まで含めた一体設計を行います
Agenticベースでは、部門間受渡しアーキテクチャの設計から、データスキーマの策定、CRMへの実装支援、境界点KPIの運用設計まで支援しています。 お問い合わせはこちら →
この記事の著者
Agentic Base 編集部
AIエージェントとWebメディア運用の知見を活かし、実践的なナレッジを発信しています。
