Zendeskオムニチャネル・ハンドオフの仕組み：2026年完全ガイド

顧客がAIエージェントとの会話を開始したものの、人間の担当者と話す必要が生じた場合、次に何が起こるでしょうか？その移行、つまりボットからエージェントに制御が移る瞬間を、サポートチームはハンドオフと呼んでいます。Zendesk環境では、1つのチャネルだけを扱っているわけではないため、これはすぐに複雑になります。メール、メッセージング、音声、チャットをすべて管理し、同じシステムに流れ込ませているのです。

このガイドでは、Zendeskオムニチャネル・ハンドオフが実際にどのように機能するかを解説します。ルーティングの仕組み、サポートチームがつまずきやすい一般的な落とし穴、顧客をイライラさせたり、エージェントを混乱させたりしないハンドオフの設定方法について説明します。

会話ハンドオフ戦略のより広範な概要については、Zendeskの会話ハンドオフからエージェントへのハンドオフに関するガイドを参照してください。Zendeskオムニチャネルサポートの概要も、より広範なコンテキストを理解するのに役立つかもしれません。

Zendeskオムニチャネル・ハンドオフとは？

オムニチャネル・ハンドオフとは、異なるサポートチャネル間で、顧客との会話をある担当者から別の担当者に転送するプロセスです。Zendeskでは、通常、AIエージェントから人間のエージェントへ、またはその逆への移行を意味します。

理解すべき2つの異なるアクションがあります。

• ハンドオフ (Handoff)：AIエージェントが会話の最初のレスポンダーから削除され、人間のエージェントが引き継ぎます。これが起こると、AIはその会話に応答できなくなります。
• ハンドバック (Handback)：チケットのステータスが「解決済 (Solved)」から「クローズ済 (Closed)」に変更されると、人間のエージェントが最初のレスポンダーから削除されます。これにより、AIエージェントがその顧客からの新しい会話を処理できるようになります。

対象となるチャネルには、メール（WebフォームやAPI送信を含む）、ネイティブ・メッセージング、ライブチャット、WhatsApp、Facebook Messenger、音声通話、SMS、およびX（Twitter）、Instagram、Telegramなどのソーシャルメディアのダイレクトメッセージが含まれます。ルーティングとハンドオフの動作に関しては、各チャネルに独自の癖があります。

シームレスなハンドオフが重要なのはなぜでしょうか？それは、顧客はチャネルを意識していないからです。チャットを開始し、メールを送信し、イライラすると電話をかけます。エージェントがこれらのタッチポイント全体の会話履歴全体を確認できない場合、顧客に何度も同じことを繰り返させることになります。これは、満足度スコアの低下への近道です。

Zendeskにおけるオムニチャネル・ルーティングの仕組み

その中核において、オムニチャネル・ルーティングはサポート・チケットの交通整理係です。すべてのチャネルからの着信会話を調べ、空き状況、処理能力、スキルに基づいて、どのアージェントが各会話を処理すべきかを決定します。

ルーティング・エンジン (Routing engine)

チケットがルーティングの対象になると、Zendeskは次のようないくつかの要素を順番に評価します。

1. キューの割り当て (Queue assignment)：チケットは、標準のオムニチャネル・ルーティング・キューまたはカスタム・キュー（ProfessionalおよびEnterpriseプランで利用可能）のいずれかに配置されます。カスタム・キューを使用すると、特定の条件を満たすチケットを指定されたグループにルーティングできます。

2. エージェントのステータス (Agent status)：エージェントは、すべてのチャネルで単一の統一されたステータス（オンライン、離席中、またはオフライン）を設定します。メッセージングと通話の場合、エージェントは作業を受信するために「オンライン」である必要があります。メールの場合、「オンライン」または「離席中」ステータスが条件を満たします。

3. 処理能力ルール (Capacity rules)：これらは、各エージェントが一度に処理できる作業量を制御します。メール、メッセージング、音声チャネルに対して異なる処理能力制限を定義できます。

4. 割り当て方法 (Assignment method)：Zendeskは、最も空いている処理能力またはラウンドロビン（作業の受信に最も時間がかかった人）に基づいて割り当てることができます。

