サポートチームは毎日、顧客の「困りごと・要望・不満・熱量」に直接触れている。この情報は Sales が商談で使える最高の武器であり、Marketing がコンテンツを作るための最良のインプットだ。しかし多くの組織では、サポートデータは Service Hub の中で眠ったまま他のチームに届かない。Service Hub が HubSpot CRM の共有データ基盤の上に構築されているという強みを活かし、CS・Sales・Marketing の3チームが「同じ顧客データを異なる目的で活用する」連携設計を本章で体系的に解説する。
HubSpot が提唱する「フライホイール」モデルでは、顧客を「引き付け（Attract）→ 関与させ（Engage）→ 喜ばせる（Delight）」サイクルが回り続けることで、満足した顧客が新しい顧客を連れてくる自己増殖する成長エンジンが生まれる。このフライホイールの「Delight（喜ばせる）」フェーズを担うのが Service Hub だ。顧客が喜べば更新率・NRR が上がり、推奨者が増え、Marketing のコンテンツ資産（事例・口コミ）が増え、Sales の商談が成約しやすくなる——Service Hub への投資はすべての Revenue に循環して戻ってくる。
Salesforce + Zendesk + Marketo のような異なるツールを連携させると、データのサイロ化・同期遅延・二重管理が発生する。HubSpot を Sales・Marketing・Service で統一することで、1つのコンタクトレコードに「商談の経緯 → 契約内容 → チケット履歴 → NPS スコア → ヘルス状態」がすべて記録されており、どのチームもリアルタイムで同じ情報を参照できる。この「共有 CRM」こそが、本章で解説するすべての連携の土台だ。
連携を機能させるには、どのプロパティに何を記録し・誰が更新し・誰がどの目的で参照するかを設計する必要がある。以下は CS・Sales・Marketing の3チームが共有すべきコンタクト／会社プロパティの設計例だ。
| プロパティ種別 | 更新オーナー | 更新タイミング | 主な参照チーム・用途 |
|---|---|---|---|
| ヘルススコア | 自動（ワークフロー） | 指標変化のたびにリアルタイム更新 | Sales（更新商談優先度の判断）・経営層（解約リスク管理） |
| 解約リスク | CS + 自動（ヘルス連動） | ヘルス「危険」変化時に自動更新・CSM が手動でも更新 | Sales（更新商談の緊急度）・CS マネージャー（優先対応判断） |
| アップセル機会 | CS（CSM が手動） | シグナル検出時・CS ミーティングの会話メモ記録時 | Sales（拡大商談の起票）・AE（提案トーク材料） |
| アドボケイト候補 | CS（NPS ワークフロー連動） | NPS 9〜10 スコア受信時に自動 ON | Marketing（事例取材依頼・レビュー依頼・リファーラル施策） |
| 更新日 | Sales（契約締結時に入力） | 契約更新のたびに Sales が更新 | CS（更新前 QBR 計画）・CS Workspace（更新90日前アラート自動起動） |
「アップセル機会フラグ」プロパティを作っても、誰も入力しなければ意味がない。各プロパティのオーナー（入力責任者）・更新タイミング・更新方法（手動 / ワークフロー自動）を設計段階で明文化し、オンボーディング資料に含めることが、連携を長期的に機能させる条件だ。プロパティは作ることよりも「継続的に正しく入力される仕組み」を作ることの方が難しい。
CS チームが日々の顧客接点で把握している情報——「この顧客は最近担当者が変わって使い方がわからなくなっている」「予算を増やせると言っていた」「競合ツールも試していると言っていた」——は Sales が商談で使える最高のインテリジェンスだ。この情報を CRM の共有プロパティと Slack 通知で Sales に届ける仕組みを自動化することで、CS の日常業務が Revenue に直結する。
Marketing チームが最も欲しているのは「本物の顧客の声」だ。ペルソナ分析やアンケートより、実際のサポート対応の中で蓄積された「顧客が使う言葉・感じている不満・製品への愛着」の方が、広告コピーにも LP にも事例記事にも圧倒的に使いやすい。CS チームが日々触れているこのリアルな顧客の声を、Marketing が活用できる形で届ける仕組みを設計しよう。
CS が顧客を喜ばせると更新率・NRR が上がり、推奨者が Marketing 資産になり、Sales の商談が成約しやすくなる。サポートへの投資は「コスト」ではなく「Revenue エンジンへの投資」として位置付けるべきだ。
ヘルススコア・解約リスク・アップセル機会・アドボケイト候補——これらのプロパティに「誰が・いつ・何を記録するか」を設計しないと、どんなワークフローを組んでも情報が途切れる。プロパティ設計は「技術の問題」ではなく「役割の問題」だ。
ヘルス低下・アップセルシグナルはワークフローで AE に自動通知し、CSM のメモがコンテキストを補完する。自動化だけでは文脈が欠ける——CSM が「なぜそのフラグが立っているか」を言葉で説明することが商談成功率を高める。
NPS 9〜10 受信 → アドボケイト候補フラグ ON → 3日後にレビュー依頼 → CSM にタスク「事例取材打診」。満足した顧客の熱量は時間とともに冷める。受信した瞬間に自動でアクションが走る仕組みが最も効果的だ。
月次で「頻出質問 TOP10・顧客が使う言葉」を Notion にまとめて Marketing に渡す。「顧客が実際に聞いてくること」から作ったコンテンツは SEO でも広告コピーでも、外部ライターが書く記事より圧倒的にリアリティが高い。
CS・Sales・Marketing・RevOps が月1回60分、解約リスク・アップセル機会・アドボケイト候補・コンテンツネタを共有してアクションオーナーを決める会議を組織のカレンダーに固定する。「報告会」ではなく「アクション設計会議」として運営することが鍵だ。