B2B受注窓口の電話を自動化するとは、受注入力チームが毎日対応している電話（新規注文、「トラックはどこ？」という配送状況の確認、破損品のクレーム、定期的な再注文）に音声エージェントが応答し、その結果をAPI経由でERPや受注システムに書き込み、判断が必要な案件は詳細を記録したうえで担当者に引き継ぐことを意味します。
メーカーや卸売業者にとって、受注窓口は電話注文を手入力する大人数のチームであることが多く、電話が最も集中するのは朝の最初の数時間です。電話の内容は繰り返しが多く、データは構造化されています。一方で、単位の誤りや追加品目の聞き漏らしは、誤出荷やクレジット処理につながります。そのため受注窓口は、通話タイプごとに個別に設計すれば、音声エージェントに非常に適した業務です。
音声エージェントが対応できる受注窓口の電話とは？
B2B受注窓口の電話の大半は4つの通話タイプでカバーでき、それぞれ連携するシステムも、担当者に引き継ぐタイミングも異なります。
| 通話タイプ | エージェントが収集する情報 | 連携するシステム | 担当者に引き継ぐタイミング |
|---|
| 新規注文 | 取引先、製品、数量と単位、追加品目、納品日と時間帯 | ERPまたは受注システム（照会後に書き込み） | 価格の例外、与信保留、カタログにない品目 |
| トラックはどこ？ | 取引先、注文番号またはPO番号 | 受注または配送システム（読み取りのみ） | システムで理由がわからない配送遅延 |
| 破損品またはクレジット依頼 | 注文番号またはPO番号、品目、数量、発生した事象 | チケット管理またはクレーム管理システム（書き込み） | すべてのクレジット判断、および複雑なクレーム |
| 定期再注文（発信） | 話している相手、在庫数、確定した数量 | 受注システム（書き込み） | 再確認後も数値が不自然な場合 |
まずは、件数が最も多く、背後のデータが最も整っている通話タイプから始めましょう。多くの窓口では、システムを読み取るだけで済む配送状況の問い合わせがそれにあたります。
エージェントは入力ミスなくどのように注文を受けるのか？
まず取引先を特定し、各明細を単位まで声に出して確認し、何かを書き込む前に注文全体を読み上げます。Retell では、通話がつながる前にインバウンドwebhookが発火し、発信者の電話番号が含まれるため、システム側で取引先を特定し、その詳細を動的変数として通話に渡すことができます。通話中は、カスタム関数がAPIを呼び出して製品、価格、在庫を確認し、エージェントは各レスポンスのフィールドを保存して会話の残りで活用できます。
受注窓口のミスの多くは単位が原因です。「50のやつを10」は、10袋、10パレット、10立方メートルのいずれも意味し得ます。エージェントへの指示は、次のように書きましょう。
- 発信者が単位を言わなかった場合は、カタログで販売している単位を使って必ず確認する
- 各明細を数量・単位・製品の順に復唱する
- 追加品目は聞き漏らしやすいため、納品の話に移る前に他に注文するものがないか確認する
- システムが返す納品日と時間帯（午前または午後）のみを提示する
- 注文全体を読み上げ、明確な「はい」を得てから注文を書き込む
照会中はTalk While Waitingをオンにすると、発信者は無音ではなく「確認いたしますね」といった短い一言を聞くことができます。製品名、工場名、現場名はブーストキーワードとして追加すれば、文字起こしで正しく認識されやすくなります。
Retell には、既製のERPコネクタは用意されていません。注文は、カスタム関数、すでに運用しているMCPサーバー、または通話後のwebhookを通じてERPに届きます。リアルタイムの在庫や価格はナレッジベースに入れないでください。自動更新は24時間ごとで、スプレッドシートファイルは1,000行が上限のため、日中に変わる情報はAPI照会で取得すべきです。
「トラックはどこ？」という電話はどう処理すべきか？
エージェントはシステムで注文を照会し、システムが返した内容だけを読み上げます。配送状況の問い合わせの大半は既存の取引先からなので、発信者の電話番号で未完了の注文を検索し、複数ある場合はどの注文かを尋ねることができます。カスタム関数は、注文ステータス、出荷日、納品時間帯など、共有すると決めたフィールドを返します。
エージェントには、到着時刻を独自に推測しないよう指示してください。システムにステータスが表示されない場合や、理由なく納品時間帯を過ぎている場合は、チケットを作成するか通話を転送すべきです。すでに追跡できる注文について、なぜ人々が今も電話をかけてくるのかは、WISMO：「注文はどこ？」が今も電話の問題である理由で解説しています。
破損品のクレームやクレジット依頼はどう扱うか？
エージェントにはクレームを受け付けさせ、判断はさせないようにします。完全なクレーム記録には次の内容が含まれます。
- 注文番号またはPO番号、および納品日
- 影響を受けた各品目と数量
- 発生した事象、および納品時に受け取りを拒否したのか後から発見したのか
- 破損が納品書類に記載されているかどうか
- フォローアップに最適な連絡先
その後、エージェントはカスタム関数を使って、またはクレームをすでにZendeskで管理している場合はZendesk連携ツールを使ってチケットを作成します。電話番号をSMS送信用に登録していれば、発信者の同意を得たうえで、通話中に写真アップロードフォームへのリンクをSMSで送ることもできます。クレジットの判断はチームが行います。設定した金額を超えるクレームや紛争案件は、ウォームトランスファー（事前取次）で担当者に回し、エージェントは発信者がつながる前にその担当者へ非公開で状況を伝えることができます。詳しくはAI音声エージェントと人間のチーム間で通話転送が機能する仕組みをご覧ください。
朝の電話集中にどう対応するか？
キャパシティは1日の平均ではなく、ピーク時間帯に合わせて計画しましょう。従量課金のワークスペースには20件の同時通話が含まれ、Enterpriseプランでは通話量に合わせて同時通話数を設定します。同時通話バーストをオンにすると、上限を超えた通話も、上限の3倍または上限＋300のいずれか低い方まで接続され、その通話には1分あたり$0.10が追加でかかります。すべての枠が埋まっている場合、着信は空きが出るまで約40秒待機し、その後設定したフォールバック番号に転送されます。
発信の再注文電話も運用している場合は、着信用の同時通話数を確保して一括発信（バッチコール）が朝の受注回線を圧迫しないようにし、バッチは朝のピーク以外の時間帯に予定してください。本番公開前には、実際の通話経路での音声AI負荷テストで説明しているとおり、ピーク時の通話量で通話経路全体をテストしましょう。
営業時間外は何を変えるべきか？
営業時間外は、エージェントは転送を試みるのをやめ、代わりにチケットを作成すべきです。誰もいないキューへの転送は保留時間を増やすだけです。インバウンドwebhookで通話ごとに応答するエージェントを切り替えられるため、システム側で営業時間外の電話を、転送ステップがなくチケットを作成して営業時間内の折り返しを約束するバージョンに振り分けることができます。また、{{current_time}}変数でエージェントに現在時刻を渡し、そのルールをprompt内に記述することも可能です。
通話中に在庫確認や荷受けバースの予約はできるか？
はい、それらのシステムにAPIがあれば可能です。カスタム関数で工場や倉庫の在庫を確認し、別のカスタム関数で空いている荷受けバースを一覧表示して集荷枠を予約できます。APIの準備ができていない場合は、手動から始めましょう。エージェントが依頼を収集し、通話後にwebhookでチームの受信箱やシートに送信し、スタッフが確認します。後からリアルタイム照会に切り替えても、発信者が聞く内容は変わりません。
スペイン語と英語に対応しているか？
はい。スペイン語は、スペイン（es-ES）とラテンアメリカ（es-419）の両方のバリエーションで音声認識と音声合成に対応しており、多言語エージェントは通話中に英語とスペイン語を切り替える発信者にも対応できます。通話の言語にかかわらず、すべての注文は同じ形式でシステムに書き込まれます。本番公開前に、シミュレーション通話で地域ごとの製品用語をテストしてください。詳しくはスペイン語の音声エージェントをご覧ください。
店舗への定期再注文の電話はどう機能するか？
エージェントはスケジュールに沿って各店舗に電話をかけ、在庫数を聞き取り、前回の注文と比較して、確定した再注文を書き込みます。一括発信（バッチコール）では店舗ごとに1行のCSVを使用し、店舗名や前回の注文数量などの追加列は、通話内の動的変数になります。優れた再注文の電話は次のように進みます。
- 話している相手と、在庫数を答えられるかどうかを確認します。小売の取引先が業者からの電話にパスコードを求める場合は、冒頭に組み込みます。
- 在庫数を1品目ずつ尋ねます。
- 相手が「少々お待ちください、確認します」と言ったら待ちます。その間は黙っているようエージェントに指示し、無音の設定値を引き上げてください。デフォルトでは、エージェントは無言の相手に10秒後に声をかけ、10分間無音が続くと通話を終了します。
- 各在庫数を前回の注文と比較し、数値が大きく外れている場合は再確認を依頼します。
- カスタム関数で注文を書き込み、納品日を読み上げます。
店舗の電話メニューはPress Digitツールで対応できます。発信プログラムに適用される発信規制については、法人回線であっても法務顧問に確認してください。燃料・ボンベ版のこの電話については、プロパン配送の受注で解説しています。
導入と効果測定はどう進めるか？
1つの回線で1つの通話タイプから始め、テスト通話で検証してから拡大しましょう。実践的な手順は次のとおりです。
- 単位の誤り、未知の製品、2つの取引先を持つ発信者などを含め、実際の通話からテストケースを作成します。シミュレーションテストではカスタム関数をモックできるため、テスト中にERPへ何も書き込まれません。
- promptを変更するたびに全テストをバッチテストとして実行し、合格率を比較します。
- 通話後分析の抽出フィールドを定義します：通話タイプ、注文書き込みの有無、明細数、クレーム起票、転送理由。
- 通話成功率が低下した際のアラートをメールまたはwebhookで設定します。
- 最初の通話タイプが安定してから、次の通話タイプを追加します。
Retell のAI電話受注のページでは、チームがカタログや受注APIを連携し、単一の受注回線から始める方法を紹介しています。従量課金の料金は1分あたり$0.07〜$0.31で、$10分の無料クレジットが付いているため、営業に問い合わせる前に自社の受注窓口の電話をテストできます。