5. スキル・マッチング (Skills matching)：Professionalプラン以上では、チケットは特定のスキル（言語能力や製品知識など）を持つエージェントにのみルーティングできます。

標準キュー vs. カスタムキュー

標準キューは、チケットに割り当てられたグループに基づいてエージェントに作業をルーティングします。ProfessionalおよびEnterpriseプランで利用可能なカスタムキューは、より多くの制御を提供します。チケットをプライマリ・グループに最初にルーティングし、誰も利用できない場合はセカンダリ・グループにフォールバックするキューを作成できます。特定のチケット・タイプを他のチケット・タイプよりも優先することもできます。

スキルベースのルーティングの制限

多くのチームを不意打ちにする点がここにあります。スキルベースのルーティングはメール・チケットでは機能しますが、メッセージングには制限があります。Zendeskのドキュメントによると、スキルベースのルーティングは、特にメッセージング・チケットでは利用できません。これは、メッセージングを多用する運用を行っている場合は、代替のルーティング戦略が必要になる可能性があることを意味します。

AIからエージェントへのハンドオフの設定

Zendeskは、EssentialとAdvancedの2つのレベルのAIエージェントを提供しています。ハンドオフの設定は、使用しているエージェントによって異なります。

ネイティブAIエージェントのハンドオフ・オプション

Essential AIエージェント（Suite Team以上で利用可能）は、基本的な会話を処理し、組み込みのダイアログ・フローを使用して人間のエージェントにエスカレーションできます。

Advanced AIエージェント（アドオンとして利用可能）は、より高度な推論、カスタム・アクション、およびより深い統合機能を提供します。顧客の意図、感情、または特定の要求に基づいてハンドオフをトリガーするエスカレーション・ブロックを設定できるダイアログ・ビルダーを使用します。

解決済 vs. クローズ済のタイミングの落とし穴

これは、サポートチームが遭遇する最も一般的なハンドオフの問題です。デフォルトでは、Zendeskはチケットを解決済みにマークしてから自動的にクローズするまで4日間待ちます。その期間中に、顧客がメッセージング・チャネルに戻ってきた場合、新しい会話を開始できません。メッセージは既存のチケットに送信され、人間のエージェントが最初のレスポンダーのままになります。

これにより、顧客は新たに開始していると考えているのに、実際には古いチケットを再オープンしているという、不満のたまるエクスペリエンスが生まれます。AIエージェントは最初のレスポンダーではないため、関与しません。

これを修正するには、次の2つの方法があります。

オプション1：デフォルトの自動化を調整する 「ステータスが解決済みに設定されてから4日後にチケットをクローズする」自動化を編集します。これを最短で1時間に短縮したり、最長で28日まで延長したりできます。

オプション2：即時クローズ・トリガーを作成する チケットが解決されたときにタグ（「クローズ」など）を追加し、そのタグが付いたチケットをすぐにクローズするトリガーを作成します。トリガーの条件は次のようになります。

• タグに「クローズ」が含まれている
• アクション：ステータスをクローズ済みに設定

CSATアンケートを使用している場合は、アンケートの配信との競合を避けるために、解決とクローズの間に少なくとも短いバッファを設けてください。

チャネル間でコンテキストを維持する

コンテキストの喪失は、優れたハンドオフの静かなる殺人者です。AIエージェントは、重要な詳細、顧客履歴、および意図シグナルを収集した可能性があります。その情報が人間のエージェントに届かない場合、ゼロからやり直すことになります。

継続性を維持する方法は次のとおりです。

自動トランスクリプト添付: Zendeskは、会話トランスクリプトをチケットに自動的に添付します。エージェントがそれらを見つける場所を知っていることを確認してください。

カスタム・チケット・フィールド: これらを使用して、AI会話中に構造化されたデータ（問題のカテゴリ、顧客の感情、または試行された解決策など）をキャプチャします。これらのフィールドは、人間のエージェントに引き継がれます。

メタデータの受け渡し: 技術的な統合の場合、Sunshine Conversations APIを使用して、システム間でメタデータを渡します。これには、顧客ID、会話履歴、およびカスタム属性を含めることができます。

内部メモ: ハンドオフする前に、AIエージェントに会話を内部メモに要約するようにトレーニングします。簡潔な要約は、50件のメッセージをスクロールするよりも優れています。

