Chat Funnel Setup
チャットキャプチャリードのリードルーティング自動化
15名の営業チームは全てのWhatsAppリードを単一の「チャットチーム」にルーティングしていた：2名のジュニア担当者が受信した会話をトリアージし、テリトリースプレッドシートに基づいてアカウントオーナーとマッチさせて転送していた。最初のメッセージから正しい担当者が会話を見るまでの平均時間：3.5時間。そのスケールでの手動トリアージはまさにリードルーティング自動化が排除するように設計されているものだ。
Respond.ioで4つのルールタイプを使って自動ルーティングを構築した後、その数字は8分に下がった。トリアージ担当者は再配置された。応答時間は改善した。チャットリードのクローズ率は90日間で22%上昇したが、主にリードが最初の連絡と最初の本当の会話の間で冷め続けていなかったからだ。
このガイドはルーティングロジックと、1週間で手動トリアージから自動割り当てに移行するためのセットアップステップを提供する。
ステップ1：ルーティング次元を定義する
機能するルーティングロジックは観察可能な属性に基づくルーティングロジックだ。任意のプラットフォームでルールを構築する前に、割り当てを決定すべき4つの次元を定義する。
| 次元 | ルーティングの基準 | データの出所 |
|---|---|---|
| 地域 / テリトリー | 電話の国番号、コンタクトの国、または明示的な国の回答 | WhatsApp番号（自動）、クオリフィケーション質問 |
| 企業規模 | クオリフィケーションフローからの従業員数またはチーム規模の回答 | ManyChat/Respond.ioカスタムフィールド |
| 製品への関心 | クオリフィケーション中に選択された製品またはユースケース | クオリフィケーションフローのボタンレスポンス |
| リードスコア | 全クオリフィケーション回答に基づく複合スコア | Respond.ioスコアフィールドまたはカスタム式 |
最も一般的な間違いは1次元のみでルーティングすることだ。テリトリーのみのルーティングは、企業規模に関係なく全ての米国リードを米国チームに割り当てる。つまりエンタープライズ担当者がSMBリードを受け取り、SMB担当者がエンタープライズリードを受け取る。マルチ次元ルーティングでこれを解決する。Respond.ioのWorkflowsドキュメントは、ビジュアルビルダーでのマルチ属性ルーティングロジックの条件ノードの連鎖方法を説明している。リード配分戦略のより広いパターンはここでも適用される。チャネルはチャットだが、ルーティングロジックの問題は同じだ。
Respond.ioを開く前にルーティング次元をテーブルで定義する：
| テリトリー | 企業規模 | 製品への関心 | ルート先 |
|---|---|---|---|
| 日本 / 日本語圏 | 50名以上 | エンタープライズ製品 | エンタープライズチーム |
| 日本 / 日本語圏 | 50名未満 | SMB製品 | SMBチーム |
| APAC（英語圏） | 任意 | 任意 | APACチーム |
| グローバル | 任意 | 特定の機能 | プロダクトスペシャリスト |
これがルーティングルール設定の入力になる。
ステップ2：クオリフィケーション回答をルーティング属性にマッピングする
チャットボットのレスポンスは文字列（「50名以上」や「エンタープライズプラン」などのボタンクリック回答）だ。ルーティングルールは構造化された属性で機能する。2つの間で変換する必要がある。
ルーティングを設定する前にこのマッピングテーブルを構築する：
| クオリフィケーション質問 | 回答 | ルーティング属性 | ルーティングシグナル |
|---|---|---|---|
| 「営業チームの人数は？」 | 10名未満 | 企業規模 = 小規模 | SMBルート |
| 「営業チームの人数は？」 | 10〜50名 | 企業規模 = ミドルマーケット | ミドルマーケットルート |
| 「営業チームの人数は？」 | 50名以上 | 企業規模 = エンタープライズ | エンタープライズルート |
| 「フォーカスに最も当てはまるのは？」 | アカウントベースの営業 | 製品への関心 = ABM | ABMスペシャリスト |
| 「フォーカスに最も当てはまるのは？」 | ハイボリュームSDR | 製品への関心 = SDR | SDRスペシャリスト |
| 「今評価中ですかリサーチ中ですか？」 | 今評価中 | リード優先度 = ホット | ファストトラック割り当て |
| 「今評価中ですかリサーチ中ですか？」 | リサーチ中 | リード優先度 = ウォーム | 標準キュー |
ManyChatで、各ボタンレスポンスの後にSet Custom Fieldアクションを使って構造化フィールドにルーティング属性値を保存する。例えば、企業規模の質問の後：回答 = 「50名以上」の場合 → カスタムフィールド「company_size_tier」= 「Enterprise」に設定。
これにより、会話がRespond.ioに同期したときに機能するクリーンなルーティング属性が作成される。
ステップ3：Respond.ioでルーティングルールを構築する
Respond.ioでWorkflows → New Workflowに移動する。「Chat Lead Routing [日付]」と名前を付けてバージョン履歴を追跡できるようにする。
トリガー： コンタクト属性変更 → リード優先度 = ホット OR ワークフロートリガー = 会話作成（新しい会話をすぐにルーティングするため）
条件構造：
この優先順序で条件を構築する。Respond.ioは条件を上から下に評価し、最初のマッチで止まる：
ルール1：エンタープライズ + ホット
IF company_size_tier = Enterprise AND lead_priority = Hot
THEN 割り当て先：エンタープライズ営業チーム（ラウンドロビン）
ルール2：エンタープライズ + ウォーム
IF company_size_tier = Enterprise AND lead_priority = Warm
THEN 割り当て先：エンタープライズ営業チーム（キュー）
ルール3：APACテリトリー
IF contact.country IN [日本, オーストラリア, シンガポール, 韓国]
THEN 割り当て先：APACチーム
ルール4：GLOBALテリトリー（その他）
IF contact.country IN [UK, ドイツ, フランス, オランダ]
THEN 割り当て先：グローバルチーム
ルール5：SMB + 評価中
IF company_size_tier = Small AND lead_priority = Hot
THEN 割り当て先：SMB営業チーム（ラウンドロビン）
ルール6：デフォルト（マッチしたルールなし）
THEN 割り当て先：ジェネラル営業キュー + チームリードに通知
Respond.ioのWorkflowビルダーで、各ルールはConditionノードに続くAssignmentアクションだ。条件はステップ2でマッピングしたカスタムフィールド値を確認する。割り当てにより会話が正しいチームまたは担当者に送られる。
画面フロー：Respond.io → Workflows → New Workflow → トリガー追加：Contact Updated → 条件追加：[フィールド][演算子][値] → アクション追加：チーム/エージェントに割り当て → 公開
ライブにする前にまずテストモードでワークフローを公開する。Respond.ioのテストモードはシミュレートされたコンタクトをワークフロー経由で実行して、各ルールがライブになる前に正しくルーティングされるか確認できる。
ステップ4：カバーされていないルーティングのラウンドロビン
一部の会話は特定のルールにマッチしない。テリトリーリストにない国のリード、定義された階層外の企業規模、またはスペシャリストカテゴリに合わない製品への関心。
これらには、ジェネラル営業チームへのラウンドロビン割り当てを設定する。Respond.ioでSettings → Teams → [ジェネラル営業チーム] → Assignment Mode → Round Robinに移動する。
ラウンドロビンは利用可能なチームメンバー間に均等に会話を配布する。「利用可能」はオンラインで会話容量制限を超えていない担当者を意味する。
担当者あたりの会話容量制限を設定する：チャット中心の担当者には同時に10〜15件のアクティブな会話が妥当な数だ。それを超えると応答品質が低下する。Respond.ioで**Settings → Agents → [エージェント名] → Conversation Limit → [数字]**に移動する。Respond.ioのラウンドロビン割り当てガイドは、容量制限、利用可能モード、全エージェントが制限に達したときのオーバーフロー動作を説明している。
ジェネラルチームの全担当者が容量いっぱいになると、デフォルトの動作は会話をキューに入れることだ。これが発生したらすぐに知りたい。人員が不足していることを意味する。通知を追加する：会話が10分以上キューに入っている → Slackでチームリードに通知。
ステップ5：CRMオーナー同期
Respond.ioが担当者に会話を割り当てると、対応するHubSpotのコンタクトがオーナーフィールドを一致するように更新するべきだ。そうでなければHubSpotのレポートは間違った担当者にディールのクレジットを示し、担当者はHubSpotが別の人のものだと思っているコンタクトを管理していることになる。
Respond.ioからHubSpotへのオーナー同期：
Respond.ioでSettings → Integrations → HubSpot → Sync Assignmentに移動する。「HubSpotコンタクトオーナーとして担当者を同期する」を有効にする。これにより、Respond.ioで会話が割り当てまたは再割り当てされるたびにHubSpotのコンタクトオーナーフィールドが更新される。まだ完全なRespond.ioとHubSpotの統合を設定していない場合は、オーナー同期を有効にする前にそれを行うこと。そうでなければ、最初から正しく作成されていなかったコンタクトレコードに割り当てデータを同期することになる。
HubSpotからRespond.ioへ（双方向）：
チームがHubSpotで最初にディールを作成し、その後チャット会話にディールオーナーを反映させたい場合に便利だ。HubSpotコンタクトオーナーが変更したときにRespond.ioのContacts APIを呼び出してConversation Assigneeを更新するHubSpotワークフローが必要だ。
ほとんどのチームにとって、Respond.io → HubSpotの方向で十分だ。まずそちらから始める。
ステップ6：グローバルチームのためのテリトリールーティング
WhatsApp会話には電話番号に送信者の国コードが含まれている。+81プレフィックスは日本。+65はシンガポール。これが最も信頼できるテリトリーシグナルで、「どの国ですか？」とユーザーに聞くよりも信頼性が高い（それはすでにリーンなクオリフィケーションフローに質問を追加してしまう）。
Respond.ioでは、国コード検出は自動だ。コンタクトの国は会話が始まったときにWhatsApp番号から入力される。ルーティングルールでcontact.countryフィールドを使用する。
言語検出には、Respond.ioが最初の数メッセージで会話言語を識別する。conversation.languageを使用してスペイン語を話すコンタクトをスペイン語を話す担当者に、フランス語コンタクトをフランス語担当者にルーティングする。
タイムゾーン対応のルーティングは複数のタイムゾーンにまたがる担当者がいる場合に重要だ。Respond.ioではチームごとの勤務時間を設定できる。EST午前2時に到着するLATAMリードはLATAMチームの日中時間にルーティングするべきで、米国チームの夜間キューにではない。
チーム別勤務時間の設定： Settings → Teams → [LATAMチーム] → Working Hours → [ローカルタイムゾーンと時間を設定]。リードがチームの勤務時間外に到着した場合、ルーティングワークフローは翌営業日まで会話を保留するか、フォローアップ予約リンク付きの時間外ボットにエスカレーションするべきだ。
ステップ7：オーバーフロールーティング
オーバーフローは割り当てられた担当者またはチームが利用できない場合に発生する：休暇、病欠、容量超過。オーバーフロールーティングなしでは、リードはキューに積み上がり応答を受け取らない。
レベル1オーバーフロー：担当者が利用できない。 割り当てられた担当者がRespond.ioで自分を利用不可に設定した場合、会話はチームの次の利用可能な担当者に自動再割り当てされるべきだ。Settings → Teams → Assignment Rulesで、ラウンドロビンモードの「利用不可エージェントをスキップする」を有効にする。
レベル2オーバーフロー：チームが容量いっぱい。 割り当てられたチームの全担当者が会話制限に達した場合、会話はセカンダリーチームにオーバーフローするべきだ。ルーティングワークフローにフォールバック条件を追加する：プライマリーチームの容量がいっぱいの場合 → セカンダリーチームに割り当て。
レベル3オーバーフロー：時間外または全チームが容量いっぱい。 会話は自動保留メッセージを受け取り、翌朝の優先フォローアップのためにフラグが立てられる。保留メッセージにはカレンダー予約リンクを含めるべきだ。ワークフローリマインダーを設定する：会話ステータス = 待機中 AND 経過時間 > 8時間 → チームリードに通知 + 翌朝優先キューのフラグを立てる。
ステップ8：ルーティング精度の測定
ライブルーティングの30日後、誤ルーティング監査を実行する。最近ルーティングされた会話50件を確認し、ルーティング決定が正しかったかどうかを確認する。
「正しい」とはつまり：会話を受け取った担当者がルーティングロジックに基づいてそのリードに適切な担当者だったこと。米国エンタープライズリードがSMBチームに行くのは誤ルーティングだ。EMEAリードが米国チームに行くのは誤ルーティングだ。
目標の誤ルーティング率：5%未満。5%を超えている場合、最も一般的な誤ルーティングタイプを特定して、失敗しているルーティングルールを追加または調整する。
高い誤ルーティング率の一般的な原因：
- コンタクトの国フィールドが空（実際の国に結びついていないVoIPサービスのWhatsApp番号）
- クオリフィケーションフローが早期に離脱したため企業規模フィールドが入力されなかった
- ルーティングルールが重複している（コンタクトが2つのルールにマッチして誤った方に最初にルーティングされる）
各原因には異なる修正がある。空の国フィールドにはフォールバックルールが必要だ。不完全なクオリフィケーションにはチャットボットの部分完了パスが必要だ。重複するルールにはルーティングワークフローの優先順位の並び替えが必要だ。
よくある落とし穴
1次元のみでのルーティング。 テリトリーのみのルーティングルールは企業規模、製品適合、優先度に関係なく全ての米国リードを米国チームに割り当てる。少なくとも2次元を追加する。
マッチしないルールのフォールバックがない。 リードがどのルールにもマッチしない場合、どこにも行かない。マッチしないリードをジェネラル営業チームに割り当て、チームリードへの通知付きのキャッチオールフォールバックルールを追加する。
個人ではなくチームへのルーティング。 「営業チームに割り当て」は誰かが手動で会話を拾うまで誰も所有しないことを意味する。チーム内でラウンドロビンを使用して特定の担当者に即座に割り当てる。
割り当て時の担当者への通知がない。 担当者に会話をルーティングしても自動的にアラートは来ない。ルーティングワークフローに割り当て直後の通知ステップ（Slackメッセージ、メール、またはRespond.ioプッシュ通知）が含まれていることを確認する。
次のステップ
ライブトラフィックに接続する前に、Respond.ioのテストモードで30件のシミュレートされた会話をルーティングワークフロー経由で実行する。様々な入力（エンタープライズ/日本、SMB/APAC、不完全なクオリフィケーション、時間外到着）を使用して、各会話が正しい宛先にルーティングされるか確認する。
その後、5名の担当者（全員ではない）でライブモードでワークフローを1週間実行する。最初の週は毎日ルーティング精度を確認する。フルチームにスケールする前に少ない量で問題を修正する。
