リードトゥキャッシュ(Lead to Cash)データテンプレート

Microsoft Dynamics 365 Sales
リードトゥキャッシュ(Lead to Cash)`データテンプレート`

リードトゥキャッシュ(Lead to Cash)データテンプレート

この`テンプレート`は、リードトゥキャッシュ(Lead to Cash)プロセス分析に不可欠な`データ`を収集するための構造化されたアプローチを提供します。重要な`属性`、主要な`アクティビティ`を概説し、この情報を抽出する方法に関するガイダンスを提供します。これらの推奨事項に従うことで、強力なプロセスインサイトを得るための包括的な`イベントログ`を構築できます。
  • `データ`収集に推奨される`属性`
  • プロセスディスカバリで追跡すべき主要な活動
  • `データ`抽出のための実用的なガイダンス
イベントログについて初めての方へ: プロセスマイニングのイベントログ作成方法.

リードから現金化までの属性

これらの`データ`フィールドは、完全な`イベントログ`を作成し、リードトゥキャッシュ(Lead to Cash)プロセスの詳細な分析を可能にするために不可欠です。
5 必須 8 推奨 6 任意
名前 説明
アクティビティ
ActivityName
営業プロセス内の特定の時点で発生したビジネス`アクティビティ`または`イベント`の名称。
説明

この属性は、リードトゥキャッシュ(Lead to Cash)プロセス内の特定のステップまたはマイルストーンを記述します。例えば「見積り作成(Quote Created)」や「入金(Payment Received)」などです。各アクティビティは、営業商談のライフサイクルにおける distinct なイベントを表します。

これらのアクティビティのシーケンスと頻度を分析することが、プロセスマイニングコアです。これにより、実際のプロセスフローが明らかになり、一般的および代替の経路(バリアント)を特定し、手戻りやボトルネックが発生する箇所を特定するのに役立ちます。この分析は、プロセスの順守状況と効率性を理解するために不可欠です。

その重要性

プロセスマップ内のステップを定義します。これは、非効率性や逸脱を発見するための全てのプロセスマイニング分析の基盤となります。

取得元

この属性は、Dynamics 365内の商談、見積り、注文、および請求書エンティティに関連するさまざまなイベントから派生します。ステータス変更やレコード作成イベントを標準化されたアクティビティ名にマッピングするためのロジックがしばしば必要となります。

商談作成顧客に見積り送付済み契約締結済み入金確認済み
営業商談
SalesOpportunity
リードトゥキャッシュ(Lead to Cash)プロセスの主要な`ケース`IDとして機能する、営業商談の一意の識別子。
説明

営業商談IDは、営業ファネルを進行する各潜在的な販売を独自に識別します。これは、商談の初期作成から最終的な支払回収まで、関連するすべてのアクティビティを結びつける中心的な糸口として機能します。

プロセスマイニングにおいて、この属性は各営業ケースエンドツーエンドのジャーニーを再構築するための基本的な要素です。これにより、プロセスフロー全体を分析し、総サイクルタイムを計算し、商談が辿る異なる経路を比較することが可能になります。最終的には、リード認定から支払回収までの非効率性やボトルネックの特定を可能にします。

その重要性

これは、すべてのプロセスイベントを連結する不可欠なケースIDであり、各営業取引の全ライフサイクルを追跡することを可能にします。

取得元

これは商談エンティティの主キーであり、通常はopportunityidフィールドです。

OPP-01532-A3B1C7OPP-01533-F8D2E5OPP-01534-G9H3I4
開始時刻
ActivityStartTime
特定のアクティビティまたはイベントが開始されたことを示すタイムスタンプです。
説明

この属性は、アクティビティが発生した日時を記録します。これは、プロセスマイニングイベントを時系列に並べ、期間を計算するために使用される主要な時間要素です。

開始時刻(Start Time)は、アクティビティ間のサイクルタイムの計算、遅延の特定、および全体的なプロセスパフォーマンスの測定を含む、すべての時間ベースの分析に不可欠です。これにより、動的なプロセスアニメーションの作成が可能になり、作業の時間的分布を理解するのに役立ちます。

その重要性

このタイムスタンプは、イベントの順序付けや、サイクルタイム、待機時間などのすべてのパフォーマンスメトリックの計算に不可欠です。

取得元

