売上プロセスの設計は、まずどの部門から着手すべきですか?

決まった正解はありませんが、多くの組織では顧客数が多く影響範囲の大きいマーケから営業への引き渡しが優先候補になります。まず一つの境界で小さく検証し、効果を確認してから他の境界へ広げる進め方が現実的です。

引き渡しの基準を厳しくしすぎると、リード数や商談数が減ってしまいませんか?

一時的に減る可能性はありますが、目的は数を絞ることではなく、下流での差し戻しや手戻りを減らすことです。基準の妥当性は、差し戻し率や初回接触の質など複数の指標を組み合わせて継続的に見直す必要があります。

新しい役職（例えばRevOps担当）を置かないと、引き渡し設計はできませんか?

専任役職は必須ではありません。既存のマーケ・営業・CSのメンバーが、通過条件や引き継ぐ情報といった機能を分担して担うことでも、引き渡し設計は成立します。

売上プロセスとは：マーケ、営業、CSを「引き渡し」で設計する

この記事の要約

マーケ、営業、CSそれぞれの数字は悪くないのに全社の成長が鈍る組織では、原因が各部門の実行力ではなく、部門間の「引き渡し」の設計不在にあるケースがほとんどです。

本記事は、売上プロセスを施策の集合ではなく「顧客の状態遷移」として捉え直し、認知から拡大までの境界ごとに、通過条件・引き継ぐ情報・確認SLA・差し戻し条件という4要素を定義する方法を整理します。マーケからのMQL引き渡し、営業からCSへの期待値の引き継ぎ、CSから営業・マーケへの逆方向の情報還元という3つの実務例も取り上げます。

読後は、自社の顧客状態遷移と部門責任を一枚のマップに整理し、どの境界から改善に着手すべきかを判断できるようになります。

この記事でわかること

売上プロセスを「施策」ではなく「顧客の状態遷移」として設計する考え方
マーケ・営業・CSの引き渡しで最低限定義すべき4つの要素
MQL→SQL、営業→CS、CS→営業・マーケという3方向の具体的な引き渡し設計例
引き渡しの健全性を測る指標と、現場でよく起きる失敗パターン
CRO・CMOが最初に着手すべき実務ステップ

はじめに
売上プロセスの不調は、部門の中ではなく「境界」で起きる
売上プロセスとは何か——Forditの定義
引き渡しで設計する売上プロセスの全体像
実務での引き渡し設計：3つの具体例
引き渡しの設計を検証する：指標と失敗パターン
CRO・CMOが最初に着手すべきこと
まとめ
Q&A
専門用語解説

はじめに

四半期の振り返り会議で、マーケはMQL目標を達成し、営業は商談化率を維持し、CSは解約率を許容範囲に収めている。それなのに、全社の受注も更新収益も期待どおりに積み上がっていない——

こうした場面に心当たりはないでしょうか。原因を探ろうとすると、各部門は口をそろえて「自分たちの数字は健全だ」と主張します。この噛み合わなさの多くは、部門の実力不足ではなく、部門と部門のあいだ、つまり顧客が担当者を跨いで引き継がれる瞬間の設計が抜け落ちていることに起因します。

売上プロセスの不調は、部門の中ではなく「境界」で起きる

結論から述べます。マーケ、営業、CSの数字がそれぞれ悪くないのに全社の成長が鈍い場合、原因の多くは各部門の実行力ではなく、部門と部門の「引き渡し」の設計不在にあります。売上プロセスとは、施策の集合ではなく、顧客がどの状態からどの状態へ移り、そのたびに誰が責任を引き継ぐかを定義した「状態遷移の設計図」です。

なぜ部門別KPIが健全でも売上が伸びないのか

CMOはMQL数と獲得単価を、CROは商談化率とパイプライン成長を、CS責任者は解約率とNPSを見ています。それぞれの指標が目標を達成していても、四半期の受注や更新収益が積み上がらないケースは珍しくありません。理由は単純で、指標は部門内の「入口から出口」しか測っておらず、部門を跨いだ瞬間の顧客の状態を誰も追っていないからです。

マーケが「良いリード」として渡したはずの顧客が、営業側では「まだ早い」と評価される。営業が受注した顧客が、CSに引き継がれた時点で期待値のずれが露呈する。こうした断絶は、個々の担当者の能力ではなく、引き渡しという業務そのものが設計されていないことに起因します。

「顧客の状態遷移」という共通言語がない組織の症状

現場でよく見られる症状を並べると、次のようになります。

営業がマーケ経由のリードを「質が低い」と評価するが、具体的な判定基準を誰も言語化できない
受注直後にCSへ引き継がれる情報が契約書と議事録メモ程度で、顧客がなぜ買ったのかが伝わらない
CSが把握した解約兆候や拡大余地が、営業やマーケの次の施策に反映されない
各部門が自部門のCRM運用に最適化し、顧客の全体像を持つ人が経営層以外にいない

