情報システム 2026.05.06 PageView 9

SalesCloudの「商談ステージ」では見えない、受注後の進捗の正体

SalesCloudの「商談ステージ」では見えない、受注後の進捗の正体

商談ステージが「100% Closed Won」になった瞬間にデータが止まる構造的問題と、その先の運用設計

はじめに:商談ステージは「受注前」のための道具

Salesforceを導入した経営者から、こうした声を聞くことがあります。「商談ステージは見えるが、その先の進捗が見えない」「Closed Wonになった案件が今どこにいるか分からない」「結局、Salesforceは営業の道具で、Deliveryには使えない」——。

これは Sales Cloud の限界ではなく、設計思想の問題です。Sales Cloud の商談オブジェクトは「受注前」の管理に最適化されており、Closed Wonになった瞬間にその役目は終わります。本記事では、商談ステージで見えない受注後の進捗の正体と、その先の運用設計を解説します。

この記事でわかること

  • 商談ステージが「受注前」までしかカバーできない3つの構造的理由
  • 受注後に発生する6つの「見えない進捗」
  • SalesCloudの先に必要な進捗管理レイヤー
  • Salesforce上で受注後の進捗を可視化する3つの設計選択

第1章:商談ステージが「受注前」までしかカバーできない理由

理由① Sales Cloudの商談オブジェクトは「受注確度」のためにある

商談ステージ(Stage)は、もともと営業の確度予測のための仕組みです。「初回提案 → 提案中 → 見積提出 → クロージング → Closed Won」という流れは、受注に至るまでの確度を段階的に表現するモデルです。

このモデルは受注後の進捗(着手→開発→検収→納品→請求)をカバーするために作られていません。「Closed Won」が最終ステージである以上、その先のデータは商談オブジェクトには乗らないのが設計上の前提です。

理由② 受注後のデータモデルが標準では存在しない

Salesforceの標準オブジェクト(取引先・商談・リード・キャンペーン・ケース)には、案件タスク・工数・原価・要員アサイン・検収条件・納品物といった受注後の業務データを保持するためのオブジェクトが含まれていません。

これらは別途カスタムオブジェクトを設計するか、AppExchangeアプリで補完する必要があります。

理由③ レポート・ダッシュボードも商談中心

Salesforce標準のレポート・ダッシュボードは、商談・売上・パイプラインを軸に設計されています。受注後の「進行中案件の粗利率」「タスク進捗率」「メンバー稼働率」を出そうとしても、必要なデータが標準オブジェクトに存在しないため、根本的に計算できません。

整理

商談ステージは「受注前」の確度予測のための道具。受注後は別のレイヤー(案件・タスク・工数・原価)が必要であり、Sales Cloud単体ではカバーできない。これは限界ではなく、設計上の責務分担。

第2章:受注後に発生する「6つの見えない進捗」

見えない進捗① タスク進捗率

案件全体の何%が完了しているか、どのタスクが遅延しているか——これは商談ステージでは表現できません。受注後の進捗管理には、案件配下のWBSタスクをトラッキングするレイヤーが必要です。

見えない進捗② 工数消化率と粗利率

想定工数のうち何%を消化したか、現時点の実績原価から逆算した粗利率は何%か——これも商談ステージでは見えません。日次の工数入力+フルコスト単価×タスク連動の集計が必要です。

見えない進捗③ 仕様変更の累計影響

案件中盤で発生した仕様変更が、受注時の想定粗利を何%削っているか——これは「変更管理タスク」と「金額換算ロジック」が組み合わさって初めて見えます。

見えない進捗④ メンバー稼働率(チャージ率)

プロジェクトに張り付いている各メンバーが、実は社内会議や別案件のヘルプで稼働の半分を奪われている——これは商談オブジェクトでは絶対に見えません。

見えない進捗⑤ 検収条件の達成状況

商談時に合意した検収条件・納品物リストが、現時点でどこまで達成されているか——これも標準では追跡できません。検収条件オブジェクトと達成判定の仕組みが必要です。

見えない進捗⑥ 顧客側のレスポンス遅延

