リードから入金までのデータテンプレート
リードから入金までのデータテンプレート
- データ収集に推奨される属性
- プロセスディスカバリーで追跡する主要なアクティビティ
- データ抽出に関する実務ガイド
リードから入金までの属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ
ActivityName
|
営業プロセスの特定の時点で発生した業務アクティビティまたはイベントの名称です。 | ||
|
説明
リードから入金までのプロセスにおける特定のステップまたはマイルストーンを示す属性です。たとえば、「Quote Created」や「Payment Received」などが該当します。各アクティビティは、営業案件のライフサイクルにおける個別のイベントを表します。 これらのアクティビティの順序と発生頻度を分析することが、プロセスマイニングの中心です。実際のプロセスフローを明らかにし、一般的な経路と代替経路(バリアント)を特定するとともに、手戻りやボトルネックが発生する箇所を示します。プロセスの遵守状況と効率を理解するうえで欠かせない分析です。
重要な理由
プロセスマップ上のステップを定義します。非効率や逸脱を発見する、すべてのプロセスマイニング分析の基盤です。
入手先
通常は、Dynamics 365内のOpportunity、Quote、Order、Invoiceエンティティに関連するさまざまなイベントから導出します。ステータス変更やレコード作成イベントを標準化されたアクティビティ名に対応付けるロジックが必要になる場合があります。
例
営業案件の作成顧客への見積送付契約締結入金
|
|||
|
営業案件
SalesOpportunity
|
リードから入金までのプロセスにおける主要なケースIDとなる、営業案件の一意の識別子です。 | ||
|
説明
Sales Opportunity IDは、営業ファネルを進む各見込み商談を一意に識別します。営業案件の作成から最終的な入金回収まで、関連するすべてのアクティビティをつなぐ中心的な識別子です。 プロセスマイニングでは、各営業案件のエンドツーエンドの経路を再現するための基本的な属性です。プロセス全体の流れを分析し、サイクル全体の所要時間を算出するとともに、営業案件ごとに異なる経路を比較できます。これにより、リード評価から入金までの非効率やボトルネックを特定できます。
重要な理由
すべてのプロセスイベントをつなぐ必須のケースIDであり、各営業案件のライフサイクル全体を追跡できます。
入手先
Opportunityエンティティの主キーで、通常は「opportunityid」項目です。
例
OPP-01532-A3B1C7OPP-01533-F8D2E5OPP-01534-G9H3I4
|
|||
|
開始時刻
ActivityStartTime
|
特定のアクティビティまたはイベントが開始した時点を示すタイムスタンプです。 | ||
|
説明
アクティビティが発生した日付と時刻を記録する属性です。プロセスマイニングでは、イベントを時系列に並べ、所要時間を算出するために使用する主要な時間項目です。 開始時刻は、アクティビティ間のサイクルタイムの算出、遅延の特定、プロセス全体のパフォーマンス測定など、時間に基づくすべての分析に欠かせません。動的なプロセスアニメーションの作成にも利用でき、作業が時間的にどのように分布しているかを把握できます。
重要な理由
イベントの順序付けや、サイクルタイム、待機時間などすべてのパフォーマンス指標の算出に欠かせないタイムスタンプです。
入手先
通常は、アクティビティに対応する関連エンティティ(Opportunity、Quote、SalesOrder、Invoice)の「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」「Partner」「Trade Show」「Advertisement」などが該当します。さまざまなマーケティングチャネルやリード獲得施策の効果を追跡できます。 プロセスマイニングでは、「リード転換パフォーマンス」ダッシュボードの分析に欠かせません。チャネルごとのリードから営業案件への転換率を算出し、価値の高いリードを生み出すソースや、評価までの時間が短いソースを特定できます。マーケティング費用や営業活動の重点配分を最適化するうえで重要な情報です。
重要な理由
さまざまなマーケティングチャネルが質の高いリードを生み出す効果を評価し、リード転換の分析を直接支援します。
入手先
通常はLeadエンティティの「leadsourcecode」項目です。リードの評価時にOpportunityへ引き継がれます。
例
Webパートナー展示会紹介
|
|||
|
営業ステージ
SalesStage
|
定義された営業プロセスのパイプラインにおける営業案件のステージです。 | ||
|
説明
営業ステージは、営業案件が「Qualify」「Develop」「Propose」「Close」など、どの段階にあるかを示します。営業パイプラインの進捗を大まかに把握できます。 プロセスマイニングではタイムスタンプから詳細なアクティビティを導出しますが、営業ステージは重要な業務上の背景情報を提供します。「営業サイクル全体の所要時間分析」ダッシュボードでプロセスを区分し、主要ステージごとの所要時間を把握するために使用します。最も時間がかかるステージや、営業案件が滞りやすい箇所の特定に役立ちます。
重要な理由
営業案件の進捗に関する業務上の背景情報を提供し、営業パイプラインの各段階にかかる時間を分析できます。
入手先
Opportunityエンティティに関連付けられたBusiness Process Flowの「stepname」項目から導出します。
例
1:見込み判定2:案件育成3:提案4:成約
|
|||
|
営業案件のステータス
OpportunityStatus
|
WonやLostなど、営業案件の最終的な結果です。 | ||
|
説明
営業案件の最終状態を記録する属性です。主な結果は、販売が成立したことを示す「Won」と、商談が成立しなかったことを示す「Lost」です。 結果別の分析は、成功につながるプロセスパターンと失敗につながるパターンを理解するうえで基本となります。ステータスでケースを絞り込むことで、成約案件と失注案件のサイクルタイム、アクティビティ、ユーザーの関与を比較できます。営業案件の成約率KPIを算出し、良い結果につながる行動を特定するうえでも重要です。
重要な理由
成功と失敗の結果を区別し、成約につながるプロセス上の行動を比較分析できます。
入手先
Opportunityエンティティの「statecode」(Status)および「statuscode」(Status Reason)項目に対応します。
例
受注失注進行中
|
|||
|
営業案件の担当者
OwnerId
|
営業案件を担当する営業担当者またはユーザーです。 | ||
|
説明
Opportunity Ownerは、Microsoft Dynamics 365 Salesで営業案件の管理と進行を担当するユーザーです。通常、このユーザーがケースに関連するアクティビティの大半を担当します。 担当者別にプロセスを分析すると、営業担当者、チーム、部門間のパフォーマンスを比較できます。成果の高い担当者のベストプラクティスを見つけ、他の担当者へのコーチング機会を特定するとともに、業務量の配分がプロセスの効率や成果に与える影響を把握できます。
重要な理由
ユーザーまたはチーム単位でパフォーマンスを分析できます。成果の高い担当者を特定し、特定の個人やグループに関する問題を診断するのに役立ちます。
入手先
Opportunityエンティティの「ownerid」項目で、UserまたはTeamレコードに関連付けられています。
例
John DoeJane SmithEMEA営業チーム
|
|||
|
営業案件の金額
OpportunityValue
|
営業案件の見積金額または実際の金額です。 | ||
|
説明
営業案件に関連する見込み収益または最終収益を表す属性です。見積金額として始まり、成約時に実際の契約金額へ更新される場合があります。 すべての営業案件が同じ価値を持つわけではないため、分析上重要な切り口です。案件規模でプロセスを分けると、大型案件に異なるプロセスが適用されているか、成約までにより長い時間がかかっているかを確認できます。高額案件に対する改善施策を優先する際にも役立ちます。
重要な理由
財務面の背景情報を提供し、案件規模に基づく分析や、高額な営業案件を対象とした改善施策の優先順位付けを可能にします。
入手先
通常は、Opportunityエンティティの「estimatedvalue」(見積収益)または「actualvalue」(実績収益)などの項目に格納されています。
例
50000.00125000.0025000.00
|
|||
|
地域
Region
|
顧客が所在する地理的な地域または営業テリトリーです。 | ||
|
説明
営業案件に関連する地理的な地域を示す属性です。「North America」「EMEA」「APAC」などが該当し、顧客の住所情報から導出することがよくあります。 地域は比較分析における重要な切り口です。「請求書の作成・送付時間」などのダッシュボードで、地域によるプロセスパフォーマンスの違いを確認するために使用します。地域の規制、チームのパフォーマンス、市場環境などによる差異を明らかにし、地域に応じた改善施策の検討に役立ちます。
重要な理由
地域別にプロセスを区分し、パフォーマンス、コンプライアンス、顧客行動の違いを明らかにできます。
入手先
このデータは通常、関連するAccountまたはContactエンティティの「address1_country」やカスタムの「Region」フィールドなどに保存されます。
例
北米EMEAAPACLATAM
|
|||
|
終了時刻
ActivityEndTime
|
特定のアクティビティまたはイベントが完了した時点を示すタイムスタンプです。単発のイベントでは、開始時刻と同じになることがよくあります。 | ||
|
説明
アクティビティの完了時点を示します。「Invoice Generated」のような瞬時に発生するイベントでは、終了時刻と開始時刻が同じになることがよくあります。手動レビューのように一定の所要時間があるアクティビティでは、作業が完了した時点を記録します。 この属性は、個々のアクティビティの処理時間を算出するために使用します。あるアクティビティの終了時刻と次のアクティビティの開始時刻を比較することで、プロセス内の実作業時間と待機時間を分析できます。
重要な理由
アクティビティの処理時間を算出し、実作業時間と待機時間を区別できます。プロセスパフォーマンスをより詳細に把握できます。
入手先
瞬時に発生するイベントでは開始時刻と同じです。所要時間のあるアクティビティでは、後続のタイムスタンプまたはステータス変更から導出する場合があります。
例
2023-04-15T10:00:00Z2023-04-25T15:00:00Z2023-05-10T11:25:00Z
|
|||
|
顧客
CustomerId
|
営業案件に関連付けられた顧客アカウントです。 | ||
|
説明
営業案件の対象となる見込み顧客または既存顧客を識別する属性です。営業プロセスをCRMシステム内の特定のアカウントに関連付けます。 顧客または顧客セグメント別にプロセスを分析すると、さまざまな顧客層が営業プロセスにどのように関わっているかを詳しく把握できます。特定の顧客でサイクルタイムが長い、手戻りが多い、成約率が高いといった傾向を明らかにできます。営業アプローチの調整や顧客関係の管理に役立つ情報です。
重要な理由
特定の顧客または顧客セグメントにおけるプロセスパフォーマンスを分析し、営業戦略を調整できます。
入手先
Opportunityエンティティの「customerid」参照項目で、AccountまたはContactレコードに関連付けられています。
例
Contoso LtdAdventure WorksFabrikam, Inc.
|
|||
|
再作業かどうか
IsRework
|
同じケース内で、アクティビティが繰り返しまたは再作業に該当するかを示すフラグです。 | ||
|
説明
このブール型属性は、1つの営業案件内でアクティビティまたは一連のアクティビティが繰り返されたことを特定する計算フィールドです。たとえば、見積が作成され、却下された後に新しい見積が作成された場合、2回目の「Quote Created」アクティビティが再作業として記録されます。 再作業の特定は、「Process Variant And Rework Analysis」ダッシュボードに欠かせません。ループや手順の繰り返しを明らかにし、プロセスの非効率がどの程度発生しているかを定量化できます。再作業がどこで、なぜ発生しているかを把握することが、プロセスの簡素化、無駄な作業の削減、営業サイクルの短縮に向けた第一歩です。
重要な理由
プロセスの非効率やループを直接特定し、再作業のコストを定量化するとともに、プロセスを簡素化できる箇所を見つけ出せます。
入手先
これは計算属性です。各ケースのアクティビティの順序を分析し、プロセスマイニングツール内で算出します。
例
truefalse
|
|||
|
割引率
DiscountPercentage
|
見積または注文に適用された割引率です。 | ||
|
説明
この属性は、販売見積または注文に提示された割引総額を、定価に対する割合として記録します。販売マージンと価格設定の規律を監視するための重要な指標です。 「Quote Management And Discount Compliance」ダッシュボードでは、この属性を使って割引の設定状況を分析します。割引の分布を可視化することで、過度な割引や承認されていない割引を特定し、割引が受注率に与える影響を評価するとともに、価格設定ポリシーへの準拠を確認できます。
重要な理由
価格戦略と割引に関するコンプライアンスを分析するうえで重要です。割引が収益性や受注率に与える影響を把握できます。
入手先
Quote(「discountpercentage」)エンティティとSalesOrder(「discountpercentage」)エンティティにあります。
例
0.050.100.15
|
|||
|
契約タイプ
ContractType
|
販売に関連する法的契約の種類です。「New Business」や「Renewal」などがあります。 | ||
|
説明
この属性は、営業案件に関連する契約を分類します。新規顧客との契約、更新、アップセルなど、契約の種類によって承認や署名のプロセスが異なる場合があります。 「Contract Signing Cycle Time」ダッシュボードでは、この属性を使って分析を分けます。契約タイプごとの署名にかかる時間を比較することで、更新契約が新規契約より早く処理されているか、複雑な個別契約が大幅な遅延を招いていないかを確認できます。契約管理プロセスの改善箇所を絞り込むのに役立ちます。
重要な理由
特定の契約タイプがプロセスの遅延を引き起こしていないかを特定し、契約締結フェーズの分析と改善に役立ちます。
入手先
業務要件に固有の項目であるため、OpportunityまたはContractエンティティのカスタムフィールドとして設定される可能性が高いです。
例
新規ビジネス更新拡張基本サービス契約
|
|||
|
支払条件
PaymentTerms
|
Net 30やNet 60など、請求書に設定された合意済みの支払条件です。 | ||
|
説明
この属性は、提供した商品やサービスの代金を顧客が支払う条件を指定します。請求書の発行後、いつまでに支払う必要があるかを定めるものです。 「Payment Collection Cycle Analysis」ダッシュボードでは、この属性が欠かせません。合意した条件別に回収期間を分けて分析できるため、支払いが慢性的に遅れている顧客や、特定の支払条件が回収期間の長期化と関連しているかを特定できます。売掛金管理プロセスの改善とキャッシュフロー管理に役立ちます。
重要な理由
支払パフォーマンスを分析する基準となり、支払遅延の特定や回収施策の有効性評価に役立ちます。
入手先
通常はInvoiceエンティティに保存され、「paymenttermscode」という名前のフィールドに格納されていることが多いです。
例
30日払い60日払い受領時払い
|
|||
|
製品カテゴリ
ProductCategory
|
商談で販売される製品またはサービスのカテゴリです。 | ||
|
説明
この属性は、営業案件に関連する主な製品またはサービスを分類します。例として、「Hardware」、「Software」、「Professional Services」などがあります。 製品カテゴリ別にプロセスを分析することは、「Order Fulfillment Performance」ダッシュボードに欠かせません。特定の製品タイプで営業サイクルが長くなっていないか、履行プロセスが異なっていないか、受注率が低くなっていないかを確認できます。この分析結果をもとに、製品ラインごとに営業プロセスを最適化し、効率を高めることができます。
重要な理由
販売対象にもとづくパフォーマンス分析が可能になり、特定の製品に固有のプロセス差異やボトルネックを明らかにできます。
入手先
通常は、Opportunityに関連付けられたOpportunity Product(opportunityproduct)エンティティから取得できます。
例
クラウドサービスオンプレミスソフトウェアコンサルティングサービス
|
|||
リードから入金までのアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
入金
|
顧客から請求書の全額を受領したことを示します。Invoiceレコードのステータスが「Paid」になった時点で記録します。 | ||
|
重要な理由
収益化を示す重要な財務上のマイルストーンです。請求書送付から入金までの期間を分析すると、入金回収サイクルを最適化できます。
入手先
Invoiceレコードの「statecode」が「Paid」(値2)に変更された時点のタイムスタンプから推定します。
取得
Invoiceの「statecode」が「Paid」に更新された時点の「modifiedon」タイムスタンプを使用します。
イベントタイプ
inferred
|
|||
|
営業案件の作成
|
特定の見込み商談における営業プロセスの開始を示します。通常、リードの評価後に新しい営業案件レコードが作成された時点で、このイベントを記録します。 | ||
|
重要な理由
リードから入金までのプロセス分析における、主要な開始アクティビティです。営業サイクル全体の所要時間を測定し、リード転換の有効性を分析できます。
入手先
Opportunityテーブルのレコード作成時刻から取得する明示的なイベントです。
取得
Opportunityエンティティの「createdon」タイムスタンプを使用します。
イベントタイプ
explicit
|
|||
|
営業案件の失注
|
営業案件が成立せず、販売なしで終了したことを示します。営業案件のステータスが「Lost」に変更された時点で記録します。 | ||
|
重要な理由
営業プロセスにおける主要な失敗終了アクティビティです。これらの案件を分析すると、失注理由、営業ファネルで顧客が離脱する箇所、競合の影響を特定できます。
入手先
Opportunityレコードの「statecode」が「Lost」(値2)に変更された時点のタイムスタンプから推定します。
取得
Opportunityの「statuscode」が「Lost」に設定された時点の「actualclosedate」項目または「modifiedon」タイムスタンプを使用します。
イベントタイプ
inferred
|
|||
|
営業案件の成約
|
営業案件が成約し、販売に至ったことを示します。営業案件のステータスが「Won」に変更された時点で記録します。 | ||
|
重要な理由
営業プロセスにおける主要な成功終了アクティビティです。成約率、成約案件の営業サイクル所要時間、営業パフォーマンス全体の算出に使用します。
入手先
Opportunityレコードの「statecode」が「Won」(値1)に変更された時点のタイムスタンプから推定します。関連する見積または受注の処理時に自動で実行されることもあります。
取得
Opportunityの「statuscode」が「Won」に設定された時点の「actualclosedate」項目または「modifiedon」タイムスタンプを使用します。
イベントタイプ
inferred
|
|||
|
見積の作成
|
商品またはサービスの正式な価格見積を顧客向けに作成したことを示します。Sales Opportunityに関連付けられた新しいQuoteレコードが作成された時点で記録します。 | ||
|
重要な理由
概念段階の提案から正式なオファーへ移行したことを示します。この時点から見積承諾までの期間は、見積管理の効率を測定するうえで重要です。
入手先
親Opportunityとの参照関係を持つQuoteエンティティに、新しいレコードが作成された日付として記録される明示的なイベントです。
取得
Opportunity IDに関連付けられたQuoteエンティティの「createdon」タイムスタンプを使用します。
イベントタイプ
explicit
|
|||
|
販売注文の作成
|
販売した商品やサービスの履行を管理するため、システム上で販売注文を正式に作成したことを示します。通常、「Won」のQuoteをOrderに変換した際に生成される明示的なイベントです。 | ||
|
重要な理由
営業から業務または履行担当への正式な引き継ぎを示します。受注処理の所要時間や販売後の業務効率を測定する起点です。
入手先
親Opportunityに関連付けられたSalesOrderレコードの作成時刻から取得する明示的なイベントです。
取得
SalesOrder(Order)エンティティの「createdon」タイムスタンプを使用します。
イベントタイプ
explicit
|
|||
|
顧客による見積承諾
|
顧客が見積に提示された条件と価格に正式に同意したことを示します。営業担当者がQuoteレコードのステータスを「Won」に更新した時点で記録します。 | ||
|
重要な理由
顧客が正式に契約する意思を示した重要なマイルストーンです。見積から受注への転換率や、見積承認にかかる平均時間を測定するうえで欠かせません。
入手先
Quoteレコードの「statecode」が「Won」(値2)に更新された時点のタイムスタンプから推定します。
取得
Quoteの「statecode」が「Won」に変更された時点の「modifiedon」タイムスタンプを使用します。
イベントタイプ
inferred
|
|||
|
ソリューションの提案
|
見込み顧客に正式なソリューションまたは提案を提示したことを示すアクティビティです。通常、営業案件がライフサイクル上の「Propose」ステージに移行した時点から推定します。 | ||
|
重要な理由
このアクティビティの前後にかかった時間を分析すると、ソリューション設計や提案書作成の効率を評価できます。繰り返し発生している場合は、営業サイクルに手戻りがあることを示します。
入手先
Opportunityレコードのステータス変更、または関連するBusiness Process Flowで「Propose」ステージへ進んだことから推定します。
取得
Opportunityエンティティでステータスまたはステージが変更された時点のタイムスタンプを使用します。
イベントタイプ
inferred
|
|||
|
受注処理の完了
|
販売注文に含まれるすべての商品を出荷するか、すべてのサービスを顧客に提供したことを示します。SalesOrderレコードのステータスが「Fulfilled」または同等の状態に更新された時点で記録します。 | ||
|
重要な理由
納品部分のプロセスを完了するアクティビティです。受注処理のパフォーマンスを分析する重要なマイルストーンであり、請求の起点となります。
入手先
SalesOrderレコードの「statecode」が「Fulfilled」(値3)に変更された時点のタイムスタンプから推定します。
取得
SalesOrderの「statecode」が「Fulfilled」に更新された時点の「modifiedon」タイムスタンプを使用します。
イベントタイプ
inferred
|
|||
|
契約締結
|
両当事者が法的拘束力のある契約に署名し、合意を確定したことを示します。通常はOpportunityまたは関連するContractエンティティを手動で更新した時点で記録し、電子署名連携がきっかけになる場合もあります。 | ||
|
重要な理由
契約確定までの所要時間を追跡するうえで重要なアクティビティです。この段階の遅延は、収益予測やプロジェクト開始に大きな影響を及ぼす可能性があります。
入手先
Opportunityに「Contract Signed Date」などの日付項目が入力された時点、またはステータスが変更された時点から推定します。項目の追加にはカスタマイズが必要になる場合があります。
取得
特定のステータス変更時のタイムスタンプ、または契約関連項目が入力された日付を使用します。
イベントタイプ
inferred
|
|||
|
要件の特定
|
営業チームが顧客のニーズを収集し、理解した時点を示します。通常は、営業担当者がBusiness Process Flowのステージを更新するか、営業案件のステータスを変更した時点で記録します。 | ||
|
重要な理由
このステージを追跡すると、初回接触から実現可能な提案に至るまでの期間を把握できます。ここでの遅延は、ヒアリングやリソースの確保に問題があることを示している場合があります。
入手先
OpportunityのBusiness Process Flowステージが「Develop」または「Propose」フェーズに変更された時点、あるいはカスタムステータス項目が更新された時点から推定します。ステージ変更時のタイムスタンプを使用します。
取得
Opportunityエンティティ、または関連するBusiness Process Flowエンティティの「stageid」の変更を追跡します。
イベントタイプ
inferred
|
|||
|
請求書の作成
|
履行済みの販売注文に基づいて顧客向け請求書を作成したことを示します。システム上で新しいInvoiceレコードが作成された時点に記録する明示的なイベントです。 | ||
|
重要な理由
請求と入金回収のサイクルを開始するアクティビティです。受注処理の完了から請求書作成までの期間は、請求プロセスの効率を示す重要な指標です。
入手先
SalesOrderに関連付けられたInvoiceレコードの作成時刻から取得する明示的なイベントです。
取得
Invoiceエンティティの「createdon」タイムスタンプを使用します。
イベントタイプ
explicit
|
|||
|
顧客への見積送付
|
作成した見積を顧客に正式に提出し、確認を依頼したことを示します。通常、Quoteレコードのステータスが「Active」に変更された時点から推定します。 | ||
|
重要な理由
顧客による確認と交渉の期間を測定する起点です。見積承認サイクルを分析し、顧客からの回答の遅延を特定するうえで重要なデータポイントとなります。
入手先
Quoteレコードの「statecode」が「Active」に変更された時点のタイムスタンプから推定します。
取得
監査履歴を監視するか、Quoteの「statecode」が1(Active)になった際にワークフローで更新されるタイムスタンプ項目を使用します。
イベントタイプ
inferred
|
|||
|
顧客への請求書送付
|
請求書を顧客に送付し、支払いを依頼したことを示します。通常、Invoiceレコードのステータス変更から推定します。 | ||
|
重要な理由
支払条件の起点となり、売上債権回転日数(DSO)を測定する最初のステップです。ここでの遅延はキャッシュフローに直接影響します。
入手先
Invoiceエンティティのステータス変更から推定します。標準の「Sent」ステータスはないため、この操作に合わせてワークフローでカスタム項目またはステータスを更新することが一般的です。
取得
Invoiceレコードのカスタム「Sent Date」項目、またはステータス理由の変更を追跡します。
イベントタイプ
inferred
|
|||
抽出ガイド
準備はできましたか?
このデータテンプレートを使って、今日からリードから入金までのプロセスを最適化しましょう。非効率を見つけ出し、より良い業務成果につなげます。
受注率を高める:今すぐリードから入金までを最適化
最適化された営業パイプラインを実現し、受注率を20%高めます。
14日間無料でお試しいただけます。クレジットカードは必要ありません。