【ITニュース解説】Inbound lead qualification from the email domain: company record, decision makers and the gmail case, with Apify Actors and n8n

顧客からの問い合わせ、いわゆるインバウンドリードの質を自動で判断し、適切な対応に振り分けることは、企業の営業活動において非常に重要である。しかし、問い合わせフォームに顧客が入力する情報は自己申告であるため、常に信頼できるとは限らないという課題がある。例えば、実態と異なる役職を名乗ったり、架空の会社名を記入したりするケースも考えられる。

この課題を解決するため、ニュース記事では、問い合わせメールアドレスのドメイン（@以降の部分）という客観的な情報に着目し、これを基にリードの質を自動で評価するシステムについて解説している。具体的には、データ収集と処理を行うプログラム群であるApify Actorsと、それらを連携させてワークフローを自動化するn8nというツールを活用している。

このシステムは主に四つのステップでリード情報を分析する。

最初のステップは、ドメインから企業情報を取得することである。 問い合わせメールのドメイン（例: hubspot.com）をApifyの「Company Enrichment by Domain」というActorに渡すと、そのドメインに関連する企業の詳細情報が返ってくる。これには、企業名、従業員数、業種、本社所在地、設立年などが含まれる。例えば、hubspot.comからは「HubSpot」という企業の詳細な情報が得られる。このステップでは、ドメインが「解決された」（企業情報が見つかった）かどうかの「_status」も重要な情報である。 しかし、ここで注意が必要な「罠」が存在する。それは、gmail.comのようなフリーメールドメインの場合である。このActorは、gmail.comをウェブサイトとして登録している実在の企業を見つけることがある。もし、この情報を鵜呑みにすると、gmail.comで登録した全てのリードがその企業に所属していると誤って判断してしまう可能性がある。これを避けるためには、事前にフリーメールのリストを用意しておき、該当する場合は別の処理に回すか、「_matchCandidates」という項目を確認する必要がある。この項目は、一つのドメインに対して複数の企業情報が見つかった場合に表示され、大きなブランドが複数の部門を持つ場合などにも発生し得る。また、誤入力されたドメインや存在しないドメイン（例: hubspot.co、formfill-demo.invalid）は「not_found」や「unresolved_domain」として扱われ、これらの場合は人間による確認が必要だと判断される。これらはスパムではなく、単なる「不明」な情報であり、その情報をさらに深掘りするべきである。

二番目のステップは、ドメインから意思決定者の情報を取得することである。 同じくメールのドメインをApifyの「Decision Maker Email Finder by Domain」というActorに渡すと、その企業の上層部、例えば創業者やCEO、VPといった意思決定者の名前や役職、勤務開始年などの情報が返される。このActorは、特定の役職を持つ人物を最大2名まで取得するように設定できる。この情報は、フォームを送信した人物が、本当にその企業の意思決定者であるかを確認したり、もしそうでなければ誰を最初の返信メールにCCすべきかを判断したりするのに役立つ。 ここでも注意点がある。gmail.comのような広範なドメインは「domain_too_broad」（ドメインが広すぎる）と判断され、特定の企業の意思決定者を見つけることはできない。また、大学（例: mit.edu）のような教育機関では、一般的な企業が持つような「創業者」や「C-level」（最高経営責任者クラス）の概念が異なるため、「no_decision_makers」（意思決定者なし）と返される。これらのケースも、人間による確認が必要なリードとして処理されるべきである。

三番目のステップは、送信者が申告した役職を検証することである。 問い合わせフォームで送信者が名乗った役職（例：「VP Sales」）が、その企業の規模や実態と合致しているかを検証する。Apifyの「People Search in count mode」というActorを使うと、特定のドメインを持つ企業に、特定のキーワード（例: 「sales」）を含む役職の人物が何人いるかを数えることができる。例えば、ある企業が従業員数79人にもかかわらず、営業機能を持つ人がゼロと出た場合、「VP Sales」という申告は疑問符が付く可能性がある。もちろん、ゼロだからといって必ずしも嘘であるとは限らず、新設された部署である可能性もあるため、直ちにリードを拒否するのではなく、人間が詳細を確認するためのフラグとして利用する。

四番目のステップは、ドメインがない場合、つまり個人メールアドレスの場合の対応である。 gmail.comやhotmail.comのようなフリーメールアドレスで問い合わせが来た場合、ステップ1〜3のドメインに基づく分析はできない。そこでApifyの「Reverse Email Lookup」というActorにメールアドレスを渡すことで、そのメールアドレスの持ち主の現在の役職、雇用主、所在地、職歴といった個人情報を取得する。これにより、フリーメールの背後にいる人物が、実はどの企業でどのような役職に就いているのかを特定できる。 ここでの「罠」は、取得した職歴に複数のオープンな役職が含まれる場合があることだ。例えば、リストでは「航空サービス会社の営業部長」とあったが、ルックアップでは別の航空会社の「ディレクター」という情報が返ってきた場合、どちらを信じるべきかという問題が発生する。この場合、「experience.work」という項目に記載された複数の職歴と開始日を参照し、問い合わせフォームに書かれた内容と合致する方を優先して採用する判断が必要になる。

これら四つのステップで得られた情報は、n8nのようなワークフロー自動化ツールを使って連携され、最終的なリードのルーティングルールを自動的に適用する。例えば、存在しないドメインからの問い合わせは「人間による確認」に、フリーメールからの問い合わせは「個人メールアドレスの情報を基に判断」に、企業情報が健全で役職も妥当であれば「ホットリードとして営業担当者に割り当て、意思決定者をCCに含める」といった具合である。n8nのワークフローでは、Webフォームからの入力をトリガーとするWebhookノードから始まり、IFノードでの条件分岐、ApifyノードでのActor実行、そして最終的にCRMシステムやSlackへの連携を行う。

この自動化システムの信頼性を確保するためには、取得したデータのいくつかの項目をチェックすることが重要である。例えば、各Actorの実行結果に含まれる「_status」は、情報が見つかったか、ドメインが広すぎたか、意思決定者が見つからなかったかなど、その結果の理由を示しているため、適切な判断を下す上で不可欠である。「_matchCandidates」は、ドメインに複数の企業情報が紐付いている場合に、選ばれた企業情報が組織全体の一部である可能性を示唆し、追加の確認が必要なケースを教えてくれる。「_freshness」はデータの鮮度を示すもので、情報が古い場合は現在の状況と一致しない可能性があるため、注意が必要である。

このように、メールアドレスのドメイン情報を起点に、複数のApify Actorsをn8nで連携させることで、自己申告に頼らず、客観的なデータに基づいてインバウンドリードの質を自動的に評価し、営業活動を効率化するシステムを構築できる。これにより、営業担当者は質の高いリードに集中し、適切なアプローチを迅速に行うことが可能になるのである。