新しいリードが登録される
テリトリー、製品、セグメント、取引先担当、または負荷分散に基づいて割り当て、その理由と時刻を記録します。
重複、不完全、戦略的、担当者競合のレコードをトリアージへ振り分けます。
判断の根拠と手動例外ルートを可視化したまま、リードを振り分け、優先順位付けし、通知、エスカレーション、商談化します。
自動化では、リードを優先、再割り当て、保留した理由を隠さずに、反復的な調整作業を減らすべきです。
チームが説明できるルールから始め、すべての例外を指定担当者へ振り分けます。
テリトリー、製品、セグメント、取引先担当、または負荷分散に基づいて割り当て、その理由と時刻を記録します。
重複、不完全、戦略的、担当者競合のレコードをトリアージへ振り分けます。
適合性、決裁権、時期、スコアがしきい値を超えたら、優先度を再計算するかレビュー対象として表示します。
高価値、規制対象、パートナー経由、矛盾する根拠がある場合は、人によるレビューを必須にします。
担当者に通知し、期限対象業務ビューにアクションを表示します。
SLA超過、期限未設定、未確認の再割り当てをエスカレーションします。
商談を作成または関連付け、承認済みの発生源情報と精査内容を引き継ぎます。
必須の根拠、担当者、同意、取引先照合が未完了なら、商談化を保留します。
データが不足した場合や担当が競合した場合の動作をチームが把握して初めて、ルールは実用可能になります。
代表的なリードが、理由の記録とともに想定担当者へ届きます。
判断が難しいリードがレビューされず、1つの既定キューに入ります。
スコアは表示項目を使用し、定義済みの判断またはレビューにつながります。
リードが優先された理由をユーザーが説明できません。
担当者はSLA違反前に期限対象の業務を確認でき、マネージャーは期限超過レコードを開けます。
通知は送られても、業務キューが更新されないままです。
発生源、精査内容、担当者、メモ、次の合意事項を商談に関連付けたまま保持します。
商談が、リードの系譜がない空のレコードとして始まります。
振り分け条件、しきい値、リマインダー、例外経路を一度に1つだけ変更し、代表的なリードでテストします。
振り分けルールの変更は、CRM管理、コンサルタント、連携テスト、リリース時期の都合で待たされることがあります。
訓練を受けたJodoo管理者なら、多くの場合、条件、選択肢、ビュー、リマインダー、エスカレーション経路を調整し、サンプルレコードでテストできます。
まずは明確なルールによる調整から始めます。割り当て、受領確認、期限業務の通知、停滞リードのフラグ、必須項目チェック、エスカレーションです。根拠と例外ルートが明確になってから、スコアリングや商談化の自動化を追加します。
Jodooは設定した項目とルールに基づいて計算や振り分けを行えます。専門的なレベニュープラットフォームと同等の予測型データ補完やAIスコアリングを提供するものではないため、そのモデルが要件なら専用システムを使用してください。
トリガーデータ、ルール結果、担当者、タイムスタンプ、例外状況を記録します。データ不足、担当者の競合、SLA違反、手動上書きを処理するキューを運用部門に提供します。
自社が管理するレコードを中心に、透明性のある振り分け、リマインダー、レビュー経路、変換手順を構築します。
専用システムが独自データ、スコアリングモデル、チャネル施策を提供し続ける一方で、Jodooはそれらを中心にリード判断を調整できます。