チャットボットから有人対応への引き継ぎで顧客に同じ説明を繰り返させない方法

チャットボットが一次対応を担う企業が増えていますが、ボットで解決できない問い合わせを有人オペレーターへ引き継ぐ際に、顧客が同じ内容をもう一度説明しなければならない状況が頻発しています。これは顧客満足度を大きく下げるだけでなく、オペレーターの対応時間を長引かせ、サポートチーム全体の生産性を圧迫します。

この記事は、従業員50〜500名規模の企業で、カスタマーサポート部門のマネージャーやチームリーダー、あるいはサポート業務のツール選定を兼務している情シス担当者を想定しています。読み終えると、チャットボットの会話履歴・顧客情報・チケット記録を一本の流れでオペレーターに渡す実務ワークフローを設計できるようになります。大規模コンタクトセンター（数百席以上）向けの全社導入計画や、個別ツールの網羅的なレビューは扱いません。

なお、本記事で紹介するツールの組み合わせは代表的な一例です。同じ役割を果たす別の製品でも、同様のワークフローを構築できます。

読み終えた時点で、チャットボットからオペレーターへの引き継ぎ時に会話履歴と顧客情報が自動で連携される3ステップのワークフロー設計図と、各ツールの役割分担が手元に揃います。

Workflow at a glance: チャットボットから有人対応への引き継ぎで顧客に同じ説明を繰り返させない方法

• Step 1: チャットボットで一次対応し、エスカレーション条件に該当したら会話要約を生成する (PKSHA Chatbot) (チャットボット)
• Step 2: チケットに顧客情報と過去履歴を自動付与し、オペレーターへルーティングする (Zendesk) (カスタマーサポートツール)
• Step 3: 対応完了後にチケットを更新し、次回の引き継ぎ精度を高める (Zendesk) (カスタマーサポートツール)

なぜチャットボットから有人対応への引き継ぎで情報が途切れるのか

会話履歴・顧客情報・チケットが別々のシステムに散在している

引き継ぎが煩雑になる最大の原因は、情報の置き場所がバラバラであることです。チャットボットの対話ログはチャットボットの管理画面に、顧客の契約情報や過去の問い合わせ履歴はCRM（顧客管理システム）やCTI（電話とコンピュータを連携させるシステム）に、案件の進捗はチケット管理ツールに、それぞれ独立して保存されています。オペレーターは引き継ぎを受けた瞬間、3つ以上の画面を切り替えながら状況を把握しなければなりません。

オペレーターの初動が遅れ、顧客の不満が増幅する

ボットで解決できなかった時点で、顧客はすでにストレスを感じています。そこからオペレーターに繋がったのに、また一から状況を説明させられると、不満は一気に増幅します。実務的には、引き継ぎ直後の30秒で顧客の温度感が決まります。この30秒でオペレーターが会話の文脈を把握できていなければ、対応時間が平均で2〜3分延び、顧客満足度も大きく下がります。

引き継ぎ内容の属人化と情報欠落

ボットからの引き継ぎ方法がルール化されていない場合、オペレーターごとに確認する項目がバラバラになります。あるオペレーターは会話履歴を丁寧に読み返す一方、別のオペレーターは顧客に直接聞いてしまう、という差が生まれます。結果として、対応品質にムラが出て、チーム全体のサポート品質が安定しません。

重要な考え方：引き継ぎの瞬間にオペレーターの画面へ必要な情報を自動で集約する

引き継ぎの問題を解決するために重要なのは、オペレーターが自分で情報を探しに行く必要をなくすことです。ボットがエスカレーション（有人対応への切り替え）を判断した瞬間に、会話履歴の要約、顧客の基本情報、過去の問い合わせ履歴がオペレーターの画面に自動で表示される仕組みを作ります。

情報を集めるのではなく、情報が集まる設計にする

多くの企業が陥る失敗は、オペレーター向けのマニュアルを整備して情報確認の手順を標準化しようとすることです。しかし、忙しい現場ではマニュアル通りに動く余裕がありません。人の行動を変えるのではなく、システム側で情報を自動的に集約する設計にすることが、再現性のある解決策です。

