代理店問い合わせの振り分け方法

Hiway編集部·9/25/2026

メール、フォーム、チャット、代理店ポータルに入口が散ると、困るのは対応件数の多さだけではありません。見積依頼は営業へ、申請不備は運用へ、障害やクレームは責任者へ回したいのに、その基準が担当者の頭の中にしかない状態になりやすいからです。結果として、一次返信はできても、案件化・エスカレーション・CRM反映がばらつきます。

代理店問い合わせの振り分けとは、代理店から来た連絡を、受付時点で必要な属性に分け、適切なキューや担当へ回し、必要に応じて人の判断へ引き継ぐ運用設計のことです。課題は「AIで自動化できるか」より先に、「何を入口で集め、どこから先を人が持つか」を決めることにあります。

Key Takeaways

代理店問い合わせの振り分けは、担当者への単純なアサインではなく、一次分類、キュー分岐、最終担当配賦、人への引継ぎ条件まで含めて設計すると安定します。
主要CRMやサポート基盤では、条件ベースのルール、キュー、優先度、営業時間、オーバーフロー、エスカレーションを公式にサポートしています。まずは現行システムで足りる範囲を見極めるべきです。
AI活用が効きやすいのは、自由文メール、添付付き依頼、代理店ごとの差分、既存案件との突合、CRMへの構造化反映が負担になっている場面です。
価格、契約、障害、チャネルコンフリクトの可能性がある案件は、自動回答より人への引継ぎ条件を先に決めるほうが事故を防げます。
導入判断では、未分類率、再振り分け率、エスカレーション率、CRM反映率を確認し、受付項目と権限設計が揃うかを見ます。

1. 振り分けが止まりやすいのは、問い合わせの種類より入口設計です

代理店からの問い合わせが混乱する組織では、「件名に見積と書いてあるから営業へ」「いつもの代理店だからその担当へ」という処理が増えます。短期的には回りますが、次の問題が残ります。

既存案件への追加相談なのか、新規案件相談なのかが分からない
申込や更新依頼なのに営業が受けてから運用へ転送している
FAQで返せる質問まで人手で処理している
価格や契約条件を含む相談が、確認前に返答される
やり取りがCRMに戻らず、支援履歴が残らない

Hiwayの代理店管理ユースケースでも、代理店経由の案件相談、進捗報告、見積依頼がメールや個別ファイルに散り、本部側で案件や活動履歴を追いにくいことが課題として示されています。さらに、代理店からの問い合わせや申請を一つの入口に集め、案件・取引先・担当者・次アクションとして構造化する考え方が示されています。これは、振り分けを単なる受付処理ではなく、営業プロセスの入口として扱う発想です。出典: Hiway 代理店管理

ここで見直すべきは、担当者名簿ではありません。入口です。

2. 最初に決めたい一次分類は6種類です

すべての問い合わせを細かく分類しようとすると、現場は入力しなくなります。先に必要なのは、一次分類を6種類前後に絞ることです。これは製品公式の固定要件ではなく、主要ベンダーのルーティング思想と代理店実務を踏まえた提案例です。受付件数が少ない組織では、初期は4分類程度から始めても構いません。

提案例: 一次分類の基本6区分

資料請求・FAQ

製品資料、制度説明、よくある質問への回答

見積・価格相談

数量、納期、条件、値引き前提の相談

案件相談・ディール登録

顧客企業名を伴う新規相談、案件登録、競合相談

申込・更新・解約

申請書類、契約更新、変更申請

進捗確認・納期照会

既存案件や既存申請の状態確認

障害・クレーム・緊急対応

サービス障害、納品事故、重大な不満や苦情

この粒度にする理由は明確です。見積と申請では必要データが違い、案件相談と障害対応では責任者もSLAも違うからです。Hiwayの運用自動化ユースケースでも、新規・更新・解約で処理を分け、既存データの更新や新規作成を分岐する前提が示されています。出典: Hiway 運用自動化

分類名を増やすより、各分類で何を必須入力にするかを先に決めたほうが実務では効きます。

3. 振り分けルールは「条件 → キュー → 担当」で分けると崩れにくいです

問い合わせをそのまま個人へ飛ばす設計は、担当不在や繁閑差に弱くなります。主要製品の公式情報を見ると、考え方はかなり共通しています。

Salesforceは、条件に合うケースやリードをユーザーまたはキューへ割り当てるAssignment Rulesを提供しています。未一致時はデフォルトオーナーも設定できます。

