リード・ツー・キャッシュ データテンプレート
リード・ツー・キャッシュ データテンプレート
- 収集を推奨する項目
- 追跡すべき主要アクティビティ
- Pipedriveデータ抽出ガイド
リード・トゥ・キャッシュ属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ名
ActivityName
|
セールスプロセス内で発生した特定のビジネスイベントまたはタスクの名前。 | ||
|
説明
この属性は、「商談作成」、「提案書送付」、「支払い受領」など、リード・トゥ・キャッシュプロセスにおける単一のステップを記述します。活動は、プロセスフローを視覚化するために使用される基本的な構成要素です。 活動の順序と頻度を分析することで、最も一般的なプロセスパス、作業が滞留するボトルネック、および標準的な営業手順からの逸脱を特定するのに役立ちます。これは、プロセスが実際にどのように実行されているかを理解するために不可欠です。
その重要性
プロセスのステップを定義し、プロセスフローの可視化と分析、ボトルネックの特定、適合性チェックを可能にします。
取得元
これは通常、商談ステージの変更や請求書などの関連オブジェクトの作成といったPipedriveイベントを、定義された活動リストにマッピングすることで導き出されます。
例
案件作成提案書送付済み案件獲得請求書送付済み入金確認済み
|
|||
|
イベント日時
EventTime
|
アクティビティの発生時刻を示すタイムスタンプです。 | ||
|
説明
イベント時刻(または開始時刻)は、特定の活動が記録された正確な日付と時刻を捕捉します。この時系列データは、イベントを時系列で並べ、異なるプロセスステップ間の期間を計算するために不可欠です。 分析では、このタイムスタンプはサイクルタイム、処理時間、待機時間などの主要なパフォーマンス指標を計算するために使用されます。これにより、パフォーマンスを監視し、セールスプロセス内の遅延を特定する時間ベースのダッシュボードの作成が可能になります。
その重要性
このタイムスタンプは、イベントの順序付け、プロセス期間の計算、および時間ベースの目標に対するパフォーマンス分析のために不可欠です。
取得元
Pipedrive APIの商談、活動、または関連オブジェクトの「add_time」や「update_time」などのフィールドから取得されます。
例
2023-04-15T10:00:00Z2023-04-16T14:30:00Z2023-05-01T09:05:00Z
|
|||
|
商談
SalesOpportunityId
|
商談の一意の識別子であり、リード・トゥ・キャッシュプロセス全体を追跡するためのケースIDとして機能します。 | ||
|
説明
商談IDは、最初のリード作成から最終支払いまでのすべての関連活動を結びつける主キーです。Pipedriveで追跡される単一の潜在的な売上を表します。 プロセス分析において、この識別子は各商談のエンドツーエンドのジャーニーを再構築するために不可欠です。これにより、「商談作成」、「提案書送付」、「支払い受領」などのすべてのイベントを一貫したケースにグループ化でき、プロセスバリアント、サイクルタイム、コンバージョン率の分析を可能にします。
その重要性
この識別子はプロセスビューの基盤であり、すべての関連イベントをリンクして各商談の完全なケース履歴を形成します。
取得元
Pipedrive APIを介してDealオブジェクトの「id」フィールドから取得されます。
例
12543125441254512546
|
|||
|
割引率
DiscountPercentage
|
商談に適用された割引率。 | ||
|
説明
この属性は、商談に適用された割引率(もしあれば)を表します。これは、価格戦略とその収益性への影響を理解する上で重要な要素です。 割引率を分析することは、割引戦略の有効性を評価するのに役立ちます。商談金額、営業担当者、製品などの他の属性と相関させることで、割引が最も一般的に行われる場所や、それが勝率の向上につながるのか、単に利益率を低下させるだけなのかを確認できます。
その重要性
これは、価格戦略、販売マージン、および商談全体の収益性を分析するために不可欠です。
取得元
これはPipedriveの商談オブジェクト上のカスタムフィールドであることがよくあります。カスタムフィールドの設定についてはPipedriveのドキュメントを参照してください。
例
0.050.100.150.0
|
|||
|
案件ステータス
DealStatus
|
商談の現在の結果または状態。受注、失注、進行中など。 | ||
|
説明
案件ステータスは、営業機会の最終的な結果または現在の高レベルの状態を示します。これは、販売成功率とプロセス効率を分析するための主要な次元です。 この属性は、勝率/敗率を計算し、プロセスマップをフィルタリングして、受注した案件と失注した案件の道のりを比較するために不可欠です。この比較は、成功または失敗に寄与するプロセス実行の主要な違いを明らかにすることが多く、プロセス改善のための貴重な洞察を提供します。
その重要性
勝率/敗率を計算し、成功した取引と失敗した取引のプロセスフローを比較するために不可欠です。
取得元
Pipedrive APIのDealオブジェクトの「status」フィールドから取得されます。
例
受注lostオープン
|
|||
|
案件担当者
DealOwner
|
商談の管理を担当する営業担当者。 | ||
|
説明
商談担当者は、特定の商談に割り当てられたユーザーです。この属性は、営業チーム内のリソース配分とパフォーマンスを理解する上で重要です。 この属性により、個人またはチームレベルでのパフォーマンス分析が可能になります。ダッシュボードを商談担当者でフィルタリングすることで、セールスサイクルタイム、コンバージョン率、平均商談金額などの指標を比較でき、トップパフォーマーやコーチングが必要な領域を特定するのに役立ちます。
その重要性
営業担当者別のパフォーマンス分析を可能にし、トップパフォーマーや改善が必要な領域を特定するのに役立ちます。
取得元
Dealオブジェクト上の「user_id」フィールドから取得され、Pipedrive APIのUserオブジェクトにリンクします。
例
John Smithジェーン・ドウPeter Jones
|
|||
|
案件金額
DealValue
|
商談の総金額。 | ||
|
説明
案件金額は、営業機会に関連する潜在的または実際の収益を表します。これは、案件を優先順位付けし、営業パイプラインの財務的影響を評価するための基本的な指標です。 プロセス分析では、この属性は財務規模によってケースをセグメント化するために使用され、高価値案件と低価値案件のプロセス実行を比較することを可能にします。また、販売パフォーマンス、割引効果、および全体的な収益生成を分析するダッシュボードの主要なコンポーネントでもあります。
その重要性
営業プロセスの財務分析を可能にし、高価値の案件を優先順位付けし、収益への影響を理解するのに役立ちます。
取得元
Pipedrive APIのDealオブジェクトの「value」フィールドから取得されます。
例
5000.0025000.501500.75
|
|||
|
イベントの終了時刻
EventEndTime
|
期間を伴う活動が完了した時期を示すタイムスタンプ。 | ||
|
説明
イベント終了時刻は、会議やタスクなど、測定可能な期間を持つ活動の完了を示します。開始時刻を補完し、特定の活動にどれくらいの時間がかかったかを正確に計算できるようにします。 この属性は、個々の活動の処理時間を計算するために不可欠です。この期間を分析することで、どの特定のタスクが最も時間消費的であるかを特定し、最適化、自動化、またはリソース再配分の機会を提供します。
その重要性
個々のアクティビティ期間を正確に計算することを可能にし、時間のかかるタスクやボトルネックを特定する鍵となります。
取得元
Pipedrive APIの活動オブジェクトにおける「due_date」や完了タイムスタンプなどのフィールドから取得されます。
例
2023-04-15T11:00:00Z2023-04-16T15:00:00Z2023-05-01T09:35:00Z
|
|||
|
セールスサイクルタイム
SalesCycleTime
|
商談が作成されてから、それがクローズ(受注または失注)されるまでの合計期間。 | ||
|
説明
セールスサイクルタイムは、最初のイベント「商談作成」から、「商談受注」または「商談失注」といった最終結果イベントまでの経過時間を測定する主要なパフォーマンス指標です。 この算出された指標は、営業の速度に関する大局的な概要を提供します。その平均と分布を分析することで、全体的なプロセスにおける傾向や体系的な遅延を特定するのに役立ちます。これは、営業効率とパフォーマンスに焦点を当てたダッシュボードの主要なKPIです。
その重要性
これは、セールスプロセス全体の効率と速度を最初から最後まで測定するための重要なKPIです。
取得元
各
例
30日と4時間92日と8時間15 days 2 hours
|
|||
|
ソースシステム
SourceSystem
|
`データ`が`抽出`された`システム`を`特定`します。 | ||
|
説明
この属性はデータの出所を指定します。この場合はPipedriveです。複数のシステムからのデータが統合され、全体的なプロセスビューが構築される環境で特に役立ちます。 単一システム分析では静的な値となることが多いですが、不可欠なコンテキストを提供し、データガバナンスとトレーサビリティを支援します。イベントと属性がPipedriveインスタンスに関連していることを確認します。
その重要性
データの出所に関する重要なコンテキストを提供し、特に複数のシステムからのデータを組み合わせる際に、追跡可能性と明確性を確保します。
取得元
これは通常、データ変換プロセス中に付加される静的な値です。
例
Pipedrive
|
|||
|
プロダクト
ProductAttached
|
商談に関連付けられた製品またはサービス。 | ||
|
説明
この属性は、商談で販売されている製品またはサービスを指定します。これにより、特定の提供物に関連する販売活動をより詳細に分析できます。 製品を含めることで、異なる製品ライン間の販売プロセスを比較するために分析をセグメント化できます。これにより、特定の製品がより長いセールスサイクル、異なるコンバージョン率を持つか、または異なるプロセスステップを必要とするかを明らかにすることができ、よりオーダーメイドの販売戦略につながります。
その重要性
製品ラインごとの販売プロセス分析を可能にし、異なる提供物における販売サイクルや成功率のばらつきを特定するのに役立ちます。
取得元
Pipedrive APIでDealにリンクされているProductオブジェクトから取得されます。
例
標準SaaSサブスクリプションエンタープライズプラットフォームライセンスプロフェッショナルサービスパッケージ
|
|||
|
リードソース
LeadSource
|
リードを獲得したソースまたはチャネル。 | ||
|
説明
リードソースは、潜在顧客が最初にどのように特定されたかを示します。例えば、「ウェビナー」、「コールドコール」、「パートナー紹介」などです。この情報は、マーケティングおよび営業戦略にとって不可欠です。 リードソースを分析することで、異なるマーケティングチャネルの効果を判断するのに役立ちます。さまざまなソースからのリードのコンバージョン率と販売サイクル時間を比較するために使用でき、ビジネスがマーケティング費用と営業努力を最適化することを可能にします。
その重要性
各ソースからのリードのコンバージョン率とプロセスパフォーマンスを分析することで、さまざまなマーケティングチャネルの効果を測定するのに役立ちます。
取得元
Leadオブジェクト上の「source_name」フィールドから取得され、その後Dealに関連付けられます。
例
オーガニック検索有料ソーシャル紹介展示会
|
|||
|
最終データ更新
LastDataUpdate
|
ソースシステムからの最新データ更新時刻を示すタイムスタンプ。 | ||
|
説明
この属性は、プロセスマイニングデータセットでデータが最後に抽出および更新された時刻を示します。分析されているデータの鮮度について明確な参照点を提供します。 あらゆる分析において、データの適時性を知ることは重要です。この属性は、ユーザーが表示しているインサイトがプロセスの最新の状態を反映しているかどうかを理解するのに役立ち、これは運用監視と意思決定に不可欠です。
その重要性
データの鮮度を示し、ユーザーがプロセス分析の最新性を認識していることを保証します。
取得元
この値は、データインジェストまたはETLプロセス中に生成および記録されます。
例
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
|
|||
|
地域
Region
|
顧客または商談に関連付けられた地理的地域。 | ||
|
説明
この属性は、商談を北米、EMEA、APACなどの地理的地域に分類します。これにより、販売パフォーマンスとプロセスを地域に基づいて分析できます。 プロセスを地域別にセグメント化することで、企業はセールスサイクルタイム、勝率、プロセスバリアントにおける地域差を発見できます。これらの洞察は、地域の営業戦略、リソース配分、プロセス標準化の取り組みに役立ちます。
その重要性
販売プロセスの地理的分析を可能にし、パフォーマンスと顧客行動における地域差を浮き彫りにします。
取得元
これは通常、商談オブジェクトまたは組織オブジェクトのカスタムフィールドです。組織のアドレスフィールドを使用してこれを導き出すこともできます。
例
北米EMEAAPACLATAM
|
|||
|
手戻り
IsRework
|
リワークループの一部であるアクティビティを識別するフラグです。 | ||
|
説明
リワークとは、プロセスが直線的な流れから逸脱し、以前のステップを繰り返すインスタンスを強調するためにプロセスマイニングツールによって通常計算されるブール値フラグです。例えば、案件が「交渉」から「提案書送付」に戻った場合、リワークと見なされます。 リワークの特定は、非効率性、無駄な労力、および顧客への潜在的な混乱を表すため、プロセス最適化にとって極めて重要です。リワークとしてフラグ付けされたアクティビティを分析することで、プロセスがどこで破綻しているかを正確に特定し、ターゲットを絞った改善を可能にします。
その重要性
反復的または循環的なプロセスパスの一部であるアクティビティを特定し、フラグを立てることで、プロセスの非効率性を定量化するのに役立ちます。
取得元
これは、各ケース内の活動の順序を分析することにより、プロセスマイニングソフトウェアによって計算されます。
例
truefalse
|
|||
|
支払条件
PaymentTerms
|
「正味30日」や「正味60日」などの合意された支払い条件。 | ||
|
説明
支払い条件は、請求書発行後、顧客が支払うべき期間を定めます。この属性は、売掛金管理およびキャッシュフローにとって極めて重要です。 プロセスマイニングでは、この属性は支払いパフォーマンスを評価するための基準となります。請求書発行日とこれらの条件から導き出される支払期日に対して実際の支払い日を比較することで、期日内支払い率などのKPIを計算するために使用されます。
その重要性
期日内支払いパフォーマンスを測定し、現金回収プロセスにおける遅延を分析するための基準を提供します。
取得元
これは通常、Pipedriveの商談オブジェクトまたは組織オブジェクトのカスタムフィールド、または統合会計システムからのものである可能性があります。
例
支払条件:正味30日支払条件:正味60日受領時支払い
|
|||
|
期日通りに支払い済み
IsOnTimePayment
|
合意された支払い条件内で支払いがあったかどうかを示すブール値フラグです。 | ||
|
説明
この属性は、支払いが期日内に行われたかどうかを示すバイナリフラグ(真/偽)です。実際の請求書支払い時刻と指定された支払い条件を比較することによって導き出されます。 このフラグは、支払い行動の分析を簡素化します。期日内支払い率KPIを迅速に計算したり、遅延支払いをフィルタリングしたりするために使用でき、特定の顧客や商談タイプが支払い遅延につながる理由に焦点を当てた根本原因分析を可能にします。
その重要性
支払い順守の分析を簡素化し、期日内支払い率KPIの計算に使用されます。
取得元
「InvoicePaymentTime」を「PaymentTerms」属性と比較して計算されます。例えば、PaymentTermsが「Net 30」でInvoicePaymentTimeが30日以内であれば、値はTrueとなります。
例
truefalse
|
|||
|
案件ステージ
DealStage
|
商談が現在置かれているセールスパイプラインの特定のステージ。 | ||
|
説明
商談ステージは、「適格」、「提案済み」、「交渉中」など、企業が定義した営業パイプラインにおける特定のステップを表します。これは、全体的な商談ステータスよりも商談の進捗をより詳細に把握するための視点を提供します。 商談ステージを分析することは、セールスファネルを理解し、商談が停滞しやすい場所を特定する上で重要です。各ステージに費やされた時間を追跡することで、チームはボトルネックを正確に特定し、セールスサイクルの中で最も問題のある部分に改善努力を集中させることができます。
その重要性
セールスファネルにおける商談の進捗を詳細に可視化し、ボトルネックや各ステージ間のコンバージョン率の特定に役立ちます。
取得元
Dealオブジェクト上の「stage_id」フィールドから取得され、Pipedrive APIのStageオブジェクトにリンクします。
例
リードインコンタクト完了デモ予約済み提案書作成済み交渉開始
|
|||
|
案件通貨
DealCurrency
|
商談金額に関連付けられた通貨。 | ||
|
説明
この属性は、商談金額が表現されている通貨(例:USD、EUR、GBP)を指定します。すべての財務指標に必要なコンテキストを提供します。 複数の地域や国からの商談を分析する場合、この属性は正確な財務報告と集計のために不可欠です。財務データを要約する前に通貨換算が正しく適用されることを保証し、不正確な結論を防ぎます。
その重要性
商談金額に関する不可欠なコンテキストを提供し、異なる地域間で正確な財務分析とレポート作成を保証します。
取得元
Pipedrive APIのDealオブジェクトの「currency」フィールドから取得されます。
例
USDEURGBP
|
|||
|
組織名
OrganizationName
|
商談に関連付けられた顧客の企業名または組織名。 | ||
|
説明
この属性は、商談にリンクされている法人顧客を識別します。これにより、どの企業がセールスパイプラインにあるかというコンテキストを提供します。 組織名でデータを分析することは、顧客行動を理解し、主要なアカウントを特定するのに役立ちます。プロセス分析をセグメント化して、戦略的顧客と小規模顧客でプロセスが異なるかどうかを確認したり、特定の企業との全販売履歴を追跡したりするために使用できます。
その重要性
顧客を特定し、顧客中心の分析と営業プロセスのセグメンテーションを可能にします。
取得元
Dealオブジェクト上の「org_id」フィールドから取得され、Pipedrive APIのOrganizationオブジェクトにリンクします。
例
ABC Corporation`Global Tech Inc.`革新的な解決策
|
|||
|
請求書支払い時間
InvoicePaymentTime
|
請求書送付から支払い受領までの期間。 | ||
|
説明
請求書支払い時間は、売掛金プロセスの効率を測定します。具体的には、「請求書送付」アクティビティから「支払い受領」アクティビティまでの経過時間を追跡します。 この指標は、キャッシュフローの監視と支払い回収の遅延特定に不可欠です。この期間を分析することで、企業は顧客の支払い行動と、督促および回収戦略の効果を理解するのに役立ち、見積もりから支払いまでのサイクルに直接影響を与えます。
その重要性
現金回収プロセスの効率を直接測定し、キャッシュフロー管理に不可欠です。
取得元
特定のケースについて、「支払い受領」と「請求書送付」のアクティビティのタイムスタンプの差として計算されます。
例
28 days45日間10日
|
|||
リード・トゥ・キャッシュアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
入金確認済み
|
顧客からの支払いの成功的な受領を示し、機会のキャッシュサイクルを完了させます。これはリード・トゥ・キャッシュプロセスの最終イベントであり、財務システムから発生します。 | ||
|
その重要性
これは最終的な価値実現ステップです。リード・トゥ・キャッシュプロセスの真の終点であり、エンドツーエンドのサイクルタイムを測定し、支払い遅延を分析するために不可欠です。
取得元
会計または支払い処理システムから取得されます。支払いの確認はPipedriveの取引にリンクされている必要があります。
取得
外部の財務システムからのイベントデータで、一意の識別子を介して取引にリンクされています。
イベントタイプ
explicit
|
|||
|
取引不成立
|
案件の不成功なクローズを示します。これは、顧客が競合他社を選択した場合、もはや関心がない場合、またはその他の理由で営業プロセスが終了した場合に発生します。 | ||
|
その重要性
これは主要な失敗終点です。商談がいつ、なぜ失注したかを分析することは、営業戦略、トレーニング、および適格化プロセスを改善するための重要な洞察を提供します。
取得元
これは商談のステータスが「失注」に変更されたときに捕捉される明示的なイベントです。商談エンティティの「lost_time」フィールドがタイムスタンプを記録します。
取得
Dealsエンティティの「lost_time」タイムスタンプを使用します。
イベントタイプ
explicit
|
|||
|
提案書送付済み
|
正式な見積もりまたは提案が顧客に提出された時点を示します。これは多くの場合、商談が「提案済み」や「見積もり送付済み」といった特定のパイプラインステージに移行したことで推測されます。 | ||
|
その重要性
これはセールスプロセスにおける重要なマイルストーンです。このイベントから「商談受注」までの時間を分析することで、意思決定および交渉フェーズの長さを理解するのに役立ちます。
取得元
「stage_id」が提案用に指定されたステージに変更されたときに、取引の変更ログから推測されます。ステージ変更のタイムスタンプが使用されます。
取得
取引の
イベントタイプ
inferred
|
|||
|
案件作成
|
営業機会の正式な開始を示します。このイベントは、新しい取引が手動で作成された場合、または変換されたリードから自動的に生成された場合にトリガーされます。 | ||
|
その重要性
これはセールスサイクルの主要な開始活動です。このイベントから「商談受注」または「商談失注」までの時間を分析することで、セールスサイクル全体の期間が提供されます。
取得元
これはPipedriveの商談エンティティで捕捉される明示的なイベントです。商談レコードの作成タイムスタンプ(「add_time」)がイベント時刻として機能します。
取得
Dealsエンティティの「add_time」フィールドを使用します。
イベントタイプ
explicit
|
|||
|
案件獲得
|
顧客からの口頭または書面による合意を意味する、取引の成功的なクローズを示します。これはPipedrive内の標準的で明示的なステータス変更です。 | ||
|
その重要性
これは最も重要な成功マイルストーンです。勝率、成功した商談のセールスサイクル期間、および全体的な営業パフォーマンスを計算するために不可欠です。
取得元
これは商談のステータスが「受注」に変更されたときに捕捉される明示的なイベントです。商談エンティティの「won_time」フィールドが正確なタイムスタンプを提供します。
取得
Dealsエンティティの「won_time」タイムスタンプを使用します。
イベントタイプ
explicit
|
|||
|
交渉開始
|
価格、条件、または範囲に関する活発な交渉の開始を示します。これは通常、提案書送付後に商談が「交渉中」のパイプラインステージに移行したときに推測されます。 | ||
|
その重要性
交渉フェーズを分離することで、この特定のサイクル部分がどれくらいの時間がかかるか、またどの案件が長期の交渉を伴うかを特定するのに役立ちます。
取得元
「stage_id」が明示的に交渉と名付けられたステージに更新されたときに、取引の変更ログから推測されます。
取得
取引履歴から事前定義された「交渉」ステージへのステージ変更を特定します。
イベントタイプ
inferred
|
|||
|
初回接触完了
|
商談に関連する潜在顧客との最初の有意義なインタラクションを示します。これは通常、商談にリンクされた通話、メール、会議などの完了した活動として記録されます。 | ||
|
その重要性
これを追跡することで、初回接触までの時間を測定し、リードが迅速にエンゲージされていることを確認できます。これにより、営業チームの応答性に関する洞察が得られます。
取得元
Pipedriveのアクティビティエンティティから取得されます。取引IDにリンクされた最も早い完了済みアクティビティを見つけることで識別されます。
取得
「done_time」フィールドに基づいて、取引に関連付けられた最初のアクティビティを見つけます。
イベントタイプ
explicit
|
|||
|
提案書フォローアップ
|
顧客に提案書が送付された後に発生する、通話やメールなどの営業活動を捕捉します。このイベントは、検討段階での積極的なエンゲージメントを示します。 | ||
|
その重要性
フォローアップアクションの適時性と頻度を測定します。これは勢いを維持し、案件をクローズするために不可欠です。「提案書フォローアップの適時性」ダッシュボードをサポートします。
取得元
Pipedriveのアクティビティエンティティから取得されます。同じ取引の「提案書送付」イベント後に発生する完了済みアクティビティとして識別されます。
取得
「提案書送付」アクティビティのタイムスタンプよりも後の
イベントタイプ
explicit
|
|||
|
案件再オープン
|
以前は失注とマークされていた商談が、その後の営業活動のために再活性化されたことを示します。このイベントは、商談のステータスが「lost」から「open」に戻ったときに推測されます。 | ||
|
その重要性
この活動は、手戻りループと再エンゲージメントの取り組みを浮き彫りにします。これらの事例を分析することで、顧客行動のパターンや営業フォローアップの効果を明らかにすることができます。
取得元
取引の変更ログから推測されます。「status」フィールドが「失注」から「オープン」に変更されたときに検出されます。
取得
案件の履歴で「失注」から「オープン」へのステータス変更を特定します。
イベントタイプ
inferred
|
|||
|
案件適格化済み
|
取引が事前定義された基準を満たし、追求する価値のある実行可能な機会と見なされることを示します。これは通常、「リードイン」のような初期のパイプラインステージから「コンタクト完了」や「ニーズ定義済み」のようなより適格なステージに取引が移行したときに推測されます。 | ||
|
その重要性
このマイルストーンは、リード適格化プロセスの有効性を分析し、商談が初期の非適格ステージにどれくらいの期間滞留しているかを正確に特定するのに役立ちます。
取得元
「stage_id」フィールドが適格化を示すステージに変更されたときに、取引の変更ログまたは履歴から推測されます。
取得
取引履歴から事前定義された「適格」ステージへのステージ変更を特定します。
イベントタイプ
inferred
|
|||
|
注文完了
|
製品が出荷されたか、サービスが顧客に提供されたことを示します。このイベントは、外部の履行または運用システムから発生します。 | ||
|
その重要性
フルフィルメントを追跡することは、注文から配送までのサイクルタイムを理解する上で重要です。ここでの遅延は、顧客満足度と収益認識に直接影響を与えます。
取得元
外部のERP、在庫管理、またはサービス管理システムから取得されます。このデータは対応するPipedriveの取引にリンクされている必要があります。
取得
外部システムからのイベントデータで、取引IDまたは別の共通識別子を介してリンクされています。
イベントタイプ
explicit
|
|||
|
請求書送付済み
|
顧客に支払い用の請求書が送信された瞬間を示します。このイベントは通常、注文履行後に外部の会計システムまたは請求システムでトリガーされます。 | ||
|
その重要性
これは支払いサイクルの開始を示します。このイベントから「支払い受領済み」までの時間は、売掛金とキャッシュフローを監視するために不可欠です。
取得元
XeroやQuickBooksのような外部の会計システムまたはERPシステムから発生します。イベントデータはPipedriveの商談と統合および関連付けされる必要があります。
取得
外部の請求システムからのイベントデータで、API連携を介して取引に関連付けられています。
イベントタイプ
explicit
|
|||
|
販売注文作成済み
|
商談が受注した後、ERPや会計プラットフォームなどの下流システムで正式な販売注文が作成されたことを示します。この活動はPipedriveに固有のものではなく、統合されたシステムからのデータに依存します。 | ||
|
その重要性
このイベントは、営業から運用または財務への引き継ぎを示します。「商談受注」からこの活動までの時間を分析することで、注文処理における潜在的な遅延を明らかにできます。
取得元
通常、接続されたERPまたは財務システムから捕捉されます。データは取り込まれ、Pipedriveの商談IDにリンクされる必要があります。
取得
外部システムからAPIを介してプッシュされたイベントデータで、多くの場合、Pipedriveの取引のカスタムフィールドを更新します。
イベントタイプ
explicit
|
|||