リードから入金までのデータテンプレート
リードから入金までのデータテンプレート
これはリードから入金まで向けの汎用プロセスマイニング用データテンプレートです。より具体的なガイダンスについては、システム別テンプレートをご利用ください。
特定のシステムを選択- 信頼性の高いイベントログに必要なデータ項目です。
- 追跡すべき主要なプロセス手順とマイルストーンです。
- 分析しやすいデータ構成にするためのガイダンスです。
リードから入金までの属性
| 名前 | 説明 | ||
|---|---|---|---|
| アクティビティ名 ActivityName | 営業プロセスの特定の時点で発生した業務イベントまたはタスクの名称です。 | ||
| 説明 アクティビティ名は、リードから入金までのプロセスにおける具体的なステップやマイルストーンを表します。たとえば、「案件の作成」、「見積書の発行」、「支払いの受領」などです。各アクティビティは、営業案件のライフサイクルにおける個別のイベントを表します。 この属性は、実際のプロセスフローを可視化するプロセスディスカバリーに欠かせません。さまざまなアクティビティを分析すると、一般的な経路、標準プロセスからの逸脱、作業が滞留するボトルネックを特定できます。プロセスマップの基盤となり、ステップ間の遷移時間の計算にも使われます。 重要な理由 プロセスマップ上のステップを定義し、プロセスフローの可視化と分析、適合性チェック、ボトルネックの特定を可能にします。 入手先 イベントログ、ステータス変更記録、タスク完了データ、または営業案件に関連する特定のアクティビティテーブルから取得します。 例 商談の選定完了見積もり発行契約署名受注処理完了入金 | |||
| イベント時刻 EventTime | 特定のアクティビティまたはイベントが発生した時刻を示すタイムスタンプです。 | ||
| 説明 イベント時刻、つまりタイムスタンプは、アクティビティが実施された正確な日時を記録します。この時系列データは、イベントを正しい順序に並べ、各営業案件のタイムラインを再構成するために欠かせません。 プロセスマイニングでは、タイムスタンプを使ってサイクルタイム、アクティビティの所要時間、ステップ間の待ち時間などの主要なパフォーマンス指標を計算します。これらのタイムスタンプを分析すると、プロセスのパフォーマンスを把握し、遅延を特定し、プロセス改善施策の効果を測定できます。時間に基づく分析の基盤となる属性です。 重要な理由 イベントを正しい順序に並べ、サイクルタイムや所要時間など、パフォーマンス分析に欠かせない時間ベースの指標を計算するために必要な属性です。 入手先 イベントログ、取引記録、または営業案件に関連するレコードの作成日や更新日として記録されています。 例 2023-04-15T10:30:00Z2023-05-20T14:00:00Z2023-06-01T09:15:22Z | |||
| ソースシステム SourceSystem | データを抽出した記録元のシステムです。CRMやERPなどが該当します。 | ||
| 説明 ソースシステム属性は、イベントデータが生成された元のアプリケーションまたはデータベースを識別します。複雑なリードから入金までのプロセスでは、営業アクティビティを管理するCRMや、注文の履行と請求を管理するERPなど、複数のシステムからデータが集まる場合があります。 この属性は、データの検証、トラブルシューティング、データの背景理解に役立ちます。データ品質の評価に使えるほか、異なるシステムや別々のシステムインスタンスを利用する事業部門間で発生するプロセスの違いも分析できます。 重要な理由 データの背景を示し、データ検証に役立つほか、異なる元システムに起因するプロセスの違いを分析できます。 入手先 通常、データの抽出・変換(ETL)処理中に追加されるか、データウェアハウスの標準フィールドとして存在します。 例 Salesforce CRMSAP S/4HANAMicrosoft Dynamics 365Oracle CX Sales | |||
| 最終データ更新日時 LastDataUpdate | ソースシステムからデータが最後に更新された時刻を示すタイムスタンプです。 | ||
| 説明 この属性は、データセットがソースシステムから最後に更新または抽出された日時を記録します。分析対象データがどの程度新しいかを把握するための重要な情報です。 最終データ更新日時を把握することは、レポート作成や分析において重要です。プロセスに関する分析結果がどの時点の情報に基づくものかを確認できるためです。データの鮮度に関する期待値を設定し、データ更新スケジュールを管理するうえでも役立ちます。十分に新しい情報に基づいて意思決定を行うために欠かせません。 重要な理由 データの鮮度を示すため、最新の情報に基づいて分析や業務上の意思決定を行ううえで重要です。 入手先 通常、データの抽出・変換・ロード(ETL)処理中に生成され、データセットに追加されます。 例 2024-07-27T02:00:00Z2024-07-26T02:00:00Z2024-07-25T02:00:00Z | |||
| 営業案件ID SalesOpportunityId | リードから入金までのプロセスにおける、1件の営業案件を表す一意の識別子です。 | ||
| 説明 営業案件IDは主要なケース識別子として機能し、各営業プロセスを開始から終了まで一意に識別します。リードの適格性確認、見積書の作成、最終的な注文処理など、関連するすべてのアクティビティを1つの一貫した流れに結び付けます。 プロセスマイニングでは、このIDが案件ごとのエンドツーエンドのプロセスフローを再構成するために欠かせません。この識別子に基づいてプロセスを分析すると、各案件のライフサイクルを追跡し、サイクルタイムを測定し、営業パイプラインのボトルネックを特定できます。また、成功した案件と不成立に終わった案件の経路を比較できます。 重要な理由 すべてのプロセスイベントを結び付ける基本キーであり、個々の営業案件について、リードから入金までの全体の流れを再構成・分析できます。 入手先 通常、ソースシステムの営業案件、案件、または見積オブジェクトのヘッダーやメインレコードにあります。 例 OPP-0012345DEAL-98765SO-2023-54321OPTY-456-7890 | |||
| リードソース LeadSource | 営業案件のリードを獲得した元の情報源またはチャネルです。 | ||
| 説明 リードソースは、「Webサイト」、「展示会」、「パートナー紹介」、「マーケティングキャンペーン」など、営業リードの発生元を記録します。どのチャネルが価値の高い営業案件を生み出しているかを把握できます。 この属性は、マーケティングチャネルや営業チャネルの有効性を評価するうえで重要です。リードソース別に受注率、案件規模、営業サイクルタイムなどのプロセス指標を分析すると、各チャネルの投資対効果を判断できます。最も収益性が高く効率的な営業につながるチャネルにリソースを集中し、マーケティング費用を最適化する際にも役立ちます。 重要な理由 マーケティングチャネルを具体的な営業成果やプロセスパフォーマンスに結び付け、各チャネルの有効性と投資対効果を測定できます。 入手先 リードまたは営業案件レコードの標準フィールドで、通常はリードの作成時に設定されます。 例 Webサイトパートナー紹介展示会新規電話営業 | |||
| 割引率 DiscountPercentage | 営業案件に適用された割引の割合です。割引がない場合もあります。 | ||
| 説明 この属性は、見積書または最終注文に適用された割引率を記録します。案件を成立させるために、標準価格からどの程度値引きしたかを示します。 割引率の分析は、営業の収益性や価格戦略の有効性を理解するうえで重要です。プロセスマイニングでは、割引率が高い案件ほどサイクルタイムが短いか、受注率が高いかを確認できます。割引に大きく依存する営業担当者を特定し、割引ポリシーへのコンプライアンスを確認することも可能です。この分析は「割引効果」ダッシュボードを支えます。 重要な理由 価格戦略、営業の収益性、割引ポリシーへのコンプライアンスを分析するうえで重要です。割引と営業パフォーマンスの関係も確認できます。 入手先 通常、見積書、注文、または案件の商品明細レコードにあります。 例 0.050.100.150.25 | |||
| 営業ステージ SalesStage | 営業パイプラインにおける営業案件のステージです。「Qualification」や「Negotiation」などがあります。 | ||
| 説明 営業ステージは、定義された営業パイプラインにおける案件の現在または過去の位置を示します。各ステージは、案件が受注または失注に至るまでに通過する主要なマイルストーンです。 営業ステージの分析は、営業ファネルとパイプラインの健全性を理解するための基本です。リードの転換ファネルを作成して案件がどこで離脱するかを確認したり、各ステージの滞在時間を測定したり、案件が停滞しやすいボトルネックを特定したりできます。ステージの遷移を定義済みのプロセスと比較することで、コンプライアンス分析にも役立ちます。 重要な理由 営業ファネルの分析、パイプラインのボトルネックの特定、案件が営業プロセスを進む速度の測定に欠かせません。 入手先 通常、営業案件または案件オブジェクトの標準フィールドとして利用でき、あらかじめ定義された選択リストに基づいて設定されます。 例 案件評価ニーズ分析提案・見積もり交渉・レビュー | |||
| 営業地域 SalesRegion | 営業案件に関連付けられた地理的地域、担当テリトリー、または市場セグメントです。 | ||
| 説明 営業地域属性は、地理的な所在地または割り当てられた営業テリトリーに基づいて案件を分類します。国、州、市区町村、または独自に定義した営業テリトリーで設定できます。 プロセスデータを分類するための有効な切り口です。地域ごとのパフォーマンスを絞り込んだり比較したりすることで、営業サイクルタイム、受注率、プロセス適合性の地域差を特定できます。リソース配分の検討、地域ごとの市場差の把握、成果の高い地域の成功施策を他地域へ展開する際にも役立ちます。 重要な理由 異なる地理的市場間でパフォーマンスを比較でき、プロセス効率や営業成果の地域差を明らかにします。 入手先 通常、顧客アカウントまたは営業案件レコードの標準フィールドです。案件所有者に割り当てられたテリトリーから導出される場合もあります。 例 北米EMEAAPACLATAM米国西部 | |||
| 案件の結果 OpportunityOutcome | 営業案件の最終結果です。通常は「Won」または「Lost」を示します。 | ||
| 説明 案件の結果は、営業案件がアクティブなパイプラインを離れた後の最終ステータスを記録します。この二値またはカテゴリ型の属性は、営業プロセスの有効性を評価するうえで欠かせません。 この属性は、営業における重要なKPIの1つである「案件受注率」の計算基盤となります。プロセスマイニングでは、この結果を使って、受注案件と失注案件のプロセスフローや特徴を比較します。比較分析により、失注案件で発生しやすいパターン、アクティビティ、遅延を明らかにし、プロセス改善に向けた具体的な改善案につなげられます。 重要な理由 受注率の計算や、成功した案件と不成立に終わった案件のプロセス経路の比較分析に欠かせません。 入手先 通常、「Status」または「Stage」フィールドから導出され、特定の値が受注または失注に対応します。システムによっては、「IsWon」のような専用の真偽値フラグがあります。 例 受注失注クローズ:意思決定なし | |||
| 案件所有者 OpportunityOwner | 営業案件を担当し、その責任を負う営業担当者またはユーザーです。 | ||
| 説明 案件所有者は、営業案件のライフサイクル全体を管理する責任を負う個人の営業担当者またはチームを識別します。この担当者が主な窓口となり、案件を前に進めます。 この属性は、パフォーマンス分析における重要な切り口です。営業担当者やチームごとに、サイクルタイム、受注率、割引率などのプロセス指標を絞り込み、比較できます。優れた担当者のベストプラクティスを見つけたり、コーチングや追加支援が必要な領域を特定したりすることにも役立ちます。 重要な理由 営業担当者またはチーム単位でパフォーマンスを分析でき、優れた担当者、ベストプラクティス、コーチングの機会を特定できます。 入手先 営業案件または案件レコードの標準フィールドとして利用でき、通常は「Owner」、「Assigned To」、「Sales Representative」などの名称で表示されます。 例 John SmithJane Doe営業チームAPartner-XYZ | |||
| 案件金額 OpportunityAmount | 営業案件の見込み金額または実績金額です。 | ||
| 説明 この属性は、営業案件に関連する見込み収益または最終収益を表します。営業予測、案件の優先順位付け、営業プロセスの財務的な影響の測定に使う重要な財務指標です。 プロセスマイニングでは、案件金額を使って案件規模別にプロセスを分類・分析できます。たとえば、高額案件と低額案件のプロセスフローを比較し、異なる経路をたどるか、サイクルタイムに違いがあるかを確認できます。停滞案件や失注案件の金額など、プロセスの非効率がもたらす財務的な影響を計算するうえでも基本となる属性です。 重要な理由 営業パイプラインの財務分析、高額案件の優先順位付け、案件規模がパフォーマンスに与える影響を把握するためのプロセス分類に役立ちます。 入手先 営業案件または案件レコードの標準的な財務フィールドとして利用できます。 例 50000.00125000.5010000.75250000.00 | |||
| 顧客名 CustomerName | 営業案件に関連する会社または組織の名称です。 | ||
| 説明 この属性は、営業案件の対象となる顧客アカウントを識別します。顧客アカウントは会社の場合も個人の場合もあり、営業プロセスを特定の顧客に結び付けます。 顧客単位でプロセスを分析すると、営業サイクルを顧客中心の視点で把握できます。特定顧客との案件履歴、購買行動のパターン、主要顧客に対する営業プロセスのパフォーマンスを確認できます。顧客満足度に影響したり、特定顧客との案件を失注に導いたりするプロセス上の問題を特定する際にも役立ちます。 重要な理由 プロセスを顧客中心の視点で把握でき、主要顧客の営業サイクルや顧客固有のプロセス上の問題を分析できます。 入手先 ソースシステムの営業案件、または関連付けられたアカウント/連絡先レコードの標準フィールドとして記録されています。 例 Global Tech Inc.Innovate Solutions LLCPioneer CorpQuantum Industries | |||
| 営業サイクル期間 SalesCycleDuration | 営業案件が作成されてから、受注または失注として終了するまでの経過時間です。 | ||
| 説明 営業サイクル期間は、1件の営業案件における営業プロセス全体の長さを測る重要なパフォーマンス指標です。案件の作成日と終了日の差分として計算します。 通常はケース単位で計算され、営業の進行速度を直接測定できます。プロセスマイニング分析では、最適化の中心となる指標です。リードソース、案件所有者、案件規模など、サイクルタイムの長短に関係する要因を分析すると、営業プロセスを短縮し、予測精度を高める方法を特定できます。 重要な理由 営業の進行速度と効率を測定する重要なKPIです。影響要因を分析すると、営業プロセスを短縮し、予測を改善する機会を特定できます。 入手先 各SalesOpportunityIdについて、「案件の作成」のタイムスタンプを「案件の終了」のタイムスタンプから差し引いて計算します。 例 35日4時間92日11時間15日2時間 | |||
| 支払条件 PaymentTerms | 合意された支払い条件です。「Net 30」や「Net 60」などがあります。 | ||
| 説明 支払条件は、提供された商品やサービスの代金を顧客が支払う条件を定めます。一般的な例として、請求書発行日から30日以内の支払いを意味する「Net 30」や、「受領時払い」があります。 この属性は、リードから入金までの後半、特に「注文から支払いまで」のサイクルを分析するうえで重要です。合意した条件と実際の支払い日数を比較すると、支払い遅延を特定し、売上債権回転日数(DSO)を測定し、回収プロセスの有効性を評価できます。特定の支払条件が案件の早期成立と関係しているかを確認することも可能です。 重要な理由 支払いの適時性を分析し、回収の有効性を測定し、キャッシュフロープロセスの財務状態を把握するための基準となります。 入手先 販売注文、請求書、または顧客アカウントレコードの既定の条件として記録されています。 例 30日後払い60日後払い受領時払い前払い50%、納品時50% | |||
| 案件タイプ OpportunityType | 「新規顧客」や「既存顧客」など、営業案件の分類です。 | ||
| 説明 案件タイプは、案件の性質に基づいて分類します。通常は、新規顧客の獲得と既存顧客への追加販売を区別します。「更新」、「アップグレード」、「クロスセル」などのカテゴリが含まれる場合もあります。 プロセスを分類するための有効な切り口です。新規顧客向けの営業プロセスは、既存顧客向けより長く複雑になることが少なくありません。タイプごとにプロセスを分析すると、現実的なパフォーマンス基準を設定し、固有のボトルネックを特定し、営業戦略を適切に調整できます。その結果、予測の精度と営業活動の有効性を高められます。 重要な理由 営業活動の種類に基づいてプロセスを分類でき、タイプごとの営業に対するパフォーマンス比較や改善施策をより正確に行えます。 入手先 通常、営業案件オブジェクトの標準的なドロップダウンまたは選択リストフィールドです。 例 新規ビジネス既存顧客:アップセル既存顧客:更新パートナー経由 | |||
| 製品カテゴリ ProductCategory | 営業案件で販売する製品またはサービスのカテゴリです。 | ||
| 説明 製品カテゴリは、営業案件に関連する製品やサービスを、「ハードウェア」、「ソフトウェア」、「コンサルティングサービス」などの大きな分類にまとめます。販売対象を大まかに把握できます。 この属性を使うと、提供内容の種類に基づいてプロセスを分析できます。たとえば、ハードウェアの販売はソフトウェアの販売より履行サイクルが長いなど、製品カテゴリによって営業プロセスが異なるかを確認できます。受注率が最も高いカテゴリや営業サイクルが最も長いカテゴリを特定し、製品戦略や営業研修に役立つ情報を得られます。 重要な理由 販売対象に基づくプロセスの違いを分析でき、提供内容に応じた営業戦略の調整や必要なリソースの予測に役立ちます。 入手先 営業案件、見積書、または注文に関連する製品またはサービスの明細から導出されます。 例 ソフトウェアライセンスハードウェア専門サービスサブスクリプション | |||
リードから入金までのアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
| 入金 | 顧客からの入金が完了し、消込が行われた時点で、リードから入金までのサイクルの最終段階を示します。財務取引が正常に完了したことを意味します。 | ||
| 重要な理由 プロセス全体における最終的な成功イベントです。請求書発行から入金までの時間を分析することは、売上債権回転日数とキャッシュフローのパフォーマンスを測定するうえで欠かせません。 入手先 財務または会計システムに記録されます。通常は、請求書のステータスが「Paid」に更新された時点、または入金レコードが作成された時点で取得します。 取得 請求書のステータスが「Paid」として記録された時点、または入金消込日が記録された時点のタイムスタンプを取得します。 イベントタイプ explicit | |||
| 商談の選定完了 | 営業チームが、予算、決裁権、ニーズ、時期などの主要な基準に照らして商談を確認した段階を示します。商談に見込みがあり、追求する価値があることを確認します。 | ||
| 重要な理由 初期の問い合わせと真剣な見込み客を区別し、選定済みの営業パイプラインをより明確に把握できます。予測精度の向上にも役立ちます。 入手先 通常は、商談の営業ステージが「Qualified」に変更されたこと、または選定に関するタスクが完了したことから推定します。 取得 商談のステータスまたはステージが初めて「Qualified」、「Discovery」、または同様の値に変更された時点のタイムスタンプを特定します。 イベントタイプ inferred | |||
| 商談作成 | 見込み商談における営業プロセスの正式な開始点です。新しい商談レコードが、ユーザーによって手動で作成された場合、またはリードの転換によって自動的に作成された場合に、このイベントが記録されます。 | ||
| 重要な理由 営業サイクルの開始を示すため、リードから入金までの総所要時間とリード転換率を正確に測定できます。 入手先 CRMシステムにおける主要な商談または取引レコードの作成タイムスタンプから取得します。 取得 商談レコードの作成日を使用します。 イベントタイプ explicit | |||
| 商談失注 | これは、案件が正式に失注・終了したことを示す終端失敗イベントです。顧客が購入しないことを決めた場合や、競合他社を選択した場合に発生します。 | ||
| 重要な理由 失注した案件を、どの段階で失注したかも含めて分析することは、営業プロセスの弱点や競争上の圧力を理解するうえで欠かせません。 入手先 ユーザーが案件を「Closed Lost」または「Lost」ステージに移動した際に、明示的に記録されます。CRMシステムでは標準的な機能です。 取得 案件のステータスまたはステージが「Closed Lost」または「Lost」に設定された時刻を記録します。 イベントタイプ explicit | |||
| 商談成約 | 営業システム上で商談が正式に成約し、クローズされたことを示す最終的な成功イベントです。営業活動が成功という結果につながったことを確認できます。 | ||
| 重要な理由 主要な成功指標となる節目です。成約率、成約商談の営業サイクル期間、営業パフォーマンス全体を算出するうえで欠かせません。 入手先 ユーザーが商談を「Closed Won」または「Won」ステージに移動した時点で明示的に取得します。すべてのCRMシステムに標準的に備わっている機能です。 取得 商談のステータスまたはステージが「Closed Won」または「Won」に設定された時点のタイムスタンプを取得します。 イベントタイプ explicit | |||
| 営業注文作成 | 営業チームから受注処理または業務チームへの社内引き継ぎを示します。製品やサービスの提供を管理するため、システム上で営業注文が正式に作成されます。 | ||
| 重要な理由 受注から入金までのサブプロセスの開始を示します。「Opportunity Won」から「Sales Order Created」までの時間を分析すると、社内引き継ぎの効率を把握できます。 入手先 通常、成約した商談に関連付けられた営業注文レコードの作成から取得します。データはCRMまたは連携されたERPシステムから取得できます。 取得 成約した商談に関連付けられた営業注文レコードの作成日を使用します。 イベントタイプ explicit | |||
| 見積もり発行 | 顧客が確認できるよう、正式な価格見積もりを作成して送付したことを示すアクティビティです。具体的な価格を提示する重要な節目です。 | ||
| 重要な理由 重要な商取引上の手順です。見積もり提示から意思決定までの時間を分析すると、価格設定の有効性と営業交渉サイクルを把握できます。 入手先 商談に関連付けられた見積もりオブジェクトの作成またはステータス変更から取得します。見積もりのステータスが「Sent」、「Presented」、または「Active」になった時点でイベントが発生します。 取得 商談に関連付けられた見積もりが作成された時点、またはステータスが「Sent」または「Presented」に変更された時点のタイムスタンプを使用します。 イベントタイプ explicit | |||
| 請求書発行 | 請求または会計システムで顧客向け請求書が作成されたことを示します。このアクティビティによって、入金回収プロセスが正式に開始されます。 | ||
| 重要な理由 キャッシュ回収サイクルの開始点です。これを追跡すると、受注処理から請求までの時間を分析でき、キャッシュフローへの影響を把握できます。 入手先 財務またはERPシステムで請求書レコードが作成されたことから取得します。請求書は通常、営業注文または商談に関連付けられています。 取得 営業注文に関連付けられた請求書レコードの作成日を使用します。 イベントタイプ explicit | |||
| ソリューション提案 | 見込み顧客に正式なソリューション、提案、または製品デモが提示された時点を示します。ディスカバリーから積極的な営業活動へ移行する段階です。 | ||
| 重要な理由 商談が成熟した段階へ進んだことを追跡し、ディスカバリーから提案までにかかる時間の測定に役立ちます。 入手先 取引ステージが「Proposal」、「Presentation Scheduled」、「Demo Completed」などのステータスに変更されたことから推定します。 取得 商談ステージが「Proposal」、「Presentation」、または同様の値に変更された時点のタイムスタンプを使用します。 イベントタイプ inferred | |||
| 受注処理完了 | 顧客への製品納品またはサービス提供が完了したことを示します。業務上の受注処理サイクルの終了点です。 | ||
| 重要な理由 受注処理サイクルの所要時間を測定することは、業務効率と顧客満足度への影響を理解するうえで重要です。 入手先 通常はERPまたは注文管理システムから取得します。営業注文レコードのステータスが「Fulfilled」または「Shipped」などに変更されたこととして記録される場合が多いです。 取得 営業注文のステータスが「Fulfilled」、「Shipped」、または「Completed」に変更された時点のタイムスタンプを取得します。 イベントタイプ explicit | |||
| 契約署名 | 顧客が契約書に署名し、法的拘束力を持つ商業契約が確定したことを示します。営業交渉段階の集大成です。 | ||
| 重要な理由 顧客が正式にコミットしたことを示します。見積もり承諾から契約署名までの時間を分析すると、法務や承認プロセスのボトルネックを明らかにできます。 入手先 契約オブジェクトのステータスが「Activated」または「Signed」に変更されたことから取得するか、商談ステージが「Contract Signed」に移行したことから推定します。 取得 関連する契約のステータスが「Activated」または「Signed」になった時点のタイムスタンプを使用します。 イベントタイプ explicit | |||
| 案件ステージの変更 | パイプラインを進む案件の営業ステージが変更されるたびに記録します。このアクティビティは、案件の一般的な進行を表します。 | ||
| 重要な理由 案件の進行状況を詳細に把握できるため、各ステージの滞在時間、ボトルネック、ステージの後戻りなど、プロセスからの逸脱を分析できます。 入手先 案件レコードの「Stage」または「Status」フィールドの変更を追跡するフィールド履歴または監査ログから取得します。 取得 案件のステージフィールドについて、フィールド履歴テーブルからすべての変更を抽出します。 イベントタイプ explicit | |||
| 案件の再開 | 以前に失注または非アクティブとされた案件が、営業活動を再開するために再び有効になった状態を表します。営業活動が再び始まったことを示します。 | ||
| 重要な理由 再開された案件を特定すると、手戻りを分析し、案件が再び動き始めた理由を理解できます。営業戦略や予測の改善にも役立ちます。 入手先 案件のステータスが「Lost」などの終端状態から、アクティブなオープンステージに戻ったことを確認して推定します。 取得 案件のステータスが「Lost」で、その後「Open」ステータスに変更された一連の流れを検出します。 イベントタイプ inferred | |||
| 要件収集完了 | ディスカバリーコールまたは会議が実施され、顧客のニーズと要件が文書化されたことを示します。ソリューションを顧客に合わせて設計するうえで重要な手順です。 | ||
| 重要な理由 このアクティビティを把握すると、ディスカバリー段階の所要時間と、提案の精度や成約率への影響を分析できます。 入手先 通常は、商談が「Needs Analysis」、「Discovery」、「Scoping」など、特定のパイプラインステージに移行したことから推定します。 取得 商談ステージが「Needs Analysis」または同様の値に更新された時点のタイムスタンプを取得します。 イベントタイプ inferred | |||
| 見積もり承諾 | 顧客が見積もりに提示された条件と価格に、正式または非公式に同意した時点で発生します。通常、最終的な契約署名に先立つイベントです。 | ||
| 重要な理由 成約の可能性を示す強い指標として、収益予測や、価格合意から最終契約までの期間の把握に役立ちます。 入手先 通常は、見積もりレコードのステータスが「Accepted」または「Won」に更新されたことから取得します。電子署名連携によって発生する場合もあります。 取得 見積もりオブジェクトのステータスが「Accepted」または「Won」に変更された時点のタイムスタンプを特定します。 イベントタイプ explicit | |||
抽出ガイド
始める準備はできましたか。
システム別の抽出ガイドを選んで始めるか、この汎用テンプレートを使ってリードから入金までのデータ構成を整えてください。
今日からリードから入金までを最適化
既存のシステムで利用できます。数日で測定可能な改善を確認できます。
クレジットカードは不要です。5分で設定できます。