出典: Salesforce Help: Set Up Assignment Rules

Microsoft Dynamics 365は、ルールを順番に評価し、キュー優先度、営業時間、オーバーフロー、フォールバックキューを設計できます。

出典: Microsoft Learn: Automatically route cases using basic routing rulesets

Zendeskは、稼働状態、キャパシティ、スキルなどを加味したオムニチャネルルーティングを説明しています。

出典: Zendesk: About omnichannel routing

ServiceNowは、ケース属性に基づくマッチングと、担当資源への割当を分けて設計します。

出典: ServiceNow: Configure case routing and assignment

この共通点を代理店問い合わせに置き換えると、設計は3段階に分かれます。

3-1. 条件

受付時に判断する属性です。

問い合わせ種別
代理店名
対象製品
顧客企業名または案件ID
地域
緊急度
添付有無
回答希望期限

3-2. キュー

個人ではなく、まず業務単位で受ける箱です。

代理店営業キュー
Sales Opsキュー
審査・運用キュー
サポートキュー
共通トリアージキュー

3-3. 担当

キュー内で、最終的に誰が持つかを決めます。

製品知識
代理店担当有無
営業時間
現在の処理量
緊急案件対応可否

ここを混ぜると、ルール変更のたびに設計全体が崩れます。一次分類と最終担当決定は、別ロジックとして持つほうが運用しやすいです。

営業企画やRevOpsの立場では、入口で取る属性と、キュー内で見る配賦条件を分けて管理できるかが重要です。前者は受付品質、後者は処理能力に効きます。

4. 先に自己解決させる問い合わせと、人へ回す問い合わせを分けます

問い合わせ件数が多いと、つい「どう振り分けるか」に意識が向きます。しかし実務では、「そもそも人に渡さなくてよい問い合わせ」を減らしたほうが効く場面があります。

SalesforceはCase Deflectionとして、ケース起票前に関連記事を提示する考え方を公式に案内しています。ServiceNowも自己解決やdeflectionの計測を扱っています。出典: Salesforce Help: Case Deflection 出典: ServiceNow Self-Service Analytics concepts

代理店問い合わせでは、たとえば次の切り分けが現実的です。

自己解決を優先しやすいもの

最新資料の送付
制度や手続きのFAQ
進捗照会
提出書類の案内

人への引継ぎを先に決めたいもの

値引きや例外価格
契約条件を含む相談
障害、苦情、納期トラブル
既存案件との重複や競合懸念
直販と代理店の調整が必要な相談

この整理は、詳しくは代理店の問い合わせ対応をAIで効率化する方法でも扱っています。AIを使うにしても、回答可否の線引きが曖昧なままだと、便利になる前に責任が曖昧になります。

5. 一次分類と人への引継ぎ表

「何を自動化するか」より先に、「どの条件で人へ渡すか」を表にすると、営業企画、代理店営業、CRM管理者の会話が揃いやすくなります。以下は提案例です。自社の製品、組織、承認規程に合わせて調整してください。

一次分類	入口で最低限ほしい情報	第1ルート	人へ引き継ぐ条件	CRM/業務基盤へ残すもの
資料請求・FAQ	代理店名、製品、質問本文	ナレッジまたは一次回答	回答候補が見つからない、最新資料確認が必要	活動履歴、回答ログ
見積・価格相談	製品、数量、納期、条件	代理店営業またはSales Opsキュー	値引き、例外条件、承認要否、契約条件あり	取引先、担当者、案件候補、次アクション
案件相談・ディール登録	顧客企業名、案件概要、地域、競合有無	パートナー営業キュー	既存案件との衝突、直販重複、チャネルコンフリクト懸念	案件、活動、担当者、次アクション
申込・更新・解約	申込区分、対象契約、必要書類	運用・審査キュー	添付不足、記載不備、例外承認あり	申請情報、契約更新、進捗
進捗確認・納期照会	案件IDまたは申込ID、確認事項	ステータス照会または運用キュー	同期できない、個別判断が必要	活動履歴、必要に応じ案件更新
障害・クレーム・緊急	重大度、影響範囲、顧客名、再現条件	サポートまたは責任者キュー	原則人手対応。自動クローズしない	ケース、エスカレーション履歴、SLA

この表で重要なのは、一次分類そのものより、入口項目と引継ぎ条件が対になっていることです。営業が欲しい情報、RevOpsが欲しい情報、CRMに残す情報が揃っていないと、振り分けだけ早くても後工程が詰まります。

