Contents
前書き
タイトル通り、Webフォームなどから流入してきたリード（orプロスペクト）をISにどのようにパスするのかという話
素朴なやり方
おそらく一番素朴な方法は、「一旦全てリードに流して、ISが入ってきたリードを（既存顧客でないかなど）チェックして、架電する」という流れ。
ISが全リードをチェックできる規模感であればこの方法で問題ないが、「スコアリングやグレーディングに基づいてMQLだけをパスしたい」・「既存顧客やNG顧客でないかのチェック工数が大きい」という場合は、MQLだけがパスされるかたちにする必要がある。
どのようにしてMQLをパスするか？
結論、「MQLのリードor取引先責任者にだけ架電ToDoが作成されるようにする」のがベストプラクティスである。
スコアリングやグレーディングに関して閾値を超えたリードにのみ架電ToDoが生成されるようにすることで、「Marketing Qualified判定」の問題と「重複レコード生成」の問題が同時に解決される（※重複レコード問題については「Emailベースで一意性を判定する」というMAツールの仕様によって回避される）
またToDoベースでの管理によって、失注時掘り起こしリマインドなども容易となる。
ToDoを利用しない場合は、以下のどちらかの方針が有力となる。
①プロスペクトにユーザを割り当てるタイミングを制御することで、一定の基準を満たしたプロスペクトだけがリードとして生成されるようにする。
→既にリード・取引先責任者レコードが存在する場合に新規レコードが作成されないというデメリットあり（※これは実質的に顧客エンゲージメント起点での失注リード・失注商談への再アプローチが不可能であることを意味する）
→また、「問い合わせ受付にPardotを利用している」ような場合、（条件に関わらず問い合わせ客に関するSFレコードの作成が必要となるため、）流入してきたリードが「見込み顧客」なのか「問い合わせ」なのかの区別を結局入ってきたレコードを見てその都度判別する手間が必要となるというデメリットもある。
②MQLを満たしたリード（＆取引先責任者）のリストを何かしらの仕方で作成し、確認すること
→リスト作成の工数に加えて、諸々の属性情報を各レコードの項目として持たせる必要があるため、ToDo運用と比べて相対的に煩雑な実装となるというデメリットあり