これらは個別の問題に見えて、根は一つです。顧客の状態遷移を定義する共通言語と、遷移のたびに責任を明示する仕組みがない。だからこそ、CROやCMOが最初に手をつけるべきは、新しい施策の追加ではなく、既存の引き渡しを一枚の地図に描き直すことです。

売上プロセスとは何か——Forditの定義

Forditでは売上プロセスを次のように定義します。顧客が認知から契約、活用、拡大へと状態を変えていく過程を、部門の実行単位ではなく顧客の状態単位で設計し、状態が変わるたびに担当・情報・判定基準を明示した運用の仕組みです。

この定義の中心にあるのは「誰が何をやったか」ではなく「顧客がどう変わったか」です。マーケティングファネル、営業パイプライン、カスタマーサクセスのヘルススコアは、それぞれの部門から見た顧客の一断面にすぎません。売上プロセスは、これらの断面をつなぎ、部門をまたいでも顧客の状態と責任の所在が途切れないようにするための設計思想です。

マーケ・営業・CSに共通する3つの問い

部門が違っても、引き渡しの設計に必要な問いは共通しています。

今、顧客はどの状態にいるのか（認知・検討・商談・契約・活用・拡大・解約リスクのどこか）
次の状態へ進める、あるいは進めない条件は何か（数値基準だけでなく、文脈情報を含む）
状態が変わった瞬間、誰が何を確認し、何を受け取るのか

この3つに答えられない引き渡しは、担当者の勘と経験に依存した属人的な運用にとどまります。属人的な運用自体が悪いわけではありませんが、再現性がなく、検証もできないため、拡大期の組織では必ずどこかで破綻します。

引き渡しで設計する売上プロセスの全体像

状態遷移モデル：認知から拡大までの6段階

顧客の状態は、業種やビジネスモデルによって呼び方は変わりますが、概ね次の6段階で整理できます。

状態	主な担当	典型的な判断
認知	マーケティング	どのチャネルで、誰の課題に触れたか
検討	マーケティング〜営業	比較検討に値する情報を持っているか
商談	営業	予算・決裁・時期が揃っているか
契約	営業〜CS	何を期待して契約したか
活用	CS	期待通りの価値を得られているか
拡大・更新	CS〜営業〜マーケ	追加提案、紹介、解約リスクはどこにあるか

この表そのものは目新しいものではありません。重要なのは、段階の名称ではなく、段階が変わる「境界」に何を定義するかです。

引き渡しごとに定義すべき4つの要素

境界を設計する際、Forditでは次の4要素を最低限セットで定義することを推奨しています。

通過条件：次の状態に進めてよいと判断する基準（定量・定性の両方）
引き継ぐ情報：担当が変わっても顧客理解が途切れないための最小限の情報セット
確認のSLA：引き渡しを受けた側が、いつまでに確認・応答するかの取り決め
差し戻し条件：基準を満たさない場合に、どこへ、なぜ戻すかのルール

この4つが欠けると、引き渡しは「投げっぱなし」になります。特に差し戻し条件が存在しない組織では、質の低いリードや期待値のずれた契約が下流に流れ続け、営業やCSの疲弊として表面化します。逆に、この4要素さえ定義されていれば、部門間のコミュニケーションコストは大幅に下がります。

顧客段階そのものの定義をそろえる方法は、次の記事で確認できます。

顧客段階の設計：リードから顧客までの定義をそろえる方法

RevOps・マーケ担当者向けに、リードからMQL・SQL・商談・顧客までの定義を部門間でそろえる方法を、5段階モデルと実装手順で解説します。

実務での引き渡し設計：3つの具体例

マーケから営業へ：MQLからSQLへの通過条件

マーケが「反応が良かった」リードをそのまま営業に渡すと、営業側は自分の基準で再評価せざるを得ません。この二度手間を防ぐには、通過条件を行動データと企業属性の組み合わせで定義し、引き継ぐ情報に「顧客が何に反応したか」という文脈を含めることが有効です。

例えば、資料請求だけでなく、閲覧したコンテンツのテーマや、過去の接点履歴まで含めて渡すと、営業側の初回アプローチの精度が上がります。

営業からCSへ：契約時の期待値を持ち越す

受注はゴールではなく、活用フェーズの起点にすぎません。ここで重要なのは、契約書に書かれていない「顧客が本当に解決したかった課題」と「成功の定義」を、営業からCSへ明示的に引き継ぐことです。

多くの組織では、この情報が営業担当者の頭の中にしか残らず、CSは契約後にゼロから顧客理解をやり直しています。引き渡し時に1枚の「期待値シート」を挟むだけでも、初期の活用支援の質は大きく変わります。

CSからマーケ・営業へ：逆方向の引き渡しを設計する

売上プロセスの引き渡しは、前工程から後工程への一方向だけではありません。CSが把握する解約兆候や、想定外の使い方から生まれる拡大機会は、営業の再提案やマーケのメッセージ更新に直結する情報です。