エスカレーション判定の基準を明確にする

もう一つ重要なのは、ボットがどのタイミングで有人対応に切り替えるかの基準を明確にしておくことです。基準が曖昧だと、本来ボットで解決できる問い合わせまでオペレーターに流れてしまい、オペレーターの負荷が増えます。具体的には、ボットが2回連続で適切な回答を返せなかった場合、顧客が明示的にオペレーターとの会話を希望した場合、特定のキーワード（解約、クレームなど）が含まれる場合、といった条件をあらかじめ設定しておきます。

チャットボットの会話をオペレーターへシームレスに引き継ぐ3ステップ

ステップ 1：チャットボットで一次対応し、エスカレーション条件に該当したら会話要約を生成する（PKSHA Chatbot）

顧客からの問い合わせをPKSHA Chatbotが受け付けます。FAQ対応や定型的な質問にはボットが自動で回答し、解決できた場合はそのまま完了します。

エスカレーション条件に該当した場合、PKSHA Chatbotは以下の情報を自動で整理します。

• 顧客が入力した質問内容の全文
• ボットが返した回答とその結果（解決したか、しなかったか）
• 顧客の感情的な表現の有無（怒りや不満を示すキーワードの検出）
• 問い合わせカテゴリの自動分類結果

これらの情報をまとめた会話要約データを、次のステップで使うチケットとしてZendeskへ自動送信します。PKSHA ChatbotはZendeskとの連携機能を備えており、API連携の設定を行うことで、エスカレーション発生時に会話ログ付きのチケットが自動生成されます。

担当者の動きとしては、この段階では人の介入は不要です。ボットの運用担当者が月に1回程度、エスカレーション条件の閾値を見直し、不要なエスカレーションが増えていないかを確認します。

ステップ 2：チケットに顧客情報と過去履歴を自動付与し、オペレーターへルーティングする（Zendesk）

PKSHA Chatbotから送られてきた会話要約付きチケットがZendeskに作成されると、Zendeskのトリガー機能が動きます。

まず、顧客のメールアドレスや電話番号をキーにして、Zendesk上の顧客プロフィールと自動的に紐づけます。これにより、過去の問い合わせ履歴、未解決チケットの有無、顧客の契約プランといった情報がチケットに自動で付与されます。

次に、Zendeskのルーティング機能（振り分け機能）を使って、問い合わせカテゴリや顧客の重要度に応じて、適切なスキルを持つオペレーターへチケットを自動で割り当てます。たとえば、解約に関する問い合わせは専任のリテンション担当へ、技術的な質問はテクニカルサポートチームへ、といった振り分けです。

オペレーターがチケットを開いた時点で、画面には以下の情報が一画面にまとまっています。

• PKSHA Chatbotでの会話要約と全文ログ
• 顧客の基本情報（名前、契約プラン、利用開始日）
• 過去の問い合わせ履歴と対応結果
• 今回の問い合わせカテゴリと緊急度

これにより、オペレーターは顧客に同じ説明を求めることなく、すぐに本題に入れます。

ステップ 3：対応完了後にチケットを更新し、次回の引き継ぎ精度を高める（Zendesk）

オペレーターが対応を完了したら、Zendesk上でチケットのステータスを更新し、対応内容の要約を記録します。この記録が次回以降の引き継ぎ精度を高める資産になります。

具体的には、以下の項目を入力します。

• 実際の問題の原因（ボットが分類したカテゴリと一致していたか）
• 解決方法の概要
• 顧客の温度感（満足して終了したか、不満が残っているか）
• ボットの改善に活かせるフィードバック（ボットが回答できなかった質問のパターンなど）

Zendeskの入力フォームをカスタマイズして、これらの項目を選択式にしておくと、オペレーターの入力負荷を最小限に抑えられます。自由記述だと記入が省略されがちですが、選択式なら10秒程度で完了します。

