B2Bリードを実際にクオリファイするManyChatフローの構築

あるB2B SaaS企業が最初のチャットボットを6週間稼働させた。フローは8つの質問をした。質問3でのドロップオフは40%だった。質問8までに、フローを完了したユーザーは20%未満だった。チャットからのMQL率はコンタクトフォームよりも低かった。

フローを4つの質問に再構築した。ドロップオフは18%に下がった。MQL率は倍増した。変わったのは質問数と各質問の書き方だけだった。

ほとんどのチャットボットフローが失敗する理由は2つある：質問が多すぎること、そしてフォームの言葉で質問すること。「会社名を入力してください」はフォームだ。「あなたのチームに最も当てはまるのはどれですか？」と3つのボタンは会話だ。完了率の差は顕著であり、データ品質の差はさらに大きい。どのプラットフォームから構築するかを検討している場合、B2B営業チームのためのManyChat vs Respond.io比較がトレードオフを詳しくカバーしている。

このガイドは、B2BリードのためのManyChatクオリフィケーションフローの設計と構築方法を示す：4メッセージでクオリファイし、回答に基づいてルーティングし、担当者が実際に必要なデータを含む構造化されたCRMコンタクトを作成する。

ステップ1：ManyChatを開く前に4つのクオリフィケーション次元を定義する

ManyChatで何かを構築する前に、リードが適合しているかどうかを示す4つのデータポイントをマッピングする。このステップには通常30分かかり、ほとんどのチームはスキップする。スキップしないこと。

標準的なB2Bクオリフィケーション次元：

1. 企業規模：虚栄の指標ではない。価格設定、セールスモーション、実装の複雑さはすべて企業規模に依存する。5人チームと200人チームは異なる営業会話だ。

2. 役割またはシニオリティ：意思決定者か評価者かを話しているか？これにより、デモを予約するかリソースを送るかが決まる。

3. 問題適合：彼らはあなたの製品が解決する問題を持っているか？これを質問として聞くことで、彼らが自分の課題をどのように説明するかについての洞察が得られ、担当者はそれを反映させることができる。

4. タイムライン：今評価しているか、来四半期に調査しているか？これは他のほぼどんな次元よりもルーティングの優先度を決定する。

これらはBANT（Budget、Authority、Need、Timeline）にほぼ対応しているが、予算について最初に明示的に聞く必要はない。予算は通常、最初の担当者との会話で出てくる。チャットで早すぎる段階で聞くのは出しゃばりに感じる。ManyChatのWhatsAppフローの公式ドキュメントは、ボタンレスポンスとカスタムフィールドの設定のためのステップバイステップフロービルダーインターフェースをカバーしている。これらの次元がさまざまなセールスモーションタイプにどのようにマッピングされるかの完全なフレームワークについては、リードクオリフィケーションフレームワークがBANT、MEDDIC、CHAMPを並べてカバーしている。

フローを構築する前に4つの次元をテーブルに書き出す：

次元 質問 レスポンスタイプ ルーティングシグナル
企業規模 「営業チームの人数は？」 ボタン（10名未満 / 10〜50名 / 50名以上） サイズのしきい値
役割 「あなたの役割に最も当てはまるのは？」 ボタン（マネージャー / ディレクター / C-Level / IC） 意思決定者フラグ
問題適合 「現在の最大の課題は何ですか？」 ボタン（3〜4のオプション） 製品適合フラグ
タイムライン 「今ソリューションを評価していますか、まだリサーチ中ですか？」 ボタン（今 / 1〜3ヶ月以内 / リサーチ中） ルーティング優先度

ステップ2：各メッセージをフォームではなく会話として書く

完了するチャットボットとそうでないチャットボットの違いは通常1つのことに帰着する：ボタンオプション対自由記述フィールド。

予測可能な回答がある全ての質問にボタンを使用する。 ボタンはフリクションを減らし、クリーンなカテゴリ化を強制し、文字列解析なしでルーティングロジックを機能させる。「連絡できる最適な番号はどちらですか？」のようなフィールドには自由記述で構わないが、クオリフィケーション質問には使わない。

カンファレンスでのスモールトークをしている人のトーンで各メッセージを書く。フォームを記入するようにではなく：

悪い例（フォームのトーン）： 「会社の規模を選択してください：

  1. 1〜10名
  2. 11〜50名
  3. 51名以上」

良い例（会話のトーン）： 「簡単な質問：今の営業チームの規模はどのくらいですか？」 ボタン：自分だけ / 2〜10名 / 10名以上

違いは微妙だが4つのメッセージにわたって蓄積される。会話的なフレージングはまた、ユーザーを離脱させる「ロボットと話している」感覚も減らす。

各メッセージを3行以内に保つ。超える場合は削除する。ユーザーはテキストメッセージのようにチャットメッセージを読む。チャットウィンドウの長い段落は不自然に感じる。

ステップ3：ManyChatでフローを構築する

トリガー設定：

