リードトゥキャッシュ(Lead to Cash)データテンプレート
リードトゥキャッシュ(Lead to Cash)データテンプレート
- `データ`収集に推奨される`属性`
- プロセスディスカバリで追跡すべき主要な活動
- `データ`抽出のための実用的なガイダンス
リードから現金化までの属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ
ActivityName
|
営業プロセス内の特定の時点で発生したビジネス`アクティビティ`または`イベント`の名称。 | ||
|
説明
この これらの
その重要性
プロセスマップ内のステップを定義します。これは、非効率性や逸脱を発見するための全てのプロセスマイニング分析の基盤となります。
取得元
この
例
商談作成顧客に見積り送付済み契約締結済み入金確認済み
|
|||
|
営業商談
SalesOpportunity
|
リードトゥキャッシュ(Lead to Cash)プロセスの主要な`ケース`IDとして機能する、営業商談の一意の識別子。 | ||
|
説明
営業商談IDは、営業ファネルを進行する各潜在的な販売を独自に識別します。これは、商談の初期作成から最終的な支払回収まで、関連するすべての
その重要性
これは、すべてのプロセス
取得元
これは商談
例
OPP-01532-A3B1C7OPP-01533-F8D2E5OPP-01534-G9H3I4
|
|||
|
開始時刻
ActivityStartTime
|
特定のアクティビティまたはイベントが開始されたことを示すタイムスタンプです。 | ||
|
説明
この 開始時刻(
その重要性
この
取得元
これは通常、関連する
例
2023-04-15T10:00:00Z2023-04-25T14:30:00Z2023-05-10T11:20:00Z
|
|||
|
ソースシステム
SourceSystem
|
データを抽出した元システム。 | ||
|
説明
この 複数の統合システムを持つ環境では、このフィールドは
その重要性
取得元
これは静的な
例
Microsoft Dynamics 365 Sales
|
|||
|
最終データ更新
LastDataUpdate
|
ソースシステムからの最終`データ`更新の`タイムスタンプ`。 | ||
|
説明
この
その重要性
データの鮮度を示し、分析が最新かつ意思決定に関連していることを保証します。
取得元
この
例
2024-07-27T02:00:00Z2024-07-28T02:00:00Z
|
|||
|
リードソース
LeadSource
|
初期リードが生成されたソース。 | ||
|
説明
この
その重要性
質の高いリードを生成する様々なマーケティングチャネルのパフォーマンスを評価するのに役立ち、リード転換分析を直接的にサポートします。
取得元
これは通常、リード
例
`Web`取引先展示会紹介
|
|||
|
商談ステータス
OpportunityStatus
|
受注または失注など、営業商談の最終結果。 | ||
|
説明
この 結果別に分析することは、どのようなプロセスパターンが成功につながり、どのようなパターンが失敗につながるかを理解するために不可欠です。
その重要性
成功と失敗の結果を区別し、比較分析を通じて、どのようなプロセス行動が成功につながるかを特定することを可能にします。
取得元
これは、商談
例
受注失注進行中
|
|||
|
商談担当者
OwnerId
|
商談を担当する営業担当者または`ユーザー`。 | ||
|
説明
商談担当者( 担当者ごとにプロセスを分析することは、異なる営業担当者、
その重要性
ユーザーまたはチーム別のパフォーマンス分析を可能にし、トップパフォーマーを特定し、特定の個人またはグループに関連する問題を診断するのに役立ちます。
取得元
これは、
例
John DoeJane SmithEMEA営業チーム
|
|||
|
商談金額
OpportunityValue
|
営業商談の見積もりまたは実際の金銭的価値。 | ||
|
説明
この すべての商談が同じではないため、これは分析にとって重要な側面です。取引規模に基づいてプロセスをセグメント化することで、企業はより大きな取引が異なるプロセスに従うか、またはクローズに時間がかかるかどうかを確認できます。また、ビジネスの高価値セグメントに対してプロセス改善活動の優先順位付けをすることも可能になります。
その重要性
財務コンテキストを提供し、取引規模に基づく分析や、高価値な商談に対するプロセス改善の優先順位付けを可能にします。
取得元
通常、商談
例
50000.00125000.0025000.00
|
|||
|
営業ステージ
SalesStage
|
定義された営業プロセスパイプライン内における商談のステージ。 | ||
|
説明
営業ステージ(
その重要性
商談の進捗に関するビジネスコンテキストを提供し、営業パイプラインの各フェーズで費やされた時間の分析を可能にします。
取得元
この情報は、商談
例
1-Qualify2-Develop3-Propose4-Close
|
|||
|
地域
Region
|
顧客が所在する地理的な地域またはテリトリー。 | ||
|
説明
この 地域は比較分析のための重要な側面です。「請求書生成と配送時間(
その重要性
プロセスの地理的セグメンテーションを可能にし、パフォーマンス、コンプライアンス、顧客行動における地域差を強調します。
取得元
この
例
北米EMEAAPACLATAM
|
|||
|
終了日時
ActivityEndTime
|
特定の`アクティビティ`または`イベント`が完了したことを示す`タイムスタンプ`。多くの場合、原子`イベント`の開始時刻(`Start Time`)と同じです。 | ||
|
説明
終了時刻( この
その重要性
活動の処理時間計算を可能にし、実作業時間と待機時間を区別することで、プロセスパフォーマンスのより詳細な視点を提供します。
取得元
瞬時的なイベントの場合、これは開始時間と同じです。期間を伴う活動の場合、後続のタイムスタンプまたはステータス変更から導出する必要がある場合があります。
例
2023-04-15T10:00:00Z2023-04-25T15:00:00Z2023-05-10T11:25:00Z
|
|||
|
顧客
CustomerId
|
営業商談に関連付けられた顧客アカウント。 | ||
|
説明
この 顧客または顧客セグメント別にプロセスを分析することで、異なる種類の顧客が営業プロセスとどのように相互作用するかについて、より深く理解することができます。これにより、特定の顧客がより長いサイクルタイムを持つか、より多くの手戻りを必要とするか、またはより高い勝率を持つかを明らかにできます。この情報は、営業アプローチを調整し、顧客関係を管理するために価値があります。
その重要性
特定の顧客または顧客セグメントのプロセスパフォーマンスの分析を可能にし、営業戦略の調整に役立ちます。
取得元
これは商談
例
Contoso LtdアドベンチャーワークスFabrikam, Inc.
|
|||
|
処理時間
ProcessingTime
|
個々のアクティビティの期間。終了時間と開始時間の差として計算されます。 | ||
|
説明
処理時間( この
その重要性
活動の実作業時間を測定し、どの特定のタスクが最も時間がかかり、最適化の対象となるかを特定するのに役立ちます。
取得元
これは、
例
8640036000
|
|||
|
割引率
DiscountPercentage
|
見積りまたは注文に適用される割引率。 | ||
|
説明
この 「見積り管理と割引
その重要性
価格戦略と割引コンプライアンスの分析に不可欠であり、割引が収益性と勝率に与える影響を理解するのに役立ちます。
取得元
Quote ('discountpercentage') および SalesOrder ('discountpercentage') エンティティにあります。
例
0.050.100.15
|
|||
|
契約形態
ContractType
|
「新規ビジネス」や「更新」など、販売に関連する法的な契約の種類。 | ||
|
説明
この 「契約締結サイクルタイム(
その重要性
特定の種類の契約がプロセスに遅延を引き起こしているかどうかを特定することで、契約締結フェーズの分析と最適化に役立ちます。
取得元
これは、ビジネス
例
新規ビジネス更新拡張基本サービス契約
|
|||
|
手戻り
IsRework
|
ある活動が同じケース内で繰り返しまたは手戻りであるかを示すフラグ。 | ||
|
説明
このブーリアン 手戻りの特定は、「プロセスバリアントと手戻り分析(
その重要性
プロセスの非効率性やループを直接的に示し、手戻りのコストを定量化し、プロセス簡素化の機会を特定するのに役立ちます。
取得元
これは計算された
例
truefalse
|
|||
|
支払条件
PaymentTerms
|
請求書に合意された支払条件(例:Net 30、Net 60など)を示します。 | ||
|
説明
この 「支払回収サイクル分析(
その重要性
支払いパフォーマンス分析の基準を提供し、遅延支払いの特定や回収戦略の有効性評価に役立ちます。
取得元
これは通常、請求書
例
支払条件:正味30日支払条件:正味60日受領時支払い
|
|||
|
製品`カテゴリ`
ProductCategory
|
商談で販売される製品またはサービスのカテゴリ。 | ||
|
説明
この 製品カテゴリ別にプロセスを分析することは、「受注処理パフォーマンス(
その重要性
販売されているものに基づいたパフォーマンス分析を可能にし、特定の製品に固有のプロセスバリエーションやボトルネックを明らかにすることができます。
取得元
この情報は通常、商談に関連付けられた商談製品(
例
Cloud Servicesオンプレミスソフトウェアコンサルティングサービス
|
|||
リードから現金化までの活動
| アクティビティ | 説明 | ||
|---|---|---|---|
|
入金確認済み
|
請求書の全額支払いが顧客から受領されました。これは、Invoiceレコードのステータスが「支払い済み」とマークされたときに捕捉されます。 | ||
|
その重要性
これは収益実現を表す重要な財務上のマイルストーンです。請求書送付から入金までの時間を分析することで、支払回収サイクルを最適化できます。
取得元
Invoiceレコードの「statecode」が「Paid」(値2)に変更されたときのタイムスタンプから推測されます。
取得
請求書の
イベントタイプ
inferred
|
|||
|
商談作成
|
特定の潜在的な取引に対する営業プロセスの開始を示します。このイベントは、新しい営業商談レコードが作成されたときに捕捉され、多くの場合、リードの資格認定の結果として発生します。 | ||
|
その重要性
これは、リードトゥキャッシュ(Lead to Cash)プロセス分析の主要な開始
取得元
これは、商談テーブルの商談レコードの作成
取得
商談
イベントタイプ
explicit
|
|||
|
商談受注
|
営業商談が成功裏にクローズされ、販売が成立したことを示します。この`イベント`は、商談のステータスが「受注」に変更されたときに記録されます。 | ||
|
その重要性
これは、営業プロセスの主要な成功終了
取得元
Opportunityレコードの「statecode」が「Won」(値1)に変更されたときのタイムスタンプから推測されます。これは、関連する見積もりまたは注文が処理される際に自動的に行われることがよくあります。
取得
商談の
イベントタイプ
inferred
|
|||
|
商談失注
|
営業商談が不成功に終わり、販売が成立せずにクローズされたことを示します。これは、商談のステータスが「失注」に変更されたときに記録されます。 | ||
|
その重要性
これは主要な失敗終了
取得元
Opportunityレコードの「statecode」が「Lost」(値2)に変更されたときのタイムスタンプから推測されます。
取得
商談の
イベントタイプ
inferred
|
|||
|
見積り作成済み
|
製品またはサービスに関する正式な見積書が顧客向けに生成されました。これは、新しいQuoteレコードが作成され、営業商談にリンクされたときに捕捉されます。 | ||
|
その重要性
これは概念的な提案から正式なオファーへの移行を示します。この時点から見積り承認までの時間は、見積り管理効率を測定するために重要です。
取得元
親のOpportunityへのルックアップ関係を持つQuoteエンティティの新規レコードの作成日として記録される明示的なイベント。
取得
商談IDにリンクされた見積り
イベントタイプ
explicit
|
|||
|
販売注文作成済み
|
販売された製品またはサービスの履行を管理するために、システムで販売注文が正式に作成されます。これは、通常、「成約済み」の見積もりを注文に変換することによって生成される明示的なイベントです。 | ||
|
その重要性
これは営業から運用または履行への正式な引き渡しを示します。受注処理サイクルタイムと販売後の効率を測定するための出発点となります。
取得元
これは、親商談にリンクされているSalesOrderレコードの作成
取得
SalesOrder(注文)
イベントタイプ
explicit
|
|||
|
顧客により見積り承認済み
|
顧客が見積書に提示された条件と価格に正式に合意したことを示します。これは通常、営業担当者が見積りレコードのステータスを「受注」に更新した際に記録されます。 | ||
|
その重要性
これは顧客からの確固たるコミットメントを示す重要なマイルストーンです。見積りから受注への変換率や平均見積り承認時間を測定するために不可欠です。
取得元
Quoteレコードの「statecode」が「Won」(値2)に更新されたときのタイムスタンプから推測されます。
取得
見積りの
イベントタイプ
inferred
|
|||
|
契約締結済み
|
両当事者によって法的拘束力のある契約が締結され、合意が最終決定されました。このイベントは、多くの場合、商談または関連する契約エンティティへの手動更新であり、電子署名連携によってトリガーされる可能性があります。 | ||
|
その重要性
この
取得元
商談に「契約締結日」のような日付フィールドが入力されたか、ステータスが変更されたことから推測されます。これにはカスタマイズが必要となる場合があります。
取得
特定のステータス変更の
イベントタイプ
inferred
|
|||
|
注文完了
|
販売注文内の全ての製品が出荷されたか、全てのサービスが顧客に提供されました。これは、SalesOrderレコードのステータスが「履行済み」または同様の状態に更新されたときに捕捉されます。 | ||
|
その重要性
この
取得元
SalesOrderレコードの「statecode」が「Fulfilled」(値3)に変更されたときのタイムスタンプから推測されます。
取得
SalesOrderの
イベントタイプ
inferred
|
|||
|
要件特定済み
|
営業チームが顧客の`ニーズ`を把握し、理解した時点を示します。これは通常、営業担当者がビジネスプロセスフローのステージを更新したり、商談ステータスを変更したりすることで記録されます。 | ||
|
その重要性
このステージを追跡することで、初期接触から実現可能な提案に移行するまでにかかる時間を特定できます。ここでの遅延は、ディスカバリーコールやリソースの可用性の問題を示している可能性があります。
取得元
商談のビジネスプロセスフローのステージが「開発」または「提案」フェーズに変更されたか、カスタムステータスフィールドが更新されたことから推測されます。ステージ変更のタイムスタンプが使用されます。
取得
商談
イベントタイプ
inferred
|
|||
|
解決策提示済み
|
この`アクティビティ`は、正式なソリューションまたは提案が見込み顧客に提示されたことを示します。これは通常、商談がライフサイクルの「提案」ステージに移行したときに推定されます。 | ||
|
その重要性
この活動の前後に費やされた時間を分析することは、ソリューション設計と提案生成ステップの効率を評価するのに役立ちます。繰り返しのインスタンスは、営業サイクルにおける手戻りを示します。
取得元
商談レコードのステータス変更、または関連するビジネスプロセスフローの「提案」ステージへの進展から推測されます。
取得
商談
イベントタイプ
inferred
|
|||
|
請求書生成済み
|
処理済みの販売注文に基づいて、顧客請求書が作成されました。これは、新しい請求書レコードがシステムに作成されたときに記録される明示的なイベントです。 | ||
|
その重要性
この
取得元
これは、SalesOrderにリンクされている請求書レコードの作成
取得
請求書
イベントタイプ
explicit
|
|||
|
顧客に見積り送付済み
|
生成された見積書が、顧客によるレビューのために正式に送付されたことを示します。この`イベント`は通常、見積りレコードのステータスが「有効」に変更されたときに推定されます。 | ||
|
その重要性
この
取得元
Quoteレコードの「statecode」が「Active」に変更されたときのタイムスタンプから推測されます。
取得
監査履歴を監視するか、Quoteの「statecode」が1(Active)になったときにワークフローによって更新されるタイムスタンプフィールドを使用します。
イベントタイプ
inferred
|
|||
|
顧客へ請求書送付済み
|
請求書が支払いのために顧客に送付されたことを示します。これは通常、請求書レコードのステータス変更から推定されます。 | ||
|
その重要性
これは支払条件の計測を開始し、売上債権回転日数(DSO)を測定する最初のステップです。ここでの遅延は、
取得元
Invoiceエンティティのステータス変更から推測されます。標準の「送信済み」ステータスはありませんが、ワークフローはこのアクションでカスタムフィールドまたはステータスを更新することがよくあります。
取得
請求書レコード上のカスタム「送付日」フィールド、またはステータス理由の変更を追跡します。
イベントタイプ
inferred
|
|||