顧客がZendeskチャットウィジェットで会話を開始したが、離席する必要がある場合、メールへの移行はシームレスである必要があります。ぎこちないハンドオフは、顧客をイライラさせ、断片化された会話をつなぎ合わせる必要のあるエージェントに余分な作業を生み出します。うまく行われれば、チャットからメールへのZendeskハンドオフは、コンテキストを保持し、会話スレッドを維持し、解決時間を短縮します。
このガイドでは、基本的な設定から高度なタイミング制御まで、Zendeskの継続的な会話機能を設定する方法を正確に説明します。チャットからメールへの移行を初めて設定する場合でも、顧客が新しい会話を開始できない理由のトラブルシューティングを行う場合でも、Zendeskの階層で機能するステップバイステップの手順が見つかります。
チャットからメールへのZendeskハンドオフとは何ですか？
設定に入る前に、実際に何を設定しているのかを明確にしましょう。Zendeskは、チャットからメールへのワークフローに「継続的な会話（continuous conversations）」という用語を使用しています。これは、ライブエージェントに会話を引き渡すのとは異なります（ただし、2つは連携して機能します）。
継続的な会話を使用すると、メッセージングチャットを放棄した顧客は、エージェントが応答したときにメール通知を受信できます。顧客は、メールに返信するか、ウェブサイトのウィジェットに戻ることで、会話を継続できます。完全な会話履歴は、どのチャネルを使用してもそのまま残ります。
これが重要なのは、顧客の行動は予測できないためです。誰かが昼休み中にチャットを開始し、会議に引き込まれ、後でメールで継続することを好むかもしれません。継続的な会話が有効になっていない場合、その会話は顧客がウェブサイトに戻るまで未読のままになるか、最悪の場合、完全に失われます。
この機能は、AIエージェントから人間のエージェントに同じチャットセッション内で制御を転送するライブエージェントハンドオフとは異なります。両方を使用できます。AIエージェントが最初のトリアージを処理し、必要に応じて人間のエージェントにエスカレートし、顧客が離れた場合は、継続的な会話が引き継ぎ、メールでスレッドを維持します。
チャットからメールへのZendeskハンドオフの前提条件
継続的な会話を有効にする前に、Zendeskアカウントがいくつかの要件を満たしている必要があります。
- Zendesk SuiteまたはSupport + Chat（Teamプラン以上）。この機能は、ChatのないスタンドアロンのSupportプランでは利用できません。
- エージェントワークスペース（Agent Workspace）が有効化されていること。これは、チャットとチケットを統合する最新のZendeskインターフェースです。従来のChatダッシュボードをまだ使用している場合は、最初に移行する必要があります。
- Chatアクセス権を持つエージェントが少なくとも1人いること。会話が入ってきたときに応答できる人が必要です。
- サポートメールアドレスが設定されていること。これは、継続的な会話の通知を顧客に送信するアドレスです。
- Webウィジェットの実装。継続的な会話は、Webウィジェットでのみ機能します。モバイルSDKの実装では利用できません。
これらのいずれかが欠落している場合、継続的な会話のオプションは管理センター（Admin Center）に表示されないか、機能が正しく機能しません。
ステップバイステップ：継続的な会話の設定
ステップ1：管理センターで継続的な会話を有効にする
まず、管理センター > オブジェクトとルール > チケット > 設定に移動します。下にスクロールして、継続的な会話セクションを見つけて展開します。
**「メッセージングの会話をメールに切り替える」**というラベルの付いたチェックボックスを選択します。これにより、コア機能が有効になります。
この設定を保存すると、Zendeskは自動的に**「継続的な会話のメールをリクエスト」**というトリガーを作成します。このトリガーは、会話が5秒間アイドル状態になった後に実行され、顧客のメールアドレスがまだ収集されていない場合は、メールアドレスをリクエストします。
ステップ2：メールリクエストトリガーを設定する
自動作成されたトリガーはほとんどのユースケースを処理しますが、ワークフローに合わせて確認およびカスタマイズする必要があります。
管理センター > オブジェクトとルール > ビジネスルール > メッセージングトリガーに移動し、**「継続的な会話のメールをリクエスト」**トリガーを開きます。
次の主要な設定を確認してください。
- 条件：デフォルトでは、会話が5秒間アイドル状態になり、顧客のメールアドレスが不明な場合に起動します。タイミングを調整したり、営業時間に基づいて条件を追加したりすることもできます。
- アクション：トリガーは、顧客のメールアドレスをリクエストするメッセージを送信します。ブランドの声に合わせてこのメッセージをカスタマイズします。
会話の開始時に（チャット前のフォームなどを介して）すでにメールアドレスを収集している場合は、このトリガーを無効にして、メールを2回要求することを回避できます。
ステップ3：メール通知テンプレートをカスタマイズする
継続的な会話のメールは、標準のZendeskメール通知テンプレートを使用します。これには以下が含まれます。
- 未読のエージェントメッセージの数
- 会話のスニペット
- メールで継続するか、ウェブサイトに戻るかの手順
テンプレートを確認またはカスタマイズするには、管理センター > チャネル > メール > メールテンプレートに移動します。継続的な会話機能は、サポートアカウントのメール通知形式から取得されます。
メールテンプレートを大幅にカスタマイズした場合は、継続的な会話のメールがどのようにレンダリングされるかをテストします。テンプレートはローカライズされ、サポートのユーザープロファイル言語に基づいて翻訳されます。
ステップ4：ワークフローをテストする
ライブになる前に、完全なテストを実行します。
- ウェブサイトを開き、Webウィジェットで会話を開始します
- メッセージを送信し、ブラウザを閉じるか、移動します（放棄をシミュレートします）
- エージェントワークスペースから会話に応答させます
- 非アクティブのしきい値を待ちます（デフォルト：未読メッセージがある非アクティブと見なされる会話）
- メール通知が正しいコンテンツで届くことを確認します
- メールに返信し、応答がZendeskチケットに表示されることを確認します
- ウェブサイトのウィジェットに戻り、そこでも会話を継続できることを確認します
メールの返信とウィジェットへの復帰の両方のパスをテストします。どちらも完全な会話スレッドを維持する必要があります。
ハンドオフのタイミングとチケットステータスの管理
ほとんどのチームがここで問題に直面します。Zendeskのデフォルトのチケットライフサイクルは、顧客を混乱させるギャップを生み出します。
エージェントがチケットを解決すると、Zendeskはデフォルトで4日間待機してから、ステータスを「クローズ済（Closed）」に変更します。その4日間、顧客がメッセージングウィジェットに戻ると、新しい会話を開始できません。代わりに、メッセージは既存のチケットに追加され、以前のエージェントが割り当てられたままになります。
これにより、次の2つの問題が発生します。
- 顧客は新しい問題を報告できません。古い会話スレッドに詰まっているためです
- 新しい問題が解決済みの問題と混ざり合うと、コンテキストが混乱します
解決済からクローズ済へのタイミングの調整
これを修正するには、2つのオプションがあります。
オプション1：デフォルトの自動化を編集する
Zendeskには、**「ステータスが解決済に設定されてから4日後にチケットをクローズする」**という自動化が含まれています。この期間を短縮できます。
- 管理センター > オブジェクトとルール > 自動化に移動します
- デフォルトのクローズ自動化を見つけて編集します
- 時間条件を4日から希望の期間（最短1時間、最長28日）に変更します
- 保存してテストします
オプション2：即時クローズトリガーを作成する
より詳細な制御を行うには、タグ付けされたときにチケットをすぐにクローズするトリガーを作成します。
- 条件：タグ | 次のいずれかを含む |
close - アクション：ステータス | クローズ済
次に、メッセージングを介して送信されたチケットを解決するときに、マクロまたは自動化を介してcloseタグを追加します。
1つの重要な注意点：CSATアンケートを使用している場合は、チケットをすぐにクローズしないでください。アンケートはチケットが「解決済」とマークされたときに送信されるため、クローズが速すぎるとアンケートエクスペリエンスが妨げられる可能性があります。ほとんどのチームは1〜4時間のバッファーがうまく機能することを見出しています。
チャットからメールへのZendeskハンドオフ中にコンテキストを保持する
顧客がすでに共有した情報を繰り返すよりも、顧客をイライラさせるものはありません。チャネルの移行でコンテキストが確実に維持されるようにする方法を次に示します。
Zendeskは、完全な会話のトランスクリプトを自動的にチケットに添付します。エージェントは、顧客がチャットで言ったことすべて、AIエージェントとのやり取りなど、すべてを確認できます。ただし、生のトランスクリプトは長くなる可能性があり、忙しいエージェントは常に完全に読みません。
構造化されたコンテキストを渡すには：
カスタムチケットフィールドを使用すると、会話中に特定のデータポイントをキャプチャできます。ダイアログビルダーでZendesk AIエージェントを使用している場合は、注文番号、製品カテゴリ、または問題の種類などのチケットフィールドにマッピングする「詳細を尋ねる」ステップを追加します。これらはチケットのサイドバーに目立つように表示されます。
メタデータの受け渡しは、アカウントIDやセッション情報などの技術データを処理します。これには、Webウィジェットでコードを使用して、カスタムデータをチケットに渡す必要があります。設定にはより多くの作業が必要ですが、特定のレコードを参照する必要があるeコマースまたはSaaSサポートに役立ちます。
内部メモには、AIが生成した要約を含めることができます。一部のチームは、エージェントが引き継ぎを行う前に、顧客の問題の簡単な要約を作成するようにAIエージェントを設定しています。これにより、エージェントはトランスクリプトを掘り下げることなく「TL;DR」を取得できます。
目標は簡単です。エージェントは、チケットを開いてから数秒以内に顧客が何を必要としているかを知っている必要があります。顧客に情報の繰り返しを求める必要がある場合、自動化が提供することになっていた効率の向上は失われています。
チャットからメールへのZendeskハンドオフの一般的な問題のトラブルシューティング
問題：チケットがデフォルトでメッセージングチャネルに戻る
これは、Zendeskが認識している既知の苦痛です。メッセージングとして開始されたチケットが再度開かれると、最後のやり取りがメールであっても、デフォルトでメッセージングチャネルに戻ります。
その結果、エージェントは顧客にメールを送信していると思って「送信」を押しますが、実際にはチャットメッセージを送信しています。これは、顧客がオンラインで受信できない場合に特にイライラします。
Zendeskのプロダクトマネージャーによると、これは予期される動作であり、すぐに変更する予定はありません。ただし、コミュニティはこの問題について声を上げています。
メッセージングチケットが届き、チケットを解決するためにチャネルをメールに変更するのは非常に不便です。ただし、チケットが再度開かれると、チャネルはメッセージングに戻ります。これはまったく意味がありません。
回避策：
- 送信する前に、常にチャネルセレクターを確認するようにエージェントをトレーニングします
- チャネルが変更されたときにチケットにタグを付けるトリガーを作成し、エージェントに確認を促します
- 内部メモを使用して、会話がメールに移行したときにドキュメント化します
問題：顧客が新しい会話を開始できない
症状：顧客がメッセージングウィジェットに戻りますが、新しい会話を開始する代わりに、以前の会話が再度開きます。
原因：チケットステータスは「解決済」であり、「クローズ済」ではありません。「クローズ済」になるまで、顧客は新しい会話を開始できません。
修正：前述の自動化またはトリガーメソッドを使用して、「解決済」から「クローズ済」への遅延を短縮します。ほとんどのチームにとって、1〜4時間のバッファーは、顧客の混乱を引き起こすことなく、CSATアンケートに十分なバッファーを提供します。
問題：メール通知が送信されない
継続的な会話のメールが顧客に届かない場合：
- 管理センター > チャネル > メールでサポートメールアドレスが正しく設定されていることを確認します
- 「継続的な会話のメールをリクエスト」トリガーがアクティブであることを確認します
- スパムフォルダーとメールの配信設定を確認します
- チケットステータスがすでに「クローズ済」になっていないことを確認します（クローズ済のチケットにはメールは送信されません）
- エージェントが応答したときに、会話が実際に未読メッセージで非アクティブであったことを確認します
チャットからメールへのハンドオフの代替アプローチ
Zendeskのネイティブな継続的な会話は多くのチームで機能しますが、唯一のオプションではありません。サードパーティのチャットボットプラットフォームは、同じ問題に対して異なるアプローチを提供します。
Adaは、スレッドの継続性を維持しながらZendeskチケットを作成するメールハンドオフブロックを提供します。SMTPコネクタを使用すると、人間のエージェントはAIエージェントと同じメールアドレスから返信できるため、すべてが1つのスレッドに保持されます。
Botsonicは、非同期メールの継続ではなく、ライブエージェントのハンドオフに焦点を当てた、よりシンプルな統合を提供します。設定は簡単ですが、「顧客が離れて後で継続する必要がある」というユースケースをエレガントに解決しません。
Deepconverseは、ウィジェットベースのハンドオフでZendesk Chat Classicをターゲットにしています。これは、Agent Workspaceにまだ移行していない場合に役立ちますが、Classic Chatは段階的に廃止されています。
サードパーティソリューションとのトレードオフは複雑さです。柔軟性は向上しますが、管理する別のシステム、維持する別の統合、および潜在的な障害点が追加されます。
ネイティブのZendesk構成が制限されていると感じる場合、またはダイアログビルダーの複雑さによって速度が低下している場合は、よりシンプルなアプローチを提供します。eesel AIでは、Zendeskと直接統合し、ビジュアルビルダーでブロックをドラッグする代わりに、プレーンな英語でエスカレーションルールを定義できます。また、ライブになる前に、過去のチケットでシミュレーションを実行して、ハンドオフがどのように機能するかを正確に確認することもできます。
チャットからメールへのZendeskハンドオフをスムーズに処理を開始する
チャットからメールへのハンドオフを正しく行うことは、ほとんどのチームが認識しているよりも重要です。それは、顧客があなたの旅を理解していると感じるか、チャネルを切り替えるたびに最初からやり直していると感じるかの違いです。
覚えておくべき重要なポイント：
- 管理センターで継続的な会話を有効にするして、メール通知をアクティブにします
- 「解決済」から「クローズ済」へのタイミングを調整するして、顧客が古い会話で動けなくなるのを防ぎます
- カスタムフィールド、メタデータ、および内部メモを通じてコンテキストを保持することで、エージェントが顧客に繰り返し尋ねることがないようにします
- チャネルの永続性の癖についてエージェントをトレーニングすることで、メールを送信するつもりが誤ってチャットメッセージを送信しないようにします
エスカレーションのニーズに対してZendeskダイアログビルダーが複雑であると感じる場合、またはライブになる前にハンドオフシナリオをテストしたい場合は、お手伝いできます。プレーンな英語のルールでハンドオフを処理し、既存のチケットとドキュメントから学習し、顧客に表示される前に過去のデータに対してシミュレーションを実行できます。
次のステップ：
- 現在の継続的な会話の設定とタイミング設定を監査します
- チャットの開始からメールの返信までの完全なワークフローをテストして、コンテキストが正しく流れることを確認します
- チャネル切り替えの動作を含めるようにエージェントトレーニング資料を確認します
- エスカレーションの複雑さがよりシンプルなアプローチを保証するかどうかを検討します
よくある質問
Share this article
Article by
Stevia Putri
Stevia Putri is a marketing generalist at eesel AI, where she helps turn powerful AI tools into stories that resonate. She’s driven by curiosity, clarity, and the human side of technology.
