サポートチームは毎日、顧客の「困りごと・要望・不満・熱量」に直接触れている。この情報は Sales が商談で使える最高の武器であり、Marketing がコンテンツを作るための最良のインプットだ。しかし多くの組織では、サポートデータは Service Hub の中で眠ったまま他のチームに届かない。Taking advantage of the strength that Service Hub is built on the shared data infrastructure of HubSpot CRM, we designed a collaborative design in which the three teams of CS, Sales, and Marketing "use the same customer data for different purposes."will be systematically explained in this chapter.
HubSpot が提唱する「フライホイール」モデルでは、顧客を「引き付け（Attract）→ 関与させ（Engage）→ 喜ばせる（Delight）」サイクルが回り続けることで、満足した顧客が新しい顧客を連れてくる自己増殖する成長エンジンが生まれる。📤 Delivered to each teamProduct: Feature requests TOP10 (monthly)
Integrating different tools like Salesforce + Zendesk + Marketo creates data silos, synchronization delays, and dual management. By unifying HubSpot across Sales, Marketing, and Service,A single contact record records all of the following: Business negotiation history → Contract details → Ticket history → NPS score → Health status, all teams can see the same information in real time. This "shared CRM" is the foundation for all the collaborations explained in this chapter.
For collaboration to work,What is recorded in which property, who updates it, and who references it for what purpose?need to be designed. Below is a design example of contact/company properties that should be shared by the three teams: CS, Sales, and Marketing.
| Property type | update owner | Update timing | Main reference teams/applications |
|---|---|---|---|
| health score | automatic (workflow) | Real-time updates every time an index changes | Sales (judgment of renewal negotiation priority)/Management (cancellation risk management) |
| Cancellation risk | 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分、解約リスク・アップセル機会・アドボケイト候補・コンテンツネタを共有してアクションオーナーを決める会議を組織のカレンダーに固定する。「報告会」ではなく「アクション設計会議」として運営することが鍵だ。