顧客のレビュー待ち、決裁待ち、フィードバック待ちでプロジェクトが止まっている時間——これは「ボール所在管理」を伴うタスクボードがないと記録されません。

第3章:SalesCloudの先に必要な進捗管理レイヤー

レイヤー① 案件オブジェクト

商談Closed Won後に立ち上がる「実行可能な案件レコード」を保持するレイヤー。受注金額・期間・主担当・想定工数・想定粗利を商談から継承し、進行中の実績データを記録します。

レイヤー② WBSタスクオブジェクト

案件配下のタスクを階層的に管理するレイヤー。「プロジェクト→マイルストン→タスク」の3階層が標準で、各タスクに予算工数・実績工数・進捗率・担当者・期限を持たせます。

レイヤー③ 工数オブジェクト

メンバー × 日 × タスクで工数を記録するレイヤー。15分単位の入力粒度・稼働種別の分類・タスクとの自動紐づけが要件です。

レイヤー④ 原価集計レイヤー

メンバーごとのフルコスト単価と工数を掛け合わせて原価を算出するレイヤー。商談から継承した受注金額と突き合わせて、案件粗利率を進行中にリアルタイムで集計します。

第4章:Salesforce上で受注後の進捗を可視化する3つの設計選択

選択① Salesforce標準+カスタムオブジェクトでゼロから設計

カスタムオブジェクトとApex/Flowで案件・タスク・工数・原価のレイヤーをゼロから構築する選択。柔軟性は高いが、設計と保守のコストが大きく、汎用機能(ガント/カレンダー/ヒートマップ)はすべて自前で作る必要があります。

選択② AppExchangeのプロジェクト管理アプリを導入

プロジェクト管理に特化したネイティブアプリを導入する選択。商談・取引先と同じデータモデル上にタスク・工数・原価が乗るため、最短期間で受注後の進捗可視化を立ち上げられます。

選択③ 他SaaSとAPI連携

Asana/Jira/Backlog等の他SaaSと連携する選択。各部門が既に使っているツールを活かせる一方、データはSalesforceの外側に存在するためレポート統合に制約があります。

原則

「商談ステージで見えない」のはバグではなく仕様。受注後の進捗を可視化したいなら、Sales Cloudを補完する明確なレイヤーをSalesforce上に乗せること。AppExchangeネイティブアプリが最短ルート。

第5章:Task Relayで商談クローズ後の進捗を可視化する

Task Relayは、Salesforce上で動作するプロジェクト&工数管理SaaSです。商談Closed Won後に立ち上がる案件のタスク・工数・原価を、商談・取引先と同じデータモデルに乗せます。

  • 商談オブジェクトと案件オブジェクトを連結したデータモデル
  • WBSタスク・工数・原価のすべてが商談から継承された案件配下に集約
  • Salesforce標準のレポート・ダッシュボードで案件粗利・進捗率・チャージ率が出せる
  • Sales Cloud資産を活かしたまま、受注後の進捗を可視化
見たい指標 SalesCloud標準のみ SalesCloud + Task Relay
商談ステージ
受注金額
案件タスク進捗率 不可
工数消化率 不可
進行中粗利率 不可
チャージ率 不可
仕様変更累計影響 不可
検収条件達成度 不可

まとめ:商談ステージはゴールではなく、受注後管理の出発点

商談ステージで「Closed Won」になった瞬間、Sales Cloudの責務は終わります。その先の進捗を可視化するには、案件・タスク・工数・原価という別のレイヤーをSalesforce上に乗せる必要があります。

まずは自社のSalesforceで「商談ステージはClosed Wonだが、その後どうなっているか分からない」案件をリストアップしてみてください。それらが、本記事の6つの見えない進捗が必要になる候補です。

関連記事

商談ステージの先で、
案件の進捗を見える化する。

Sales Cloudの限界を補完するTask Relayが、受注後のタスク・工数・原価をSalesforce上で完結させます。30分のデモで実機をご紹介します。

Task Relay の詳細を知りたい方へ

プロジェクト管理を、Salesforce で完結。

30分のオンラインデモで、Task Relay の操作感を体験できます。Excelテンプレートも無料でDL可能。