はじめに：「受注後」に構造が存在しない
受注まではうまくいっている。営業も頑張り、マーケティングもリードを作れている。それなのに、解約が増え、オンボーディングが荒れ、アップセルにつながらない。CSが「そんな話は聞いていない」と言い、契約後の顧客情報が正確に引き継がれていない——こうした問題は、サブスクリプション・継続課金・アップセル型のBtoB企業では特によく起きます。
重要なのは、これはCS部門の問題ではないということです。本当の原因は、「受注まで」と「受注後」が別々に設計されていることにあります。
多くの会社では、「受注」で構造が切れている
営業組織は受注をゴールに設計されています。商談数・Win Rate・ARR・受注件数を追う。一方CSは、オンボーディング・活用率・更新率・NRR・チャーンを見る。つまり、そもそもKPI構造が分断されています。同じ会社の中で、「受注まで」と「受注後」が別の組織として動いており、それをつなぐ設計が存在しない——これが最初の問題です。
営業とCSが噛み合わない、典型的な3つのパターン
営業は「受注」を優先する
営業は数字を追います。すると、導入条件が曖昧なまま、無理な期待値や過剰提案を含んだ状態で受注するケースが出てきます。営業からすると「まず契約」が重要であり、それ自体は組織の目標に沿った合理的な行動です。しかし、その判断がCS側に無言のコストを転嫁することになります。
CSは「運用」を背負わされる
契約後、実際に顧客対応をするのはCSです。すると、想定と違う運用・未共有の要件・引き継ぎ漏れ・期待値ギャップが次々と発覚します。CS側は「営業が無理に売った」と感じ始め、組織内の信頼が失われていきます。
顧客体験が分断される
顧客から見ると、営業もCSも同じ会社です。しかし内部では、営業・導入・サポート・更新が別々に動いている。その結果、「契約前と話が違う」という顧客の不満が生まれます。これはRevenue Operationsが機能していない状態の典型例です。
分断される会社に共通する5つの問題
01
顧客情報が分断されている
営業はSalesforce、CSはNotion、サポートは別ツール——という状態では、契約内容・導入背景・期待値・利用状況がつながりません。CS担当者が顧客の過去のやり取りを知らないまま対応することになります。
02
受注後のKPIが存在しない
営業はARRを見ますが、NRR・Expansion・Health Scoreを営業が見ていない。するとコールドな「売って終わり」の構造になります。受注後の収益成長に対して、誰も責任を持たない状態です。
03
引き継ぎ条件が定義されていない
何を共有するか・いつCSへ渡すか・誰が責任を持つかが曖昧なまま運用されています。これでは属人化を避けられず、担当者が変わるたびに情報が欠落します。
04
オンボーディングが設計されていない
導入後、最初に何を使うか・いつ定着確認するか・どこで成功を判断するかが未設計です。この状態ではチャーン率が上がり、顧客の期待値コントロールもできません。
05
収益KPIが部門ごとに分断されている
営業は受注、CSは継続、という分断が続く限り、「収益全体」を最大化する視点が生まれません。NRRやExpansionを組織全体のKPIとして持つ設計が必要です。
本当に必要なのは「Customer Lifecycle Design」
引き継ぎの問題を解決するために、多くの会社はSlackのチャンネルやNotion上のドキュメントを整備しようとします。しかしそれは対症療法にすぎません。本当に必要なのは、Customer Lifecycle Design——獲得・商談・契約・オンボーディング・活用・更新・アップセルを一つの流れとして設計する考え方です。営業だけでも、CSだけでもなく、「顧客ライフサイクル全体」を見ることが重要です。
特にSaaS・サブスクリプションモデルでは、受注よりも継続・Expansion・NRRの方が収益上の重要度が高くなります。つまり「受注後」が収益の中心です。しかし営業組織だけが強い会社では、ここが切れます。高チャーン・アップセル不足・導入失敗が続くのは、その構造的な結果です。
Revenue Architectureという考え方
営業とCSの問題は、部門間のコミュニケーション不足で起きているのではありません。収益KPI・Customer Lifecycle・CRM設計・Revenue Data Flow・RevOpsという構造の問題です。ここで重要になるのがRevenue Architecture（レベニューアーキテクチャ）——営業・マーケティング・CS・CRM・KPI・データ・会議体を「収益につながる一つの構造」として設計する考え方です。
Revenue Architectureを整えることで、営業とCSが同じKPI（ARR・NRR・Expansion・Activation）を見るようになります。顧客情報が統合され、「誰が何を約束したか」が見えるようになります。オンボーディングが構造化され、CSデータが営業にフィードバックされることでアップセルが自然に生まれます。チャーンが減り、期待値ギャップが解消されます。
解約防止
Health Score
営業へ還流
日本企業でこの問題が難しい理由
日本企業には、部門分断・属人営業・Excel文化・情報の口頭共有が根強く残っている組織が少なくありません。その結果、営業とCS連携が崩れやすく、顧客情報の引き継ぎが個人の努力に依存します。欧米型のCS組織モデルをそのまま導入しても、日本企業の商習慣や組織文化とのズレで機能しないことが多い。必要なのは、日本企業に合ったRevenue Architectureの設計です。
Consilegyの考え方
Consilegyでは、CS改善を単なるサポート改善として捉えていません。本質はRevenue Architecture・Customer Lifecycle・RevOps・Revenue Data Flow・KPI設計にあります。Salesforce・HubSpot・CSツール・BI・Slackなどを横断しながら、「受注後も収益が成長する構造」を設計します。目的は契約を取ることではなく、継続収益が積み上がる構造を作ることです。
| 領域 | Consilegyのサポート |
|---|---|
| Customer Lifecycle設計 | Lead→Expansionまでの一貫したフロー設計 |
| 引き継ぎ条件の定義 | 営業→CSの情報引き継ぎ構造とCRM設計 |
| 収益KPI統合 | ARR・NRR・Expansionを部門横断で接続 |
| オンボーディング設計 | 定着・成功判断・早期チャーン防止の設計 |
| RevOps構築 | 会議体・プロセス・KPI・ツール連携の整備 |
まとめ：営業とCSの分断は、収益構造の問題
営業とCSが噛み合わない原因は、コミュニケーション不足ではありません。収益KPI分断・Customer Lifecycle未設計・Revenue Architecture不足・RevOps未整備が根本原因です。だからこそ必要なのは部門改善ではなく、受注から継続までの構造を設計することです。収益は営業だけでなく、Customer Lifecycle全体で生まれます。
Revenue Architecture
受注後も収益が成長する
構造を設計します
Customer Lifecycle・収益KPI・CRM・RevOpsを横断した設計で、継続収益とNRR向上を実現します。
まずは相談する公開日：2026年5月7日