これは通常、関連するエンティティ(商談、見積り、SalesOrder、請求書)のcreatedonまたはmodifiedon``タイムスタンプであり、アクティビティに対応します。

2023-04-15T10:00:00Z2023-04-25T14:30:00Z2023-05-10T11:20:00Z
ソースシステム
SourceSystem
データを抽出した元システム。
説明

この属性は、イベントデータが発生したソースアプリケーションを識別します。このプロセスの場合、一貫してMicrosoft Dynamics 365 Salesになります。

複数の統合システムを持つ環境では、このフィールドはデータリネージとトラブルシューティングにとって重要です。これにより、データのコンテキストを理解し、分析が正しいソースからの情報に基づいていることを保証するのに役立ちます。

その重要性

データソースに関する重要なコンテキストを提供し、データガバナンス、検証、統合管理に不可欠です。

取得元

これは静的なであり、データ抽出プロセス中にレコードのソースを特定するために設定されるべきです。

Microsoft Dynamics 365 Sales
最終データ更新
LastDataUpdate
ソースシステムからの最終`データ`更新の`タイムスタンプ`。
説明

この属性は、Microsoft Dynamics 365 Salesからデータが最後に抽出され、プロセスマイニングツールに読み込まれた日時を示します。これは、分析されているデータの鮮度を示す参照点を提供します。

データの適時性を理解することは、分析と結論が関連性があり、最新の情報に基づいていることを保証するために不可欠です。これにより、ユーザーはインサイトを信頼し、プロセスの現在の状態に基づいて情報に基づいた意思決定を行うことができます。

その重要性

データの鮮度を示し、分析が最新かつ意思決定に関連していることを保証します。

取得元

このタイムスタンプは、データ抽出およびローディングプロセス自体によって生成されます。

2024-07-27T02:00:00Z2024-07-28T02:00:00Z
リードソース
LeadSource
初期リードが生成されたソース。
説明

この属性は、営業商談を開始したリードの発生源を示します。例えば「Web」、「パートナー」、「展示会」、または「広告」などです。これは、異なるマーケティングチャネルとリード生成戦略の有効性を追跡します。

プロセスマイニングにおいて、リードソース別に分析することは、「リード変換パフォーマンス(Lead Conversion Performance)」ダッシュボードにとって不可欠です。これにより、各チャネルのリードから商談への変換率を計算し、どのソースが最も価値のあるリードを生み出すか、または最も速い認定時間を持つかを特定するのに役立ちます。これらのインサイトは、マーケティング費用と営業活動の焦点を最適化するために極めて重要です。

その重要性

質の高いリードを生成する様々なマーケティングチャネルのパフォーマンスを評価するのに役立ち、リード転換分析を直接的にサポートします。

取得元

これは通常、リードエンティティleadsourcecodeフィールドであり、リード認定時に商談に転送されます。

`Web`取引先展示会紹介
商談ステータス
OpportunityStatus
受注または失注など、営業商談の最終結果。
説明

この属性は、営業商談の最終状態を捕捉します。主な結果は通常、「受注(Won)」で成功した販売を示し、「失注(Lost)」で取引が成立しなかったことを示します。

結果別に分析することは、どのようなプロセスパターンが成功につながり、どのようなパターンが失敗につながるかを理解するために不可欠です。ケースをステータスでフィルタリングすることで、受注した取引と失注した取引でサイクルタイム、アクティビティユーザーの関与を比較できます。これは商談勝率KPIを計算し、肯定的な結果と相関する行動を特定するために重要です。

その重要性

成功と失敗の結果を区別し、比較分析を通じて、どのようなプロセス行動が成功につながるかを特定することを可能にします。

取得元

これは、商談エンティティstatecode(ステータス)フィールドおよびstatuscode(ステータス理由)フィールドに対応します。

受注失注進行中
商談担当者
OwnerId
商談を担当する営業担当者または`ユーザー`。
説明

商談担当者(Opportunity Owner)は、Microsoft Dynamics 365 Sales内で営業商談の管理と推進を担当する個別のユーザーです。このユーザーは通常、ケースに関連するアクティビティの大部分に責任を負います。

