1. 結論 ――“誰の手柄か”を決め切れればレポートは組める
-
One‑Time Business（例：BtoB SaaS、プロジェクト系）
→ 受注＝商談成立。商談（Opportunity）の所有者をそのまま KPI/KGI に使えば OK。 -
Run‑Rate Business（例：連続生産の製造業、消費財卸）
→ 受注件数は商談より多い。商談は「導入フェーズ」の管理に留め、実売上は 注文（Order） または外部システムで捕捉する。注文を誰の成果にするか？の考えで実装手段が変わる。
2. シナリオ別：担当営業をどう紐付けるか
| シナリオ | 推奨オブジェクト / 設計 | 実装ポイント |
|---|---|---|
|
① 1アカウント＝1担当 （専任営業制） |
取引先 (Account) を担当者の所有物にする |
- 標準項目 所有者 をそのまま使用 - レポートは Account, Opportunity, Order いずれも「所有者」で集計 |
|
② 1製品＝1担当 （プロダクト営業制） |
商品 (Product2) を担当者所有にする |
- Product2.OwnerId を編集可にしておく- 商談商品／注文商品にカスタムユーザー項目を作成し、 親商品の所有者 の値をフローでコピーすることで担当変更時に対応できる |
|
③ 同一アカウントに複数担当 （案件単位の都度アサイン） |
商談 (Opportunity) を担当者所有にする |
- One‑Time Business ならこれで終わり - Run‑Rate Business だと「導入者 ≠ リピート受注者」問題が残る |
| ④ Run‑Rate × 複数担当 × 非製品担当制 |
価格表エントリ (PricebookEntry) に「担当者」カスタム項目を追加。取引先毎にカスタム価格表を作成。 |
- PricebookEntry__c.Sales_Rep__c (Lookup<User>) を追加- 注文商品作成時、レコードトリガフローで PricebookEntry__c.Sales_Rep__c → OrderItem.Sales_Rep__c にコピー- レポートは OrderItem をローデータに Sales_Rep__c で集計 |
💡 ポイント：Run‑Rate では「最初に導入させた人の功績を、後続の注文にも乗せるか？」をまず経営側で合意させる。ロジックが決まれば実装は難しくない。
3. 実装ステップ（ケース④の例）
-
価格表エントリに担当者フィールドを追加
- 型：
Lookup(User)、API 名：Sales_Rep__c
- 型：
-
注文商品に担当者フィールドを追加
- 型：同上、API 名：
Sales_Rep__c
- 型：同上、API 名：
-
レコードトリガフロー（オブジェクト＝Order Item）
- トリガ：作成のみ
- 取得：
[PricebookEntry].Sales_Rep__c - 代入：
$Record.Sales_Rep__c ← {取得値}
-
レポートタイプ
- 主オブジェクト：Order Products
- 必要列：
Sales_Rep__c,Order.AccountId,TotalPrice,Quantity,CreatedDateetc.
4. 実装で合わせて用意しておきたいフロー（一覧）
※ 本記事ではロジック詳細を割愛し、必要なフロー／オートメーションの全体像だけを整理します。
詳細実装は別記事で順次解説予定。
| # | 目的 | トリガ & 処理概要 | 備考 |
|---|---|---|---|
| 1 | 注文作成時に取引先専用の価格表を自動選択 |
Order レコード生成時： Lookup 先 Account.Default_Pricebook__c → Order.Pricebook2Id へ代入 |
価格表が複数ある環境の必須基盤 |
| 2 | 注文商品に担当営業をコピー |
Order Item 作成時：PricebookEntry.Sales_Rep__c → OrderItem.Sales_Rep__c
|
本記事の KGI 集計ロジックの肝 |
| 3 | 商談成立後に価格表エントリへ最終単価を転記 |
Opportunity が Won になったら： 関連 OpportunityLineItem の金額 → PricebookEntry.ListPrice へ書込み |
“アカウント専用単価” を PricebookEntry に残す |
| 4 | 価格改定時の履歴スナップショット |
PricebookEntry 更新時： 旧 ListPrice と更新者情報を履歴オブジェクトへ INSERT |
データ監査＆過去受注金額の整合性維持 |
| 5 | マルチ通貨下での Null ガード | いずれかの BEFORE フローにて：ISBLANK(PricebookEntry.Id) ならフロー停止 |
通貨別 PricebookEntry が存在しない場合の保険 |
| 6 | 権限監視のアラート | 担当外ユーザーが PricebookEntry を更新したら Chatter 通知 | 権限セットが緩い組織向けの低コスト監査 |
| 7 | 定期バッチ：担当者未設定レコードの洗い出し | スケジュールフロー | レポートだけでも良いが自動リマインド推奨 |
5. まとめ
- Run‑Rate Business の KGI 集計は「どの場合で誰の成果にするか」を明確化するところが全て。
- シンプルなルックアップ＋フローだけで、大抵のシナリオはカバー可能。
- 迷ったら「商談で導入を追跡、注文で売上を追跡」と割り切り、
売上側に 担当者を写しておく――これが一番事故が少ない。