このデータは月次でサポートマネージャーが集計し、PKSHA Chatbotのシナリオ改善に反映します。ボットで解決できなかった問い合わせのパターンを分析し、新しいFAQやシナリオを追加することで、エスカレーション率そのものを下げていきます。

この組み合わせが機能する理由

PKSHA Chatbot：日本語特化のAIチャットボットで高精度な一次対応と会話要約を実現する

PKSHA Chatbotは日本語の自然言語処理に強みを持つチャットボットです。日本語特有の曖昧な表現や敬語のバリエーションに対応できるため、顧客の意図を正確に把握した上でエスカレーション判定を行えます。海外製のチャットボットでは日本語の文脈理解が不十分で、不要なエスカレーションが増えるリスクがあります。

Zendeskとの連携はAPI経由で実現でき、会話ログをそのままチケットに添付する仕組みが用意されています。ただし、初期設定にはAPIキーの発行や連携フローの構築が必要で、情シス担当者の協力が不可欠です。設定自体は1〜2日で完了しますが、エスカレーション条件のチューニングには2〜4週間の運用データが必要です。

注意点として、PKSHA Chatbotの会話要約機能はプランによって利用可否が異なります。導入前に、会話ログのエクスポートやAPI連携が含まれるプランかどうかを確認してください。

Zendesk：チケット管理と顧客情報の一元化でオペレーターの画面切り替えをなくす

Zendeskを選ぶ最大の理由は、チケット管理・顧客情報管理・ルーティングが一つのプラットフォームに統合されている点です。オペレーターは一つの画面で会話履歴、顧客情報、過去のチケットをすべて確認できるため、複数システムを行き来する必要がありません。

また、Zendeskはトリガーやマクロ（定型操作の自動化）が豊富で、チケット作成時の自動分類や自動割り当てを細かく設定できます。たとえば、チケットの件名に解約という文字が含まれていたら優先度を高に設定し、リテンションチームに自動割り当てする、といったルールを管理画面から設定できます。プログラミングの知識は不要です。

トレードオフとして、Zendeskは機能が豊富な分、初期設定の項目が多く、使いこなすまでに時間がかかります。FitGapでは、まずチケットの自動生成とルーティングの2機能に絞って設定し、運用が安定してからカスタマイズを広げていくアプローチをおすすめします。

もう一点、Zendeskは1エージェント（オペレーター1人）あたりの月額課金です。オペレーターの人数が多い場合はコストが膨らむため、事前に利用人数と予算を照らし合わせてください。

Recommended tool list

結論：会話履歴と顧客情報の自動連携で引き継ぎの断絶をなくす

チャットボットから有人対応への引き継ぎで顧客に同じ説明を繰り返させてしまう問題は、ツール間の情報連携を自動化することで解決できます。PKSHA Chatbotで一次対応と会話要約を行い、Zendeskでチケット・顧客情報・ルーティングを一元管理する3ステップのワークフローにより、オペレーターは引き継ぎの瞬間から顧客の状況を把握した状態で対応を開始できます。

最初の一歩として、現在のエスカレーション件数と、オペレーターが引き継ぎ後に顧客へ状況確認している回数を1週間だけ記録してみてください。この数字が、ワークフロー導入後の改善効果を測る基準になります。

Mentioned apps: PKSHA Chatbot, Zendesk

Related categories: カスタマーサポートツール, チャットボット

Related stack guides: ツール導入後の社内問い合わせ対応が特定の社員に集中する属人化を解消し安定したサポート体制を構築する方法, カスタマーサポートの対応ノウハウを組織に蓄積し対応品質のばらつきと工数増大を防ぐ方法, 委託先からの問い合わせ対応と指導履歴を組織のナレッジとして蓄積し監督責任リスクを防ぐ方法, 個人データの利用停止請求を受けてから提供先への連絡完了までを1週間以内に短縮する方法, 同意撤回・削除依頼の対応漏れをなくし法定期限内に完了を証明できる体制をつくる方法