担当者ごとにプロセスを分析することは、異なる営業担当者、チーム、または部署間のパフォーマンスを比較するのに役立ちます。これにより、トップパフォーマーのベストプラクティスが明らかになり、他のユーザーへのコーチングの機会を特定し、ワークロードディストリビューションがプロセス効率と成果にどのように影響するかを理解することができます。

その重要性

ユーザーまたはチーム別のパフォーマンス分析を可能にし、トップパフォーマーを特定し、特定の個人またはグループに関連する問題を診断するのに役立ちます。

取得元

これは、ユーザーまたはチームレコードにリンクされる、商談エンティティowneridフィールドです。

John DoeJane SmithEMEA営業チーム
商談金額
OpportunityValue
営業商談の見積もりまたは実際の金銭的価値。
説明

この属性は、営業商談に関連する潜在的または最終的な収益を表します。これは見積もり額として始まり、取引が成立した際に実際の契約額に更新される場合があります。

すべての商談が同じではないため、これは分析にとって重要な側面です。取引規模に基づいてプロセスをセグメント化することで、企業はより大きな取引が異なるプロセスに従うか、またはクローズに時間がかかるかどうかを確認できます。また、ビジネスの高価値セグメントに対してプロセス改善活動の優先順位付けをすることも可能になります。

その重要性

財務コンテキストを提供し、取引規模に基づく分析や、高価値な商談に対するプロセス改善の優先順位付けを可能にします。

取得元

通常、商談エンティティestimatedvalue(見積もり収益)やactualvalue(実績収益)などのフィールドで見つかります。

50000.00125000.0025000.00
営業ステージ
SalesStage
定義された営業プロセスパイプライン内における商談のステージ。
説明

営業ステージ(Sales Stage)は、「見込み客評価(Qualify)」、「開発(Develop)」、「提案(Propose)」、「クローズ(Close)」など、商談が現在置かれている特定のフェーズを表します。これらのステージは、営業パイプラインと進捗のハイレベルな概要を提供します。

プロセスマイニングタイムスタンプから詳細なアクティビティを導出する一方で、営業ステージは貴重なビジネスコンテキストを提供します。これは「全体的な営業サイクル時間分析(Overall Sales Cycle Time Analysis)」ダッシュボードで使用され、プロセスをセグメント化し、各主要ステージでどれだけの時間が費やされているかを理解するのに役立ちます。これにより、どのステージが最も長く、どこで商談が停滞しやすいかを特定できます。

その重要性

商談の進捗に関するビジネスコンテキストを提供し、営業パイプラインの各フェーズで費やされた時間の分析を可能にします。

取得元

この情報は、商談エンティティに関連付けられたビジネスプロセスフローのstepnameフィールドから導出されます。

1-Qualify2-Develop3-Propose4-Close
地域
Region
顧客が所在する地理的な地域またはテリトリー。
説明

この属性は、営業商談に関連する地理的エリアを指定します。例えば、「北米」、「EMEA」、「APAC」などです。これはしばしば顧客の住所情報から導出されます。

地域は比較分析のための重要な側面です。「請求書生成と配送時間(Invoice Generation And Delivery Time)」のようなダッシュボードで使用され、プロセスパフォーマンスに地域ごとの差異があるかどうかを確認します。このような分析により、現地の規制、チームのパフォーマンス、または市場状況によって引き起こされる違いが明らかになり、地理的にターゲットを絞ったプロセス改善に役立つ情報となります。

その重要性

プロセスの地理的セグメンテーションを可能にし、パフォーマンス、コンプライアンス、顧客行動における地域差を強調します。

取得元

このデータは通常、関連するアカウントまたは連絡先エンティティaddress1_countryやカスタムの「地域」フィールドに保存されます。

北米EMEAAPACLATAM
終了日時
ActivityEndTime
特定の`アクティビティ`または`イベント`が完了したことを示す`タイムスタンプ`。多くの場合、原子`イベント`の開始時刻(`Start Time`)と同じです。
説明

終了時刻(End Time)は、アクティビティの完了を示します。「請求書生成」のような瞬時のイベントでは、終了時刻は開始時刻(Start Time)と同じであることがよくあります。手動レビューのステップのような測定可能な期間を持つアクティビティの場合、このタイムスタンプは作業が完了した時点を捉えます。

