ChatBot.comからLiveChatへ転送できないときの確認手順

ChatBot.comのTransfer chatで有人転送できないときのWidget、受付状態、割当方式、Success/FailureとHelpDesk.com代替受付を確認します。

確認日 2026年10月21日AIものさし編集部

LiveChat

ChatBot.comからLiveChatの担当者へ会話を渡せないときは、AIの回答文を直す前に、転送ブロック、担当者の受付状態、転送失敗後の経路を確認します。「担当者へおつなぎします」と表示しただけでは、引き継ぎが成立したことにはなりません。

この記事は、ChatBot.comのブロック式フローでLiveChat連携のTransfer chatを使う構成を扱います。TextのAI Agent全般の操作手順ではありません。公式資料を基にした設定確認と架空ケースの設計で、実アカウントでの接続、有人転送、チケット作成は実施していません。

最初に、どの画面で試しているかを確認する

Transfer chatは有効なLiveChat連携が前提です。公式資料は、内部Testing Toolでは有人転送されず、接続したLiveChat Chat Widgetで試すよう説明しています。担当者が少なくとも一人利用可能で、チャットを受け付ける必要もあります。

転送先グループと担当者の受付・同時対応上限を確認し、LiveChatの割当をAuto assignmentにします。Manual selectionを同じ動作だと考えないでください。Successは有人転送が成立した経路で、その後に置いたBot responseは利用者へ表示されません。Failure側には、無人・受付停止・上限到達などに備えた案内を置きます。ChatBot.com公式：Transfer chat（新しいタブで開く）

次の表は、調査の順序を整理するためのメモです。製品がこの名前の診断結果を返すという意味ではありません。

表は横にスクロールできます

見えていること	最初に確認するもの	まだ言えないこと
内部テストで転送されない	試験画面がTesting ToolかWidgetか	本番連携が壊れているとは限らない
転送前の案内だけ出る	Transfer chatまで経路が到達したか	案内表示だけで有人受付済みとはしない
Failureへ進む	対象グループ、受付状態、対応上限、割当方式	AIの知識不足が原因とは限らない
Success後のBot文が出ない	成功前に必要な案内を置いたか	転送失敗とは限らない

連携時はLiveChat側のWidgetを使います。ChatBot.com側のWidget設定だけを変更しても、LiveChatのWidgetへ同じ変更が反映されるとは考えません。

公式の連携設定にはChats priorityのBot／Agentと、Remember recent agentがあります。後者が有効で、以前対応した担当者が受付可能なら、再訪した利用者はBotを飛ばす場合があります。「昨日と同じ質問なのにBotが始まらない」ときは、初回利用と再訪を分けて確認します。ChatBot.com公式：LiveChat installation guidelines（新しいタブで開く）

設定を調べる際は、現在値を記録してから、問題に関係する項目だけを切り分けます。担当者へ先に渡す運用を意図しているのに、Botを必ず経由させるため設定を変えると、別の要件を壊します。「Botが先か」「再訪時は以前の担当者を優先するか」をサポート責任者と決めておきます。

転送前と転送失敗後で、文案を分ける

次は架空の文案です。応答時間や返金判断など、窓口で保証していない約束は加えていません。

転送前：

この内容は担当者による確認が必要です。これから担当者への接続を試みます。

Failure後：

現在、担当者へ接続できませんでした。お問い合わせ内容を残すか、案内済みの別窓口をご利用ください。

二つ目を「担当者が確認しました」に変えると、失敗を成功として伝えてしまいます。また、問い合わせを残す機能をまだ用意していない構成で、「内容を残せます」と表示してはいけません。実際に使える経路だけを文案へ残してください。

案内と処理結果を別に記録すると、会話ログの読み違いも減ります。「接続を試みる文を表示」「Transfer chatの結果」「代替受付の結果」をそれぞれ追い、最初の文だけを見て完了扱いしません。

無人時にHelpDesk.comへ残す構成

Failureから問い合わせを残す場合は、HelpDesk.com連携とCreate ticketを別に設定します。公式資料では、事前に収集した属性を名前・メール等へ対応させ、必要な項目を埋める手順が説明されています。Descriptionは事前入力されていないため、説明文または収集した属性を設定します。

会話全文を含める選択肢は、有効なLiveChat連携がある場合に使え、初期状態では無効です。有効にするとDescription欄が無効になるので、「説明欄と全文が常に両方送られる」と想定しません。ChatBot.com公式：HelpDesk.com integration（新しいタブで開く）

例えば「注文の届け先を変更したい」という架空の問い合わせなら、受付内容は次のように整えられます。

表は横にスクロールできます

項目	架空の内容・設定方針	確認すること
件名	届け先変更の相談	変更処理が完了した件名にしない
名前・メール	利用者から収集する	収集属性と送信先項目が一致するか
問い合わせ本文	発送前か不明。変更可否を確認したい	AIが「変更可能」と補っていないか
会話全文	必要性と共有範囲を決めて選択	有効時のDescription欄の扱いも確認
受付後の案内	受付の成立を確認できた範囲で表示	作成失敗時に完了文を出さないか

メールの値が空なら、例の名前や別の利用者のメールで埋めません。チケットを作ることと、届け先を変更することも別です。問い合わせの受付を理由に、注文情報の変更までBotへ許す設計に広げないようにします。

公開前に分けて試す5ケース

次の表は自社で実施する試験の設計例です。ここに記載した期待値は製品で観測した結果ではありません。担当者と試験時間を合わせ、顧客がいない検証用の経路で実施します。

表は横にスクロールできます

ケース	用意する条件	合格条件
A：通常転送	正しいグループに受付可能な担当者	Widgetで実際に担当者へ渡り、元の質問を確認できる
B：担当者不在	検証用の転送先グループに、受付可能な担当者が一人もいない	Failure側の案内が出て、有人受付済みと表示しない
C：成功後の案内	必要な案内を転送前に配置	成功後のBot文に必須案内を依存させていない
D：再訪利用者	Remember recent agentの現在値を記録	意図した入口になり、Botを飛ばす理由を説明できる
E：代替受付	HelpDesk.comの必要属性を用意	作成先で内容と連絡先を読み戻せる。欠損時は完了にしない

各ケースで、入力、設定値、時刻、通った経路、担当者側の記録を残します。Aの成功だけで、BやEも合格にはしません。反対に、内部Testing Toolで転送されなかったことだけを、Aの不合格として数えないでください。

転送後に会話が見つからない場合は、会話の識別情報と確認した画面を記録し、受付先で確認します。問い合わせを重ねて作る前に、既に受付済みか結果が不明なのかを切り分け、重複受付を避けます。

導入判断は、無人時の行き先まで決めてから

この構成が合うのは、ChatBot.comで一次対応し、例外だけLiveChatの担当者へ渡したい場合です。担当者を置けない時間帯があるなら、Failure側から実際に使える受付窓口へ進めることも導入条件にします。

契約前にはChatBot.com、LiveChat、HelpDesk.comそれぞれで必要な機能と利用条件を確認してください。この記事では料金総額、無料利用の成立、現契約での機能利用可否を検証していません。AIの回答が自然かだけで選ばず、転送先が実際に受け取れて、利用者が次の行動を理解できる構成かを確認します。

参考資料

資料確認日：2026年10月21日。文案・問い合わせ・試験表は編集例です。実製品の接続・転送・受付・通知・料金は未検証です。