獲得は速いが初回応答は遅い
新しい需要は、チームが担当者を決めるまで待たされています。
発生源、地域、製品、セグメント、対応余力に基づいて担当者と回答期限を割り当てます。発生源とニーズを記録し、明確な根拠で精査し、適切な担当者を割り当て、背景情報を失わずに準備済みの需要を商談へ変換します。
目的は名前を多く集めることではありません。注力すべき需要と、次に行うべきことを判断することです。
リード管理の問題の多くは、データの問題に見える担当責任と判断の問題です。
新しい需要は、チームが担当者を決めるまで待たされています。
発生源、地域、製品、セグメント、対応余力に基づいて担当者と回答期限を割り当てます。ニーズ、決裁権、時期、適合性が不明でも、数値だけでリードが次へ進む。
スコアとともに基準、レビュー担当者、メモ、判断、次のアクションを保持します。受入、拒否、再育成、変換済みのリードを照合できなくなる。
ライフサイクルの状態と、各状態へ移行・退出するために必要な根拠を定義します。マネージャーにはステータスだけが見え、その背景にある顧客との合意や期限超過アクションが見えません。
活動、期限、結果、商談化を元のリードに関連付けます。ワークフローでは最新ステータスだけでなく、リードが移行した理由も保持する必要があります。
発生源、キャンペーンまたは紹介元、同意、連絡先詳細、企業情報、ニーズ、関心製品、受領日時を記録します。
重複、テリトリー、セグメント、既存取引先の担当者、不足情報、対象外条件を確認します。
課題適合性、決裁権、時期、チーム規模、根拠、スコア、レビュー担当者の判断を確認します。
受け入れたリードに担当者、SLA、次のアクション、期限、エスカレーションルートを設定します。
発生源情報を保持したまま商談を作成するか、理由と次回レビュー日を記録します。
アプリケーションには関連付けられた8件のサンプルが用意されており、チームは各シグナルの対象レコードを確認できます。
すべてのサンプルリードに、初回応答と次のアクションに責任を持つ担当者を設定します。
4件のサンプルレビューは「精査済み」または「失格」に到達し、残りのレコードは引き続きレビューまたは確認が必要です。
サンプルの各アクションに、担当者、期限、ステータス、推奨される次ステージを設定します。
4件のサンプルリードは次へ進める状態で、その他はレビュー、育成、失格判定中です。
リードの定義や振り分けルールは変化します。システム全体を置き換えずに、変更された項目、判断、キューだけを更新できます。
精査ルールの更新は、CRM管理、コンサルタント、連携確認、テスト、リリース時期の都合で待たされることがあります。
訓練を受けたJodoo管理者なら、多くの場合、精査フィールド、選択肢、振り分けビュー、リマインダー、ダッシュボード指標を調整し、サンプルリードで変更をテストできます。
最低限、発生源、同意、連絡先と企業の背景、業務ニーズ、精査の根拠、スコアまたは判断、担当者、ステータス、次のアクション、期限、拒否または再育成の理由、商談への変換を管理します。
いいえ。リード管理では、需要が実在し、精査され、担当者が決まっているかを判断します。パイプライン管理では、精査済み商談、営業ステージ、金額、リスク、移行、ポートフォリオ判断を統制します。
通常、スコアだけで商談化すべきではありません。スコアでレビューの優先度は決められますが、商談化では営業プロセスに必要な根拠、判断、担当者、例外ルートを保持する必要があります。
チームの需要精査方法に合わせて、受付、レビュー、割り当て、フォローアップ、変換のレコードを構築します。
Jodooでリードを受け付けて管理しながら、広告、データ補完、インテントデータ、シーケンス、メール到達率、マーケティング貢献度の専用製品に専門業務を任せられます。