この属性は、個々のアクティビティの処理時間を計算するために使用されます。あるアクティビティの終了時刻を次のアクティビティの開始時刻と比較することで、プロセス内の実作業時間(処理時間)とアイドル時間(待機時間)の両方を分析することが可能です。

その重要性

活動の処理時間計算を可能にし、実作業時間と待機時間を区別することで、プロセスパフォーマンスのより詳細な視点を提供します。

取得元

瞬時的なイベントの場合、これは開始時間と同じです。期間を伴う活動の場合、後続のタイムスタンプまたはステータス変更から導出する必要がある場合があります。

2023-04-15T10:00:00Z2023-04-25T15:00:00Z2023-05-10T11:25:00Z
顧客
CustomerId
営業商談に関連付けられた顧客アカウント。
説明

この属性は、商談が追求されている見込み顧客または既存顧客を識別します。これは営業プロセスをCRMシステム内の特定のアカウントにリンクさせます。

顧客または顧客セグメント別にプロセスを分析することで、異なる種類の顧客が営業プロセスとどのように相互作用するかについて、より深く理解することができます。これにより、特定の顧客がより長いサイクルタイムを持つか、より多くの手戻りを必要とするか、またはより高い勝率を持つかを明らかにできます。この情報は、営業アプローチを調整し、顧客関係を管理するために価値があります。

その重要性

特定の顧客または顧客セグメントのプロセスパフォーマンスの分析を可能にし、営業戦略の調整に役立ちます。

取得元

これは商談エンティティcustomeridルックアップフィールドであり、アカウントまたは連絡先レコードにリンクされます。

Contoso LtdアドベンチャーワークスFabrikam, Inc.
処理時間
ProcessingTime
個々のアクティビティの期間。終了時間と開始時間の差として計算されます。
説明

処理時間(アクティビティ期間)は、特定のタスクに費やされた実作業時間を測定します。これはアクティビティ終了時刻からアクティビティ開始時刻を減算して計算されます。

このメトリックは、実作業時間とアイドル/待機時間を区別するのに役立ちます。分析では、プロセス全体でどの特定のアクティビティが最も時間がかかっているかを特定するために使用されます。処理時間の長いアクティビティを特定することは、業務の効率化とリソース効率の向上に向けた重要な一歩です。

その重要性

活動の実作業時間を測定し、どの特定のタスクが最も時間がかかり、最適化の対象となるかを特定するのに役立ちます。

取得元

これは、ActivityEndTimeからActivityStartTimeを減算して導出される計算フィールドです。

8640036000
割引率
DiscountPercentage
見積りまたは注文に適用される割引率。
説明

この属性は、営業見積りまたは注文に適用される割引総額を定価の割合として捕捉します。これは、営業利益率と価格設定の規律を監視するための主要なメトリックです。

「見積り管理と割引コンプライアンスQuote Management And Discount Compliance)」ダッシュボードは、この属性を使用して割引行動を分析します。割引の分布を可視化することで、経営陣は過剰または不正な割引を特定し、割引が勝率に与える影響を評価し、価格設定ポリシーへのコンプライアンスを確保することができます。

その重要性

価格戦略と割引コンプライアンスの分析に不可欠であり、割引が収益性と勝率に与える影響を理解するのに役立ちます。

取得元

Quote ('discountpercentage') および SalesOrder ('discountpercentage') エンティティにあります。

0.050.100.15
契約形態
ContractType
「新規ビジネス」や「更新」など、販売に関連する法的な契約の種類。
説明

この属性は、営業商談に関連する契約を分類します。新規顧客契約と更新契約またはアップセル契約のように、異なる種類の契約では、異なる承認および署名プロセスに従う場合があります。

「契約締結サイクルタイム(Contract Signing Cycle Time)」ダッシュボードは、この属性を使用して分析をセグメント化します。異なる契約タイプの署名時間を比較することで、ビジネスは更新契約が新規契約よりも迅速に処理されるか、または複雑なカスタム契約が大幅な遅延を引き起こすかどうかを特定できます。これは、契約管理プロセスに対する改善目標を定めるのに役立ちます。

その重要性

特定の種類の契約がプロセスに遅延を引き起こしているかどうかを特定することで、契約締結フェーズの分析と最適化に役立ちます。

取得元

これは、ビジネスニーズに特有のものであるため、商談または契約エンティティのカスタムフィールドである可能性が高いです。