CSからの逆方向の引き渡しが仕組み化されていない組織では、既存顧客の知見が眠ったまま、新規獲得のコストばかりが積み上がっていきます。

マーケティングから営業への引き渡し基準を具体化する際は、次の記事を参照してください。

マーケティングから営業へのリード引き渡し基準：実務で使える項目と運用例

CRO・CMO向けにマーケティングから営業へのリード引き渡し基準を解説。属性・行動・意思表示の3層基準とSLA、差し戻し、失注フィードバックの運用例を紹介します。

引き渡しの設計を検証する：指標と失敗パターン

境界を定義しただけでは、それが機能しているかどうかは分かりません。ここでは、引き渡しの健全性を測る指標と、実務でよく見かける失敗パターンを整理します。

引き渡しごとに見るべき指標

売上プロセス全体を一つの指標で評価しようとすると、どこで詰まっているかが見えなくなります。境界ごとに、次のような指標を分けて追うことをお勧めします。

境界	見るべき指標	詰まっているときのサイン
マーケ→営業	引き渡し後の一次接触率、差し戻し率	差し戻し理由が毎回同じ内容に偏る
営業→CS	期待値シートの提出率、初期オンボーディング完了率	CSからの問い合わせが契約内容の再確認ばかりになる
CS→営業・マーケ	拡大提案化率、解約兆候の共有件数	解約が起きてから初めて兆候の存在に気づく

重要なのは、これらの数値を「誰の成績」として評価するのではなく、「境界がうまく機能しているかどうかの体温計」として使うことです。数値が悪化したときに個人を責める運用にしてしまうと、現場は数値を良く見せる方向にしか動かなくなり、本来の目的である顧客理解の引き継ぎが形骸化します。

現場でよく見る4つの失敗パターン

引き渡し設計を進める中で、次のような失敗パターンが繰り返し起こります。事前に知っておくだけで、多くは回避できます。

基準はあるが、誰も更新しない：通過条件を一度決めたきり、市場やプロダクトの変化に合わせて見直されず、現場の実感とずれていく
情報は渡すが、要点が埋もれる：引き継ぐ情報量を増やしすぎて、受け取る側が結局重要な文脈を読み飛ばす
SLAはあるが、罰則も支援もない：期限だけ決めて、守れない理由（人員不足、優先順位の衝突）への対応策がない
差し戻しが心理的に難しい：差し戻すと関係部門との摩擦が生まれるため、基準を満たさない顧客も黙って下流に流してしまう

これらは、仕組みの設計不足だけでなく、部門間の力関係やコミュニケーション文化にも根ざしています。だからこそ、引き渡し設計は一度作って終わりではなく、定期的に見直す前提で運用する必要があります。

CRO・CMOが最初に着手すべきこと

現状の引き渡しを一枚のマップに書き出す

新しいツールやKPIを導入する前に、まず現状の状態遷移と引き渡しの実態を、部門横断のワークショップで一枚の図に書き出すことをお勧めします。理想形ではなく、今実際に何が起きているかを可視化することが目的です。ここで初めて、「誰も責任を持っていない境界」が具体的に見えてきます。

責任の空白を、役割ではなく機能で埋める

責任の空白が見つかったとき、新しい役職やチームを作ることが唯一の解ではありません。既存のメンバーの中で、通過条件・引き継ぐ情報・SLA・差し戻し条件という4要素を担える機能を、誰がどう分担するかを決めるほうが、多くの組織にとって現実的です。

一つの境界から検証し、全社展開は後にする

すべての引き渡しを同時に再設計しようとすると、必ず現場の反発を招きます。まずは影響の大きい一つの境界（多くの場合、マーケから営業への引き渡し）を選び、小さく試して、効果と負荷を確認したうえで他の境界へ広げていく進め方が、実務上は最も定着しやすいアプローチです。

検証の際は、「新しい基準に変えたら数字が良くなった」だけで満足しないことが肝心です。現場の担当者が実際にその基準を使って判断しているか、差し戻しが発生したときに気まずさなく処理できているかまで観察して初めて、その境界の設計が定着したと言えます。

CROやCMOが継続的に関与すべきなのは、この定着確認の部分です。仕組みを作った後、現場任せにせず、境界がきちんと機能しているかを四半期ごとに見直す場を持つことで、売上プロセス全体の精度は着実に上がっていきます。

まとめ

売上プロセスの不調は、多くの場合、マーケ・営業・CSそれぞれの実行力ではなく、部門を跨ぐ「引き渡し」の設計不在から生まれます。売上プロセスを施策の集合ではなく顧客の状態遷移として捉え、境界ごとに通過条件・引き継ぐ情報・確認SLA・差し戻し条件を定義することで、責任の空白は具体的に埋められます。最初の一歩は新しいツールの導入ではなく、現状の引き渡しを一枚のマップに書き出し、影響の大きい境界から小さく検証していくことです。