ManyChatでAutomation → Flow Builder → New Flowに移動する。エントリーポイントをMeta広告ソースにリンクされたWhatsApp Entry Pointとして設定する。Click-to-WhatsAppキャンペーンのために構築している場合は、Growth Tools → WhatsApp Entry Pointsに移動してエントリーポイントをキャンペーンに接続する。

メインのクオリフィケーションフローにはキーワードトリガーを使用しない。キーワードトリガーはキーワードを含む任意のメッセージで発火し、既存の顧客やカスタマーサービスの問い合わせを含む。広告ソーストリガーは接続された広告から開始した会話のみで発火する。

フロー構造：

このシーケンスでフローを構築する：

  1. ウェルカムメッセージ + 質問1（ボタンレスポンス付き）
  2. カスタムフィールドの設定アクション（Q1の回答を保存）
  3. 質問2メッセージ（ボタンレスポンス付き）
  4. カスタムフィールドの設定アクション（Q2の回答を保存）
  5. 質問3メッセージ（ボタンレスポンス付き）
  6. カスタムフィールドの設定アクション（Q3の回答を保存）
  7. 質問4メッセージ（ボタンレスポンス付き）
  8. カスタムフィールドの設定アクション（Q4の回答を保存）
  9. 条件ノード（ルーティングロジック）
  10. ブランチアクション（ホット / ウォーム / ディスクオリファイド）

各質問の後のカスタムフィールドの設定アクションは重要だ。ManyChatはフローでマッピングした場合、ボタンクリックの回答を自動的にカスタムフィールドに保存する。これがなければ、ルーティングやCRM同期にデータを使用できない。

ManyChatでの条件付きルーティング：

4つの回答を全て収集した後、条件ノードを追加する。この順序で条件を設定する：

ホットリードの条件（3つすべてが当てはまる必要がある）：

  • 企業規模 = 10〜50または50以上
  • タイムライン = 今評価中
  • 役割 = ディレクターまたはC-Levelまたはマネージャー

ウォームリードの条件（以下のうち2つ）：

  • 企業規模 = 10〜50または50以上
  • タイムライン = 1〜3ヶ月以内
  • 問題適合がICPと一致

ディスクオリファイドの条件（ホットでもウォームでもない場合のデフォルト）：

  • 企業規模 = 10名未満
  • タイムライン = リサーチ中
  • 問題適合なし

ステップ4：ルーティングロジック（3つの宛先）

ホットリード：すぐに電話を予約する。 「了解です、適合していそうです。チームのメンバーが60分以内にWhatsAppでご連絡します。待ちたくない場合は、直接時間を予約できます：[Calendlyリンク]。連絡できる最適な番号はどちらですか？」

HubSpotコンタクト作成アクションを追加してライフサイクルステージをMQLに設定する。担当者への通知をすぐにトリガーする（ステップ6で説明）。

ウォームリード：ナーチャリングシーケンス。 「共有していただきありがとうございます。役立つリソースをいくつかお送りします。チームのメンバーが1〜2日以内にフォローアップします。送り先のメールアドレスを教えていただけますか？」

メールアドレスを収集し、ライフサイクルステージ = リードでCRMに追加し、HubSpotを通じて3通のメールナーチャリングシーケンスに登録する。

ディスクオリファイドリード：リソースを送り、担当者に割り当てない。 「お問い合わせありがとうございました！共有いただいた内容に基づいて、役立ちそうなリソースです：[リンク]。適切なタイミングでまたご連絡ください。」

担当者への通知なし。CRM MQLなし。将来の再エンゲージメントキャンペーンのためにコンタクトを保存する。

ルーティングマトリックスのまとめ：

企業規模 タイムライン ルート
50名以上 今評価中 ホット
10〜50名 今評価中 ホット
10〜50名 1〜3ヶ月以内 ウォーム
10名未満 なんでも 問題適合によりウォームまたはディスクオリファイ
なんでも リサーチ中 ウォーム

ステップ5：CRMデータの転送

ManyChatからHubSpotへ（ネイティブ統合）：

ManyChatでIntegrations → HubSpotに移動する。OAuthで接続する。接続後：

  • 各ManyChatカスタムフィールドをHubSpotのコンタクトプロパティにマッピングする
  • 重複を防ぐために「コンタクト作成または更新」を使用する
  • 主なマッチングキーとして電話番号を設定する（まだメールがないかもしれないため、メールではない）

最低限マッピングするフィールド：

ManyChatカスタムフィールド HubSpotコンタクトプロパティ
名前（First Name） 名前（First Name）
電話番号 電話番号
企業規模の回答 従業員数の範囲（カスタムプロパティ）
役割の回答 役職
問題の回答 リードノート
タイムラインの回答 購買意向
リードルート ライフサイクルステージ
フロー完了日 最終アクティビティ

ManyChatのネイティブ統合がないCRM（Salesforce、Pipedriveなど）の場合：