新規ビジネス更新拡張基本サービス契約
手戻り
IsRework
ある活動が同じケース内で繰り返しまたは手戻りであるかを示すフラグ。
説明

このブーリアン属性は、単一の営業商談内でアクティビティまたは一連のアクティビティが繰り返される時期を識別する計算フィールドです。例えば、見積りが作成され、拒否された後、新しい見積りが作成された場合、2番目の「見積り作成(Quote Created)」アクティビティは手戻りとしてフラグ付けされます。

手戻りの特定は、「プロセスバリアントと手戻り分析(Process Variant And Rework Analysis)」ダッシュボードにとって極めて重要です。ループや繰り返しステップを強調することで、プロセスにおける非効率性の程度を定量化するのに役立ちます。手戻りがどこで、なぜ発生するのかを理解することは、プロセスを簡素化し、無駄な労力を削減し、営業サイクルを加速するための最初の一歩です。

その重要性

プロセスの非効率性やループを直接的に示し、手戻りのコストを定量化し、プロセス簡素化の機会を特定するのに役立ちます。

取得元

これは計算された属性です。プロセスマイニングツール内で、各ケースアクティビティのシーケンスを分析することで導出されます。

truefalse
支払条件
PaymentTerms
請求書に合意された支払条件(例:Net 30、Net 60など)を示します。
説明

この属性は、顧客が提供された商品やサービスに対して支払うべき条件を規定します。これは、請求書発行後の支払い期間を定義します。

「支払回収サイクル分析(Payment Collection Cycle Analysis)」ダッシュボードにとって、この属性は不可欠です。これにより、合意された条件に基づいて支払回収時間をセグメント化でき、どの顧客が慢性的に支払いが遅れているか、特定の支払条件がより長い回収サイクルと関連しているかどうかを特定することが可能になります。これは、売掛金プロセスを最適化し、キャッシュフローを管理するのに役立ちます。

その重要性

支払いパフォーマンス分析の基準を提供し、遅延支払いの特定や回収戦略の有効性評価に役立ちます。

取得元

これは通常、請求書エンティティに保存され、多くの場合paymenttermscodeという名前のフィールドにあります。

支払条件:正味30日支払条件:正味60日受領時支払い
製品`カテゴリ`
ProductCategory
商談で販売される製品またはサービスのカテゴリ。
説明

この属性は、営業商談に関連する主要な製品またはサービスを分類します。例えば、「ハードウェア」、「ソフトウェア」、または「プロフェッショナルサービス」などです。

製品カテゴリ別にプロセスを分析することは、「受注処理パフォーマンス(Order Fulfillment Performance)」ダッシュボードにとって不可欠です。これにより、特定の種類の製品がより長い営業サイクルを持つか、異なる履行プロセスを持つか、または低い勝率を持つかを判断するのに役立ちます。このインサイトは、効率を向上させるために、異なる製品ラインに対する専門的な営業プロセスにつながる可能性があります。

その重要性

販売されているものに基づいたパフォーマンス分析を可能にし、特定の製品に固有のプロセスバリエーションやボトルネックを明らかにすることができます。

取得元