6. 実装時の設計要件

ルールを作っても運用が安定しないときは、ほぼ例外処理が先に設計されていません。ここは初期設定より大事です。

6-1. 未分類時の逃がし先

未分類をゼロにするより、未分類時の扱いを決めるほうが現実的です。Salesforceはデフォルトオーナー、Dynamics 365はフォールバックキューやオーバーフローを公式に案内しています。出典: Salesforce Help: Set Up Assignment Rules 出典: Microsoft Learn: Automatically route cases using basic routing rulesets

提案例:

未分類は共通トリアージキューへ送る
24時間以内に再分類する責任者を置く
未分類理由を記録し、受付項目かルールの不足を見直す

6-2. 営業時間とキャパシティ

詳しい人にだけ寄せると、その人がボトルネックになります。Dynamics 365、Zendesk、ServiceNowはいずれも、キュー運用で営業時間や担当キャパシティを扱います。出典: Microsoft Learn: Create and manage queues for unified routing 出典: Zendesk: About omnichannel routing 出典: ServiceNow: Exploring Advanced Work Assignment

確認したい論点は次のとおりです。

営業時間外は翌営業日に回すのか、当番制にするのか
再オープン案件は同じ担当へ戻すのか
同一代理店を同じ担当に寄せるのか、空き優先にするのか
緊急案件の割込みを許可するのか

6-3. 権限と外部可視性

代理店が関わる以上、見える範囲の設計は避けられません。Hiwayは代理店・販売店・社内チームごとの閲覧範囲制御を紹介しています。Salesforceも、パートナー向けケースでの割当や可視性を前提とした設定を案内しています。出典: Hiway 代理店管理出典: Salesforce Help: Assign Cases to Partners

最低限、次は確認が必要です。

代理店ごとに見える案件範囲
コメントの公開範囲
添付ファイルの共有可否
社内メモと外部向け回答の分離

6-4. CRMへ何を戻すか

振り分けは、対応先が決まった時点では終わりません。Hiway CRMは、入力・更新・分析の自動化と、既存CRM/SFAとのAPIやETLによる双方向同期を説明しています。出典: Hiway CRM

ただし、どこまで戻すかは自社設計です。

活動履歴だけでよいのか
案件候補まで起こすのか
申請や契約更新まで反映するのか
誰が最終承認するのか

RevOps視点では、ここが曖昧だと、問い合わせ件数は取れても営業判断に使えるデータになりません。

6-5. 外部照合を含むルールの制約

Salesforceでは、レコード保存時フローの同期実行中に外部データ参照ができないなど、実装上の制約があります。出典: Salesforce Help: Record-Triggered Flow Considerations

つまり、既存案件との外部照合や添付解析を含む高度な振り分けは、1本の同期ルールに詰め込めるとは限りません。非同期処理、iPaaS、別基盤での構造化を組み合わせる設計が現実的になる場合があります。

7. 既存CRMで足りるケースと、AIネイティブCRMの検討が向くケース

ここは切り分けて考えたほうが導入判断を誤りません。

既存CRMやヘルプデスクで足りるケース

入口がすでにフォーム中心で、必須項目が揃っている
振り分け条件が明確で、例外が少ない
CRMへの反映対象が活動履歴中心で足りる
自由文メールや添付の解釈がボトルネックではない

この場合、まずはAssignment Rule、キュー、営業時間、エスカレーションの見直しが先です。

AIネイティブCRMやAgentic CRMの検討が向くケース

メール、チャット、添付書類など自由度の高い入口が多い
代理店ごとの文脈や過去履歴を踏まえて整理したい
問い合わせを案件、取引先、担当者、次アクションへ構造化して戻したい
社外とのやり取りと社内CRM更新が分断している

Hiwayの代理店管理では、問い合わせ、案件相談、資料請求、申請を一つの入口に集約し、AIが構造化し、必要に応じて本部担当者へエスカレーションする考え方が示されています。Hiway CRMでは、入力や更新の自動化と既存CRM連携が説明されています。出典: Hiway 代理店管理出典: Hiway CRM

AIネイティブCRMやAgentic CRMをここで短く言えば、入力先を増やさず、問い合わせ文脈を読み取って、営業や運用の次アクションに接続しやすくする考え方です。単純な受付自動化だけでなく、CRMへ戻る形まで含めて検討すると意味が出ます。関連する考え方はAIネイティブCRMとは？でも整理しています。