エージェント・トレーニング: エージェントは、コンテキストがどこにあるかを知る必要があります。Agent Workspaceからトランスクリプト、カスタム・フィールド、および会話履歴にアクセスする方法を示すクイック・リファレンス・ガイドを作成します。

オムニチャネル・ハンドオフの一般的な課題

適切な構成であっても、うまくいかないことがあります。ここでは、最も頻繁に見られる問題を紹介します。

顧客が新しい会話を開始できない: 前述の解決済 vs. クローズ済ステータスのギャップです。顧客は新たに開始することを期待して戻ってきますが、代わりに古いチケットに引き込まれます。

間違ったチームがエスカレーションされたチケットを受信する: ルーティング・ルールが十分に具体的でないか、カスタム・キューが組織構造と一致するように構成されていません。Tier 2向けのチケットが、解決できないTier 1エージェントに割り当てられます。

エージェントが会話のコンテキストを見逃す: エージェントは、応答する前にトランスクリプトまたはカスタム・フィールドを確認しません。AIがすでに収集した情報を顧客に繰り返すように求めます。

スキルのタイムアウトとチケットの停滞: タイムアウトのしきい値なしでスキルベースのルーティングが有効になっている場合、一致するスキルを持つエージェントがいない場合、チケットはキューで無期限に待機する可能性があります。メールおよびメッセージング・チケットは、適切なスキルを持つ誰かがオンラインになるまで待機します。

チャネル固有の制限: スキルベースのルーティングは、メッセージング・チケットでは機能しません。音声チケットは、エージェントに割り当てられると再割り当てできません。ライト・エージェントは、チケットを割り当てたり、ステータスを設定したりできません。

eesel AIによるオムニチャネル・ハンドオフの簡素化

Zendeskのネイティブ・ルーティングは強力ですが、大幅な構成と継続的なメンテナンスが必要です。よりシンプルなアプローチをお探しの場合は、eesel AIを使用すると、複雑さを軽減してハンドオフを処理できます。

Zendeskのビルダーでダイアログ・ツリーを構築する代わりに、プレーンな英語でエスカレーション・ルールを定義します。たとえば、「顧客が請求に関する紛争について質問した場合は、すぐに財務チームにエスカレーションする」などです。コーディングも、複雑なトリガー構成も必要ありません。

Zendesk統合は、コンテキストを自動的に保持します。eeselがZendeskエージェントにハンドオフすると、完全な会話履歴、顧客データ、およびAI生成の要約が付属します。エージェントは、複数のタブを検索することなく、必要なものをすべて確認できます。

本番稼働する前に、過去の数千件のチケットでシミュレーションを実行して、ハンドオフがどのように機能するかを正確に確認できます。実際のお客様との会話に触れることなく、さまざまなエスカレーション・ルールをテストし、解決率を測定し、アプローチを洗練します。

eeselは、Zendeskだけでなく、Confluenceドキュメント、Googleドライブ、Notionページなど、100以上のナレッジ・ソースとも統合されています。これは、eeselが複雑なハンドオフ・シナリオを処理するためのより広範なコンテキストを持っていることを意味します。

よりスマートなオムニチャネル・ハンドオフを始める

Zendeskオムニチャネル・ハンドオフを設定または最適化する場合は、次の手順から開始します。

1. 現在のルーティング構成を監査する: どのキューが存在するか、チケットがキュー間をどのように流れるか、および現在ハンドオフが発生する場所を文書化します。

2. 解決済 → クローズ済の自動化タイミングを確認する: デフォルトの4日間の期間を確認します。顧客の混乱を引き起こしている場合は、調整するか、即時クローズ・トリガーを作成します。

3. 実際シナリオでエスカレーション・フローをテストする: AIエージェントを介してテスト会話を実行し、完全なコンテキストを維持したまま、適切な人間のエージェントに到達することを確認します。

4. 複雑さの許容度を検討する: Zendeskのルーティング構成が圧倒的に感じられる場合は、eesel AIのようなツールを使用すると、効果的なハンドオフへのより簡単な道が開けます。

eesel AIがどのようにハンドオフを処理するかを見てみませんか？無料でお試しくださいまたはデモを予約するして、既存のZendesk設定で実際に動作する様子をご覧ください。