この情報は通常、商談に関連付けられた商談製品(opportunityproductエンティティから入手できます。

Cloud Servicesオンプレミスソフトウェアコンサルティングサービス
必須 推奨 任意

リードから現金化までの活動

これらは、リードトゥキャッシュ(Lead to Cash)ジャーニーの明確な全体像を提供するために、`イベントログ`で捕捉すべき重要なプロセスステップとマイルストーンです。
7 推奨 7 任意
アクティビティ 説明
入金確認済み
請求書の全額支払いが顧客から受領されました。これは、Invoiceレコードのステータスが「支払い済み」とマークされたときに捕捉されます。
その重要性

これは収益実現を表す重要な財務上のマイルストーンです。請求書送付から入金までの時間を分析することで、支払回収サイクルを最適化できます。

取得元

Invoiceレコードの「statecode」が「Paid」(値2)に変更されたときのタイムスタンプから推測されます。

取得

請求書のstatecodeが「支払い済み」にアップデートされたときに、modifiedon``タイムスタンプを使用します。

イベントタイプ inferred
商談作成
特定の潜在的な取引に対する営業プロセスの開始を示します。このイベントは、新しい営業商談レコードが作成されたときに捕捉され、多くの場合、リードの資格認定の結果として発生します。
その重要性

これは、リードトゥキャッシュ(Lead to Cash)プロセス分析の主要な開始アクティビティです。これにより、総営業サイクルタイムを測定し、リード変換の有効性を分析できます。

取得元

これは、商談テーブルの商談レコードの作成タイムスタンプから取得される明示的なイベントです。

取得

商談エンティティcreatedon``タイムスタンプを使用します。

イベントタイプ explicit
商談受注
営業商談が成功裏にクローズされ、販売が成立したことを示します。この`イベント`は、商談のステータスが「受注」に変更されたときに記録されます。
その重要性

これは、営業プロセスの主要な成功終了アクティビティです。勝率、成功した取引の営業サイクルタイム、および全体の営業パフォーマンスを計算するために使用されます。

取得元

Opportunityレコードの「statecode」が「Won」(値1)に変更されたときのタイムスタンプから推測されます。これは、関連する見積もりまたは注文が処理される際に自動的に行われることがよくあります。

取得

商談のstatuscodeが「受注(Won)」に設定されたときに、actualclosedateフィールドまたはmodifiedon``タイムスタンプを使用します。

イベントタイプ inferred
商談失注
営業商談が不成功に終わり、販売が成立せずにクローズされたことを示します。これは、商談のステータスが「失注」に変更されたときに記録されます。
その重要性

これは主要な失敗終了アクティビティです。これらのケースを分析することで、失注の理由、営業ファネルにおける離脱ポイント、および競合の有効性を特定するのに役立ちます。

取得元

Opportunityレコードの「statecode」が「Lost」(値2)に変更されたときのタイムスタンプから推測されます。

取得

商談のstatuscodeが「失注(Lost)」に設定されたときに、actualclosedateフィールドまたはmodifiedon``タイムスタンプを使用します。

イベントタイプ inferred
見積り作成済み
製品またはサービスに関する正式な見積書が顧客向けに生成されました。これは、新しいQuoteレコードが作成され、営業商談にリンクされたときに捕捉されます。
その重要性

これは概念的な提案から正式なオファーへの移行を示します。この時点から見積り承認までの時間は、見積り管理効率を測定するために重要です。

取得元

親のOpportunityへのルックアップ関係を持つQuoteエンティティの新規レコードの作成日として記録される明示的なイベント。

取得

商談IDにリンクされた見積りエンティティcreatedon``タイムスタンプを使用します。

イベントタイプ explicit
販売注文作成済み
販売された製品またはサービスの履行を管理するために、システムで販売注文が正式に作成されます。これは、通常、「成約済み」の見積もりを注文に変換することによって生成される明示的なイベントです。
その重要性

これは営業から運用または履行への正式な引き渡しを示します。受注処理サイクルタイムと販売後の効率を測定するための出発点となります。

取得元

これは、親商談にリンクされているSalesOrderレコードの作成タイムスタンプから取得される明示的なイベントです。

取得

SalesOrder(注文)エンティティcreatedon``タイムスタンプを使用します。

イベントタイプ explicit
顧客により見積り承認済み
顧客が見積書に提示された条件と価格に正式に合意したことを示します。これは通常、営業担当者が見積りレコードのステータスを「受注」に更新した際に記録されます。
その重要性

これは顧客からの確固たるコミットメントを示す重要なマイルストーンです。見積りから受注への変換率や平均見積り承認時間を測定するために不可欠です。

取得元

Quoteレコードの「statecode」が「Won」(値2)に更新されたときのタイムスタンプから推測されます。

取得

見積りのstatecodeが「受注(Won)」に変更されたときに、modifiedon``タイムスタンプを使用します。

イベントタイプ inferred
契約締結済み
両当事者によって法的拘束力のある契約が締結され、合意が最終決定されました。このイベントは、多くの場合、商談または関連する契約エンティティへの手動更新であり、電子署名連携によってトリガーされる可能性があります。
その重要性

このアクティビティは、契約最終化サイクルタイムを追跡するために重要です。この段階での遅延は、収益予測やプロジェクト開始に大きな影響を与える可能性があります。

取得元

商談に「契約締結日」のような日付フィールドが入力されたか、ステータスが変更されたことから推測されます。これにはカスタマイズが必要となる場合があります。

取得

特定のステータス変更のタイムスタンプ、または契約関連フィールドが入力された日付を使用します。

イベントタイプ inferred
注文完了
販売注文内の全ての製品が出荷されたか、全てのサービスが顧客に提供されました。これは、SalesOrderレコードのステータスが「履行済み」または同様の状態に更新されたときに捕捉されます。
その重要性

このアクティビティはプロセスの配送部分を完了します。受注処理パフォーマンスを分析するための重要なマイルストーンであり、請求処理のトリガーとなります。

取得元

SalesOrderレコードの「statecode」が「Fulfilled」(値3)に変更されたときのタイムスタンプから推測されます。

取得

SalesOrderのstatecodeが「履行済み」にアップデートされたときに、modifiedon``タイムスタンプを使用します。

イベントタイプ inferred
要件特定済み
営業チームが顧客の`ニーズ`を把握し、理解した時点を示します。これは通常、営業担当者がビジネスプロセスフローのステージを更新したり、商談ステータスを変更したりすることで記録されます。
その重要性

このステージを追跡することで、初期接触から実現可能な提案に移行するまでにかかる時間を特定できます。ここでの遅延は、ディスカバリーコールやリソースの可用性の問題を示している可能性があります。

取得元

商談のビジネスプロセスフローのステージが「開発」または「提案」フェーズに変更されたか、カスタムステータスフィールドが更新されたことから推測されます。ステージ変更のタイムスタンプが使用されます。

取得

商談エンティティまたは関連するビジネスプロセスフローエンティティ内のstageidへの変更を追跡します。

イベントタイプ inferred
解決策提示済み
この`アクティビティ`は、正式なソリューションまたは提案が見込み顧客に提示されたことを示します。これは通常、商談がライフサイクルの「提案」ステージに移行したときに推定されます。
その重要性

この活動の前後に費やされた時間を分析することは、ソリューション設計と提案生成ステップの効率を評価するのに役立ちます。繰り返しのインスタンスは、営業サイクルにおける手戻りを示します。

取得元

商談レコードのステータス変更、または関連するビジネスプロセスフローの「提案」ステージへの進展から推測されます。

取得

商談エンティティ上のステータスまたはステージ変更のタイムスタンプを使用します。

イベントタイプ inferred
請求書生成済み
処理済みの販売注文に基づいて、顧客請求書が作成されました。これは、新しい請求書レコードがシステムに作成されたときに記録される明示的なイベントです。
その重要性

このアクティビティは、請求および支払回収サイクルを開始します。受注処理から請求書生成までの時間は、請求プロセス効率の主要な指標です。

取得元

これは、SalesOrderにリンクされている請求書レコードの作成タイムスタンプから取得される明示的なイベントです。

取得

請求書エンティティcreatedon``タイムスタンプを使用します。

イベントタイプ explicit
顧客に見積り送付済み
生成された見積書が、顧客によるレビューのために正式に送付されたことを示します。この`イベント`は通常、見積りレコードのステータスが「有効」に変更されたときに推定されます。
その重要性

このアクティビティは、顧客のレビューと交渉の時間を計測し始めます。見積り承認サイクルを分析し、顧客応答の遅延を特定するための重要なデータポイントです。

取得元

Quoteレコードの「statecode」が「Active」に変更されたときのタイムスタンプから推測されます。

取得

監査履歴を監視するか、Quoteの「statecode」が1(Active)になったときにワークフローによって更新されるタイムスタンプフィールドを使用します。

イベントタイプ inferred
顧客へ請求書送付済み
請求書が支払いのために顧客に送付されたことを示します。これは通常、請求書レコードのステータス変更から推定されます。
その重要性

これは支払条件の計測を開始し、売上債権回転日数(DSO)を測定する最初のステップです。ここでの遅延は、キャッシュフローに直接影響します。

取得元

Invoiceエンティティのステータス変更から推測されます。標準の「送信済み」ステータスはありませんが、ワークフローはこのアクションでカスタムフィールドまたはステータスを更新することがよくあります。

取得

請求書レコード上のカスタム「送付日」フィールド、またはステータス理由の変更を追跡します。

イベントタイプ inferred
推奨 任意

抽出ガイド

Microsoft Dynamics 365 Salesからデータを取得する方法