各ルーティングブランチの最後にWebhookアクションを追加する。CRMのAPIエンドポイントにPOSTするように設定する。ほとんどのCRMにはコンタクト作成リクエストを受け入れるREST APIがある。ManyChatのHubSpot統合ガイドは、ネイティブフィールドマッピングインターフェースとOAuth接続フローのステップバイステップをカバーしている。チャットソースのコンタクトを現在のCRMが適切に処理するかを評価している場合、Rework vs HubSpot CRM比較は成長する営業チームのためにこれを直接扱っている。

WebhookボディにはManyChatのWebhookエディタの{{custom_field_name}}マージタグを使用して収集した全てのカスタムフィールド値を含める。

ステップ6：担当者への通知

ホットリードがブッキングブランチにルーティングされたとき、担当者はすぐに通知を受け取る必要がある。日次ダイジェストではない。

ManyChatでSend EmailまたはWebhook to Slackアクションを使って担当者への通知を構築する。通知には以下を含める：

新しいホットリード - WhatsApp
名前：[名] [姓]
電話番号：[電話番号]
企業規模：[企業規模の回答]
役割：[役割の回答]
課題：[問題の回答]
タイムライン：[タイムラインの回答]
フロー完了：[タイムスタンプ]
直接返信リンク：[会話を開くWhatsAppリンク]

直接返信リンクは重要だ。担当者がManyChatまたはRespond.ioに移動して会話を探す必要がある場合、応答時間が上がる。1タップで開けるようにする。

ホットリードには5分の応答SLAを設定する。ManyChatまたはRespond.ioで、会話が5分後も未割り当ての場合にエスカレーション通知を設定できる。バックアップ担当者またはチームリードに2回目の通知が届く。

ステップ7：ライブトラフィックを接続する前のテスト

ManyChatのこのフローをテストボタンを使ってフローを自分でウォークスルーする。しかし別のデバイスの実際のWhatsApp番号から別途テストも実行する。テストモードは特にモバイルでのボタンレンダリングに関して、実際のユーザーエクスペリエンスを常に再現するわけではない。

テストシナリオチェックリスト：

シナリオ 期待される結果
ホットリードの回答（大チーム、今評価中、ディレクター） ブッキングメッセージにルーティング；担当者への通知が発火；HubSpotコンタクトがMQLとして作成
ウォームリードの回答（小チーム、リサーチ中、マネージャー） ナーチャリングメッセージにルーティング；メール収集；HubSpotライフサイクル = リード
ディスクオリファイドの回答（10名未満、リサーチ中） リソースメッセージにルーティング；担当者への通知なし；HubSpot MQLなし
ユーザーがQ2後に返信を止める フローが一時停止；24時間後にフォローアップメッセージが発火（設定している場合）
既存の顧客が広告経由でメッセージを送る ソースフィルターがクオリフィケーションフローのトリガーを防ぐ
ユーザーが予期しないボタンレスポンスを送る フォールバックメッセージが表示；担当者が未処理のレスポンスを通知される

各ホットおよびウォームテスト実行後にCRMを確認して、コンタクトが正しいフィールド値で作成されたことを確認する。ライブ広告トラフィックにフローを接続する前にマッピングの問題を修正する。

よくある落とし穴

質問が多すぎる。 4つ目以降の各質問はコンプリーション率をおよそ10%下げる。8質問のフローはルーティング決定に到達する前にほぼ半数のレスポンダーを失う。8つの質問が必要だと思うなら、まずより鋭いICPが必要だ。

ボタンが機能する場所に自由記述。 「最大の課題は何ですか？」という自由記述フィールドは会話的に聞こえるが、CRMがカテゴリ化できない非構造化データを生む。「これらのうち最も当てはまる課題はどれですか？」と4つのボタンはクリーンなルーティング属性を生む。

反応のないリードを処理しないルーティングロジック。 一部のユーザーはフローを開き、1〜2つの質問に回答して止まる。ルーティングロジックが4つの回答を全て必要とする場合、反応のないユーザーはルーティング決定に到達せずゴーストコンタクトとして落ちる。部分完了パスを追加する：24時間後に回答がない場合、ウォームにルーティングして担当者に通知する。

予期しない回答のフォールバックがない。 ユーザーがボタンクリックを期待している場所に自由記述で回答した場合、ManyChatは正しくルーティングできない。条件ノードに、未一致のレスポンスをキャッチしてボタン付きの質問に戻す「キャッチオール」ブランチを追加する。

次のステップ

フローを最適化する前に、最も適した顧客3人にインタビューする。こう聞く：「チャットウィンドウで私たちに連絡して4つの質問をされたとしたら、話す価値があると分かるのはどの4つですか？」彼らの回答はどんなフレームワークよりも優れている。

その後、最も適した顧客が言ったことに合わせて4つのクオリフィケーション次元を調整する。更新されたフローを30日間実行して、現在のベースラインとホットリード率を比較する。

関連リンク