リードからキャッシュまでのデータテンプレート
リードからキャッシュまでのデータテンプレート
こちらはリード・トゥ・キャッシュ向けの汎用プロセスマイニングデータテンプレートです。より具体的なガイダンスが必要な場合は、システム固有のテンプレートをご利用ください。
特定のシステムを選択- 堅牢なイベントログに不可欠なデータフィールドです。
- 追跡すべき主要なプロセスステップとマイルストーンです。
- 分析のためのデータ構造に関するガイダンスです。
リード・トゥ・キャッシュ属性
| 名前 | 説明 | ||
|---|---|---|---|
| アクティビティ名 ActivityName | 営業プロセスのある特定の時点で発生したビジネスイベントまたはタスクの名前。 | ||
| 説明 アクティビティ名は、「商談作成」、「見積もり発行」、「支払い受領」など、リードからキャッシュまでのプロセスにおける特定のステップやマイルストーンを記述します。各アクティビティは、商談のライフサイクルにおける個別のイベントを表します。 この属性は、実際のプロセスフローを視覚化することを可能にするプロセスマイニングに不可欠です。異なるアクティビティを分析することで、一般的な経路、標準プロセスからの逸脱、作業が滞留する その重要性 プロセスマップのステップを定義し、プロセスフローの可視化と分析、適合性チェック、ボトルネックの特定を可能にします。 取得元 イベントログ、ステータス変更記録、タスク完了データ、または営業案件に関連する特定のアクティビティテーブルから派生します。 例 案件認定済み見積もり発行済み契約締結済み注文完了入金確認済み | |||
| イベント日時 EventTime | 特定のアクティビティまたはイベントが発生した時刻を示すタイムスタンプ。 | ||
| 説明 イベントタイム、またはタイムスタンプは、アクティビティが発生した正確な日時を記録します。この時系列データは、イベントを正しく順序付けし、各商談のタイムラインを再構築するために不可欠です。 プロセスマイニングは、サイクルタイム、アクティビティ期間、ステップ間の待機時間などの主要業績評価指標(KPI)を計算するためにタイムスタンプに依存しています。これらのタイムスタンプを分析することで、企業はプロセスパフォーマンスを理解し、遅延を特定し、プロセス改善イニシアチブの影響を測定できます。これは、すべての時間ベースの分析の基盤となります。 その重要性 この属性は、 取得元 イベントログ、トランザクション記録、または営業案件に関連するレコードの作成日や変更日として見つかります。 例 2023-04-15T10:30:00Z2023-05-20T14:00:00Z2023-06-01T09:15:22Z | |||
| ソースシステム SourceSystem | `データ`が抽出された記録システム。CRMやERPシステムなど。 | ||
| 説明 ソースシステム属性は、 この属性は、 その重要性 データにコンテキストを提供し、データ検証を支援し、異なる発信システムに関連する可能性のあるプロセスバリエーションの分析を可能にします。 取得元 通常、データ抽出・変換(ETL)プロセス中に追加されるか、データウェアハウス内の標準フィールドとして存在します。 例 Salesforce CRM`SAP S/4HANA`Microsoft Dynamics 365Oracle CX Sales | |||
| 最終データ更新 LastDataUpdate | ソースシステムからデータが最後に更新されたことを示すタイムスタンプです。 | ||
| 説明 この属性は、データセットが最後に更新された、またはソースシステムから抽出された日時を記録します。これは分析中の 最後の その重要性 データが最新であるかを示し、分析やビジネス上の決定が最新情報に基づいていることを保証するために不可欠です。 取得元 この 例 2024-07-27T02:00:00Z2024-07-26T02:00:00Z2024-07-25T02:00:00Z | |||
| 営業案件ID SalesOpportunityId | リードからキャッシュまでのプロセスの単一インスタンスを表す、商談の一意の識別子。 | ||
| 説明 商談IDは、各営業プロセスを最初から最後まで一意に区別する主要なケース識別子として機能します。リードの適格化、見積もりの作成、最終的な受注処理など、関連するすべてのアクティビティを単一の一貫したジャーニーに紐付けます。 プロセスマイニングにおいて、このIDは各商談のエンドツーエンドのプロセスフローを再構築するために不可欠です。この識別子に基づいてプロセスを分析することで、企業は各案件のライフサイクルを追跡し、サイクルタイムを測定し、営業パイプライン内の その重要性 全てのプロセスイベントを接続するための基本キーであり、個々の営業案件におけるリード・トゥ・キャッシュジャーニー全体を再構築し、分析することを可能にします。 取得元 通常、ソースシステム内の商談、案件、または見積もりオブジェクトのヘッダーまたはメインレコードに見られます。 例 OPP-0012345DEAL-98765SO-2023-54321OPTY-456-7890 | |||
| リードソース LeadSource | 商談のリードが獲得された元のソースまたはチャネル。 | ||
| 説明 リードソースは、「ウェブサイト」「展示会」「パートナー紹介」「マーケティングキャンペーン」など、営業リードの発生元を追跡します。これにより、どのチャネルが最も価値のあるビジネス機会を生み出しているかについての洞察が得られます。 この属性は、異なるマーケティングおよび営業チャネルの効果を評価するために不可欠です。リードソース別に勝率、取引規模、営業サイクル時間といったプロセス指標を分析することで、企業は各チャネルの投資対効果を判断できます。この分析は、最も収益性が高く効率的な営業を生み出すチャネルにリソースを集中させることで、マーケティング支出を最適化するのに役立ちます。 その重要性 様々なマーケティングチャネルの効果とROIを、具体的な販売成果やプロセスパフォーマンスと関連付けることで測定するのに役立ちます。 取得元 リードまたは案件レコードの標準フィールドで、通常リードが最初に作成されたときに自動入力されます。 例 ウェブサイトパートナー紹介展示会コールドコール | |||
| 割引率 DiscountPercentage | 商談に適用される割引率(もしあれば)です。 | ||
| 説明 この属性は、見積もりまたは最終注文に適用された割引率を記録します。これは、案件を確保するための標準定価からの乖離を反映しています。 割引レベルの分析は、販売の収益性と価格戦略の有効性を理解する上で重要です。プロセスマイニングでは、より高い割引がより速いサイクルタイムやより高い勝率と相関するかどうかを確認するために使用できます。また、割引に大きく依存している営業担当者を特定し、割引ポリシーへの その重要性 価格戦略、営業収益性、割引ポリシーの順守を分析するために不可欠であり、割引と営業パフォーマンスとの相関関係を特定するのに役立ちます。 取得元 通常、見積もり、注文、または商談の品目レコードに見られます。 例 0.050.100.150.25 | |||
| 営業ステージ SalesStage | 営業パイプラインにおける商談のステージ(「予選」や「交渉」など)。 | ||
| 説明 営業ステージは、定義された営業パイプライン内での商談の現在または過去の位置を示します。これらのステージは、案件が成約または失注に至るまでに通過しなければならない主要なマイルストーンを表します。 営業ステージの分析は、営業ファネルとパイプラインの状態を理解するための基本です。これにより、リードコンバージョンファネルを作成して案件がどこで失注しているかを確認したり、各ステージで費やされた時間を測定したり、商談が停滞しやすい その重要性 営業ファネル分析、パイプラインのボトルネック特定、および取引が営業プロセスを通過する速度を測定するために不可欠です。 取得元 通常、商談または案件オブジェクトの標準フィールドとして利用可能で、多くの場合、事前定義されたピックリストに基づいています。 例 評価ニーズ分析提案/価格見積もり交渉/レビュー | |||
| 営業地域 SalesRegion | 商談に関連付けられた地理的地域、テリトリー、または市場セグメント。 | ||
| 説明 営業地域属性は、商談を地理的位置または割り当てられた営業テリトリーに基づいて分類します。これは、国、州、都市、またはカスタム定義されたビジネス地域で定義できます。 これはプロセス その重要性 異なる地理的市場間でのパフォーマンスベンチマーキングを可能にし、プロセス効率と販売成果における地域差を明らかにします。 取得元 通常、顧客アカウントまたは商談レコードの標準フィールドです。商談担当者のテリトリー割り当てから導出される場合もあります。 例 北米EMEAAPACLATAMUS-West | |||
| 案件オーナー OpportunityOwner | 商談に割り当てられ、責任を持つ営業担当者またはユーザー。 | ||
| 説明 商談担当者は、商談のライフサイクルを通じて管理を担当する個々の営業担当者またはチームを特定します。この人物は主要な窓口であり、案件を進める責任があります。 この属性は、パフォーマンス分析の重要な側面です。これにより、異なる営業担当者やチーム間で、サイクルタイム、勝率、割引レベルなどのプロセス指標をフィルタリングおよび比較できます。この分析は、トップパフォーマーのベストプラクティスを明らかにし、コーチングや追加サポートが必要な領域を特定するのに役立ちます。 その重要性 営業担当者またはチームごとのパフォーマンス分析を可能にし、トップパフォーマー、ベストプラクティス、およびコーチングの機会を特定するのに役立ちます。 取得元 営業案件または取引レコードの標準フィールドとして利用可能で、多くの場合「オーナー」「担当者」「営業担当者」などと表示されます。 例 John Smithジェーン・ドウ営業チームAPartner-XYZ | |||
| 案件結果 OpportunityOutcome | 商談の最終結果であり、通常「成約」または「失注」のいずれかを示します。 | ||
| 説明 案件結果は、営業取引がアクティブなパイプラインを抜けた後の最終ステータスを捕捉します。この二進またはカテゴリ属性は、営業プロセスの有効性を評価するために不可欠です。 この属性は、最も重要な営業KPIの一つである「案件勝率」を計算するための基礎となります。プロセスマイニングは、この結果を使用して、受注した取引と失注した取引のプロセスフローと特性を比較します。この比較分析により、失注案件により多く見られるパターン、活動、または遅延が明らかになり、プロセス改善のための実用的な洞察を提供します。 その重要性 勝率を計算し、成功した取引と失敗した取引のプロセスパス間の比較分析を可能にするために不可欠です。 取得元 多くの場合、「ステータス」または「ステージ」フィールドから派生し、特定の値が受注または失注に対応します。一部のシステムには、「IsWon」のような専用のブール型フラグがあります。 例 成約失注クローズ - 結論なし | |||
| 案件金額 OpportunityAmount | 商談の潜在的または実際の金銭的価値。 | ||
| 説明 この属性は、商談に関連付けられた見積もりまたは最終収益を表します。これは、売上予測、案件の優先順位付け、および営業プロセスの財務的影響を測定するために使用される重要な財務指標です。 プロセスマイニングでは、商談金額は、案件規模に基づいてプロセスをセグメント化し、分析するために使用されます。たとえば、アナリストは高価値の案件と低価値の案件のプロセスフローを比較して、異なる経路をたどるか、異なるサイクルタイムを持つかを確認できます。また、停滞した商談や失注した商談の価値など、プロセスの非効率性の財務的影響を計算するための基本でもあります。 その重要性 営業パイプラインの財務分析、高価値案件の優先順位付け、および取引規模がパフォーマンスにどのように影響するかを理解するためのプロセスセグメンテーションを可能にします。 取得元 営業案件または取引レコードの標準財務フィールドとして利用可能です。 例 50000.00125000.5010000.75250000.00 | |||
| 顧客名 CustomerName | 商談に関連付けられた企業または組織の名称。 | ||
| 説明 この属性は、商談の対象となる顧客アカウント(企業または個人)を識別します。これは営業プロセスを特定のクライアントに紐付けます。 顧客別にプロセスを分析することで、セールスサイクルをクライアント中心に捉えることができます。企業は特定の顧客との案件履歴を追跡し、購買行動のパターンを特定し、主要アカウントに対する営業プロセスのパフォーマンスを測定できます。また、顧客満足度に影響を与えている可能性のあるプロセス上の問題や、特定のクライアントとの案件失注につながっている問題の特定にも役立ちます。 その重要性 プロセスに対する顧客中心の視点を提供し、主要顧客の営業サイクルを分析し、顧客固有のプロセス問題を特定することを可能にします。 取得元 ソースシステムの営業案件またはリンクされた取引先/連絡先レコードの標準フィールドとして見つかります。 例 `Global Tech Inc.`Innovate Solutions LLCPioneer Corpクアンタム・インダストリーズ | |||
| 営業サイクル期間 SalesCycleDuration | 商談が作成されてから、成約または失注としてクローズされるまでの合計経過時間。 | ||
| 説明 営業サイクル期間は、単一の案件に対する営業プロセス全体の長さを測定する主要業績評価指標です。これは、案件作成日と案件クローズ日の差として計算されます。 この属性は通常、ケースレベルで計算され、営業速度を直接測定するものです。プロセスマイニング分析において、最適化すべき主要な指標として機能します。リードソース、案件オーナー、取引規模など、サイクルタイムの短縮または長期化と相関する要因を分析することで、企業は営業プロセスを加速し、予測精度を向上させる戦略を特定できます。 その重要性 営業速度と効率を測定するための重要なKPIです。その推進要因を分析することで、営業プロセスを短縮し、予測を改善する機会を特定するのに役立ちます。 取得元 各SalesOpportunityIdについて、「案件クローズ」タイムスタンプから「案件作成」タイムスタンプを差し引いて計算されます。 例 35日4時間92日11時間15 days 2 hours | |||
| 支払条件 PaymentTerms | ネット30やネット60など、合意された支払い条件です。 | ||
| 説明 支払い条件は、顧客が提供された商品やサービスに対して支払うべき条件を定義します。一般的な例としては、請求書日から30日以内に支払期限が到来する「正味30日」や、「受領時支払い」などがあります。 この属性は、リード・トゥ・キャッシュプロセスの後期段階、特に「受注から支払いまで」のサイクルを分析するために重要です。合意された条件に対して支払い時期を分析することで、企業は支払い遅延を特定し、売掛金回収期間(DSO)を測定し、回収プロセスの有効性を評価できます。また、特定の支払い条件がより迅速な取引完了と相関しているかどうかも示すことができます。 その重要性 支払い適時性の分析、回収効果の測定、およびキャッシュフロープロセスの財務健全性を理解するためのベースラインを提供します。 取得元 販売注文、請求書、または場合によっては顧客勘定レコードのデフォルト条件として見つかります。 例 支払条件:正味30日支払条件:正味60日受領時支払い50% upfront, 50% on delivery | |||
| 案件タイプ OpportunityType | 案件の分類で、「新規ビジネス」や「既存顧客」などがあります。 | ||
| 説明 案件タイプは、その性質に基づいて取引を分類し、通常は新規顧客獲得と既存顧客への追加販売を区別します。その他のカテゴリには、「更新」、「アップグレード」、または「クロスセル」が含まれる場合があります。 これはセグメンテーションのための貴重な側面です。新規ビジネスの営業プロセスは、既存顧客向けのプロセスよりも長く、複雑になることがよくあります。各タイプごとにプロセスを個別に分析することで、企業は現実的なパフォーマンスベンチマークを設定し、独自のボトルネックを特定し、営業戦略を適切に調整できます。これにより、より正確な予測とより効果的な営業活動につながります。 その重要性 セールスモーションに基づいたプロセスセグメンテーションを可能にし、より正確なパフォーマンスベンチマーキングと、異なるタイプのセールスに対する的を絞ったプロセス改善を実現します。 取得元 通常、商談オブジェクトの標準的なドロップダウンまたはピックリストフィールドです。 例 新規ビジネス既存顧客 - アップセル既存顧客 - 更新パートナー経由 | |||
| 製品`カテゴリ` ProductCategory | 商談で販売される製品またはサービスのカテゴリです。 | ||
| 説明 製品カテゴリは、営業案件に関連する製品またはサービスを「ハードウェア」「ソフトウェア」「コンサルティングサービス」などのより広範な分類にグループ化します。これにより、販売されているものについて高レベルの視点を提供します。 この属性は、提供物の種類に基づいたプロセス分析を可能にします。企業は、異なる製品カテゴリで営業プロセスが異なるかどうか、例えばハードウェア販売がソフトウェア販売よりも長い履行サイクルを持っているかどうかを発見できます。これは、どの製品カテゴリが最高の勝率または最長の営業サイクルを持っているかを特定するのに役立ち、製品戦略と営業研修に貴重なインプットを提供します。 その重要性 販売されるものに基づいたプロセスバリエーションの分析を可能にし、販売戦略の調整や、異なる提供物に対するリソースニーズの予測を支援します。 取得元 営業案件、見積もり、または注文に関連する製品またはサービス品目から派生します。 例 ソフトウェアライセンスハードウェアプロフェッショナルサービスサブスクリプション | |||
リード・トゥ・キャッシュ活動
| アクティビティ | 説明 | ||
|---|---|---|---|
| 入金確認済み | このアクティビティは、リードからキャッシュまでのサイクルの最終ステップであり、顧客からの支払いが受領され、照合された時点を示します。これは、金融取引が正常に完了したことを意味します。 | ||
| その重要性 プロセス全体の最終的な成功イベントです。請求書から支払いまでの時間を分析することは、売上債権回収期間とキャッシュフローパフォーマンスを測定するために極めて重要です。 取得元 財務または会計システムに記録されます。通常、請求書のステータスが「支払い済み」に更新されたとき、または支払記録が作成されたときに捕捉されます。 取得 請求書ステータスが「支払い済み」とマークされたか、支払決済日が記録された際のタイムスタンプをキャプチャします。 イベントタイプ explicit | |||
| 案件作成済み | 潜在的な案件に対する営業プロセスの公式な開始。このイベントは、ユーザーによる手動、または変換されたリードから自動的に新しい商談レコードが作成されたときに記録されます。 | ||
| その重要性 営業サイクルの始まりを示し、リード・トゥ・キャッシュの総期間とリード転換率を正確に測定することを可能にします。 取得元 CRMシステムにおける主要な商談(または案件)レコードの作成タイムスタンプから取得されます。 取得 商談レコードの作成日を使用します。 イベントタイプ explicit | |||
| 案件受注 | これは、案件が営業システムで正式に成約としてクローズされる、最終的な成功`イベント`です。これは、営業努力が成功した結果につながったことを確認します。 | ||
| その重要性 これは主要な成功マイルストーンです。勝率、成約案件の営業サイクル期間、および全体の営業パフォーマンスを計算するために不可欠です。 取得元 ユーザーが案件を「クローズ受注」または「受注」ステージに移動させたときに明示的にキャプチャされます。これは全てのCRMシステムの標準機能です。 取得 案件のステータスまたはステージが「クローズ受注」または「受注」に設定された際のタイムスタンプをキャプチャします。 イベントタイプ explicit | |||
| 案件失注 | これは、案件が正式に失注としてクローズされる、最終的な失敗`イベント`です。これは、顧客が購入しないことを決定したり、競合他社を選択したりした場合に発生します。 | ||
| その重要性 失注した案件を、どの段階で失注したかを含めて分析することは、営業プロセスの弱点や競合圧力を理解するために不可欠です。 取得元 ユーザーが案件を「クローズ失注」または「失注」ステージに移動させたときに明示的にキャプチャされます。これはCRMシステムの標準機能です。 取得 案件のステータスまたはステージが「クローズ失注」または「失注」に設定された際のタイムスタンプをキャプチャします。 イベントタイプ explicit | |||
| 案件認定済み | 営業チームが予算、権限、必要性、タイミングなどの主要な基準に対して案件を精査したマイルストーンを表します。これにより、案件が実現可能であり、追求する価値があることが確認されます。 | ||
| その重要性 初期の問い合わせから真剣な見込み客を区別するのに役立ち、資格のある営業パイプラインのより明確な視点を提供し、予測精度を向上させます。 取得元 通常、商談の営業ステージが「適格」ステータスに変更された場合、または適格化関連タスクの完了から推測されます。 取得 案件ステータスまたはステージが最初に「資格認定済み」、「ディスカバリー」、または類似の値に変更された際のタイムスタンプを特定します。 イベントタイプ inferred | |||
| 見積もり発行済み | このアクティビティは、顧客の確認のために正式な見積書を作成し、送信することを示します。これは、特定の価格が提示される重要なマイルストーンです。 | ||
| その重要性 これは重要な商業ステップです。見積もりから決定までの時間を分析することで、価格設定の有効性と営業交渉サイクルに関する洞察が得られます。 取得元 案件にリンクされた見積もりオブジェクトの作成またはステータス変更からキャプチャされます。イベントは、見積もりステータスが「送付済み」「提示済み」「有効」になったときに発生します。 取得 商談にリンクされた見積もりが作成されたとき、またはそのステータスが「送信済み」または「提示済み」に変更されたときの イベントタイプ explicit | |||
| 請求書生成済み | 顧客請求書が請求システムまたは会計システムで作成されたことを示します。このアクティビティは、正式に支払い回収プロセスを開始します。 | ||
| その重要性 これは現金回収サイクルの開始点です。これを追跡することで、履行と請求の間にかかる時間を分析し、キャッシュフローへの影響を把握するのに役立ちます。 取得元 財務システムやERPシステムで請求書レコードが作成された際に取得されます。請求書は通常、販売注文または商談に紐付けられます。 取得 販売注文に関連付けられた請求書レコードの作成日を使用します。 イベントタイプ explicit | |||
| 販売注文作成済み | 営業チームから履行チームまたは運用チームへの内部引き継ぎを示します。製品またはサービスの配送を管理するために、システムで正式に販売注文が作成されます。 | ||
| その重要性 受注から入金までのサブプロセスの開始を示します。「案件受注」から「販売注文作成」までの時間を分析することで、内部の引き継ぎ効率が明らかになります。 取得元 販売注文レコードの作成から取得されます。これは多くの場合、受注した案件にリンクされています。このデータはCRMまたは統合されたERPシステムから供給される可能性があります。 取得 成約した商談に関連付けられた販売注文レコードの作成日を使用します。 イベントタイプ explicit | |||
| 契約締結済み | 顧客が契約に署名し、法的拘束力を持たせることで、商業合意が最終決定されたことを表します。これは営業交渉段階の集大成です。 | ||
| その重要性 顧客からの正式なコミットメントを示します。見積もり承認から契約締結までの時間を分析することで、法務または承認プロセスにおけるボトルネックが明らかになる可能性があります。 取得元 契約オブジェクトのステータスが「有効化」または「署名済み」に変更された時点、または案件ステージが「契約締結済み」に移行した時点から取得されます。 取得 リンクされた契約のステータスが「有効」または「署名済み」になったときの イベントタイプ explicit | |||
| 案件ステージ変更 | 案件がパイプラインを進む際の営業ステージのあらゆる変更を捕捉します。このアクティビティは、案件の一般的な動きを表します。 | ||
| その重要性 案件のジャーニーを詳細に把握し、ステージ期間、ボトルネック、ステージの後退などのプロセス逸脱の分析を可能にします。 取得元 案件レコードの「ステージ」または「ステータス」フィールドへの変更を追跡するフィールド履歴または監査ログから取得されます。 取得 案件のステージフィールドに関するフィールド履歴テーブルから全ての変更を抽出します。 イベントタイプ explicit | |||
| 案件再開 | 以前に失注または非アクティブとマークされたものの、その後の営業活動のために再活性化された案件を表します。これは、新たな営業努力を示します。 | ||
| その重要性 再開された案件を特定することは、手戻りを分析し、なぜ取引が再浮上したのかを理解するのに役立ち、営業戦略や予測に情報を提供できます。 取得元 案件のステータスが「失注」のような最終状態から活動中のオープンなステージに戻ることを観察することで推測されます。 取得 案件ステータスが「失注」から「オープン」ステータスにその後変更されるシーケンスを検出します。 イベントタイプ inferred | |||
| 注文完了 | 製品の配送またはサービス提供の顧客への完了を表します。このイベントは、運用上の履行サイクルの終了を示します。 | ||
| その重要性 注文履行サイクル時間を測定することは、運用効率と顧客満足度への影響を理解するための鍵です。 取得元 通常、ERPまたは注文管理システムから取得されます。多くの場合、「履行済み」または「出荷済み」などの販売注文レコードのステータス変更として記録されます。 取得 販売注文ステータスが「履行済み」、「出荷済み」、または「完了」に変更された際のタイムスタンプをキャプチャします。 イベントタイプ explicit | |||
| 要件収集済み | ディスカバリーコールまたは会議が行われ、顧客のニーズと要件が文書化されたことを示します。これはソリューションをカスタマイズする上で重要なステップです。 | ||
| その重要性 このアクティビティを理解することは、発見フェーズの期間と、それが提案の正確性および勝率に与える影響を分析するのに役立ちます。 取得元 多くの場合、案件が「ニーズ分析」「ディスカバリー」「スコープ定義」などの特定のパイプラインステージに移行したときに推測されます。 取得 案件ステージが「ニーズ分析」または類似のステータスに更新された際のタイムスタンプをキャプチャします。 イベントタイプ inferred | |||
| 見積もり承認済み | この`イベント`は、顧客が見積もりに提示された条件と価格に正式または非公式に合意したときに発生します。これはしばしば最終的な契約締結に先行します。 | ||
| その重要性 受注の確度が高いことを示す強力な指標として、収益予測や価格合意から最終契約までの時間差を理解するのに役立ちます。 取得元 通常、見積もりレコードのステータスが「承認済み」または「成約」に更新されたときに取得され、e-signature統合を介してトリガーされることもあります。 取得 見積もりオブジェクトのステータスが「承認済み」または「受注」に変更された際のタイムスタンプを特定します。 イベントタイプ explicit | |||
| 解決策提示済み | 潜在顧客に正式なソリューション、提案、または製品デモンストレーションが提示された時点を表します。これは、ディスカバリーからアクティブな販売への移行を示します。 | ||
| その重要性 商談が成熟段階に進む過程を追跡し、発見から提案までの移行にかかる時間を測定するのに役立ちます。 取得元 取引ステージが「提案」、「プレゼンテーション予定」、「デモ完了」などのステータスに変更されたことから推測されます。 取得 商談ステージが「提案」、「プレゼンテーション」などに変更されたときの イベントタイプ inferred | |||