8. 導入時の注意点：価格表を切り替える前の確認

価格や契約条件を含む問い合わせは、振り分け設計の中でも事故の影響が大きい領域です。ここをFAQと同じ扱いにすると、運用は早くなっても統制が崩れます。

事実

Hiway公式では、AI回答と本部担当者へのエスカレーションが示されています。
NIST AI RMF 1.0では、人間の役割、責任、監督を定義する重要性が示されています。
OpenAIのエージェント構築ガイドでも、ガードレールの設計や、人・別ワークフローへのハンドオフを含めた設計が重要な論点として扱われています。

出典: Hiway 代理店管理出典: NIST AI RMF 1.0 出典: OpenAI: A practical guide to building agents

実装上の示唆

値引き、例外契約、競合対抗、障害補償は人手レビュー必須にする
自動回答ではなく、下書き生成や一次整理に留める選択肢も持つ
信頼度が低いときの転送先を事前に決める
既存案件との衝突がある場合は、営業責任者またはチャネル責任者へ上げる

相談前に整理しておくと有効なデータ

価格表の更新頻度
特価承認の有無
契約例外の承認者
障害、クレーム時の責任部署
代理店ティアごとの対応差

ここが固まっていない段階では、自動振り分けの精度より、責任分界の明文化を優先したほうが安全です。

9. まず追いたいKPI

振り分け改善は、対応時間だけでは評価しきれません。少なくとも次は見たいところです。

分類別件数
未分類率
エスカレーション率
再振り分け率
一次応答SLA達成率
自己解決率
CRM反映率

初期導入では、全部を同時に追うより、未分類率、再振り分け率、CRM反映率を優先すると改善点が見えやすくなります。指標の置き方は、問い合わせ対応のKPI設計｜代理店営業で見る指標で詳しく扱っています。営業企画やRevOpsの立場では、問い合わせ処理の効率化だけでなく、案件化率や支援優先度判断に使えるデータが戻っているかを必ず見てください。

FAQ

既存のCRMだけでも代理店問い合わせの振り分けはできますか？

できます。Salesforce、Microsoft Dynamics 365、Zendesk、ServiceNowはいずれも、条件ベースのルール、キュー、優先度、営業時間、エスカレーションを公式に案内しています。入口項目が揃っていて、自由文や添付解析の負担が小さいなら、まず現行設定の見直しが有効です。

AIを使うと、すべて自動で振り分けられますか？

そうは限りません。価格、契約、障害、チャネルコンフリクトのように、人の判断や承認が必要な領域は残ります。AI活用は、自由文の整理、一次分類、CRM入力補助、人への引継ぎ準備で効果を出しやすいです。

一次分類はいくつまで増やしてよいですか？

初期は6種類前後が扱いやすいです。増やしすぎると入力負荷が上がり、未分類や誤分類の原因になります。まずは見積、案件相談、申請、進捗、FAQ、障害のように、必要データと責任部署が明確に違う単位で区切るのが実務的です。受付件数が少ない場合は、4分類程度から始めても構いません。

代理店ごとに担当を固定したほうがよいですか？

固定が有利な場面もありますが、繁閑差や不在対応で滞留しやすくなります。同一代理店は原則固定、緊急案件や営業時間外はキュー優先、のように例外条件まで決めておくと運用しやすくなります。

Hiwayへの相談前に、何を整理しておくとよいですか？

提案例としては、現在の問い合わせチャネル、一次分類の現状、既存CRMやヘルプデスクの構成、CRMへ戻したい項目、価格や契約で人手レビューが必要な範囲、代理店ごとの権限ルールを整理しておくと、適用条件を照合しやすくなります。

デモ・導入相談

代理店からの問い合わせをうまく振り分けるには、AIを入れる前に、一次分類、人への引継ぎ条件、CRMへ戻す項目を揃える必要があります。そのうえで、自由文や添付を含む問い合わせの構造化、既存CRMとの連携、代理店ごとの権限付き共有まで見直したいなら、Hiwayが適合するかを相談先の候補に入れられます。

相談の場では、現行ルールで足りる範囲と、追加で設計が必要な範囲としてどの論点を照合したいかを整理しておくと、判断しやすくなります。

参考文献・一次情報

顧客接点の構造化からCRM更新までAIが支援

自社の営業・パートナー業務への活用を相談する

現在のCRM、代理店との情報共有、見積対応の流れをもとに、デモで支援できる範囲や導入条件を確認できます。

デモ・導入相談資料ダウンロード