Zendeskのチャネル切り替え：2026年に可能なことと不可能なこと

Zendeskでチケットのチャネルを変更しようとしたことがある場合（たとえば、電話からEmailへ）、壁にぶつかったことがあるかもしれません。それはあなただけではありません。これはZendeskコミュニティで最も要望の多い機能の1つであり、サポートチームにとって本当に不満の種です。

混乱は用語から始まります。Zendeskはメッセージングの会話に「チャネル転送（channel transfers）」を提供していますが、それはチケットのチャネルプロパティを変更することとはまったく異なります。一方は機能しますが、もう一方は機能しません。このガイドでは、実際に何が可能か、なぜ制限が存在するのか、そしてそれを回避する方法を明確にします。

チャネル切り替えの混乱

すぐにこれを明確にしましょう。人々が「Zendeskのチャネル切り替え（Zendesk channel switching）」と言うとき、通常は次の2つのうちの1つを意味します。

チャネル転送（サポート対象）： Web Widget（ウェブウィジェット）からWhatsApp（ワッツアップ）のように、あるメッセージングチャネルから別のチャネルへ会話を移動すること。これにより、会話履歴が保持され、すべてが1つのスレッドに保持されます。

チャネル変更（サポート対象外）： Talk（トーク）チケットをEmail（メール）に切り替えるように、チケットのチャネルプロパティを変更すること。これはほとんどの人が実際に望んでいることですが、ネイティブでは不可能です。

要するに、メッセージングアプリ間で会話を移動しようとしている場合、Zendeskはそれを行うことができます。ルーティングとレポートの目的でチケットの分類方法を変更しようとしている場合は、運が悪いです。

ごく最近、あるエージェントが電話での会話をEmailでフォローアップしましたが、チケットはまだ電話として分類されていたため、通常のルーティングトリガーが発動しませんでした。チケットは、誰かが手動でピックアップして委任するまで、割り当てられていない状態でした。

Zendesk Community

Zendeskが実際にサポートしていること：チャネル転送

チャネル転送は、メッセージングの会話用に設計されています。これにより、コンテキスト（context）を失うことなく、顧客をあるチャネルから別のチャネルに移動できます。元のユースケース（use case）は単純でした。顧客がWebサイトでチャットを開始したが、離れる必要があるとします。顧客を失う代わりに、会話をWhatsAppまたはFacebook Messenger（フェイスブックメッセンジャー）に転送して、電話で会話を続けることができます。

チャネル転送の仕組み

転送を開始する方法は2つあります。

ユーザー開始： 顧客はWeb Widgetのボタンをクリックして、ソーシャルチャネルで会話を続けます。Zendeskはこれを自動的に処理します。コーディングは必要ありません。

ビジネス開始： システムはConversations API（会話API）を使用して、ユーザーを新しいチャネルにリンクします。これには開発作業が必要ですが、より多くの制御が可能になります。

APIアプローチでは、「リンク要求コード（link request code）」と呼ばれるものを使用します。システムはワンタイムトークン（one-time token）を生成し、それをユーザーに送信します。ユーザーがそれを受け入れると、チャネルがリンクされます。ユーザーには、新しいチャネルを接続するかどうかを尋ねるプロンプト（prompt）が表示され、確認されると、会話がシームレス（seamless）に続行されます。

確認タイプ

APIを使用する場合、ユーザーが転送を確認する方法を選択します。

出典：Zendeskチャネル転送ドキュメント（Zendesk Channel Transfer Documentation）

注意点

チャネル転送は、メッセージングチャネル間でのみ機能します。Web WidgetからWhatsAppへ、またはFacebook MessengerからInstagram Direct（インスタグラムダイレクト）へ移動できます。ただし、この機能を使用して、TalkチケットをEmailに変更したり、EmailチケットをChat（チャット）に変更したりすることはできません。チケットの元のチャネル分類は変わりません。

Zendeskがサポートしていないこと：チケットチャネルの変更

ここからがイライラするところです。Zendeskでは、チケットのチャネルプロパティを作成後に変更することはできません。顧客から電話があり、チケットが「電話（Phone call）」チャネルとして作成された場合、その後のすべての通信がEmailで行われたとしても、その状態が永久に維持されます。

これが重要な理由

チャネルプロパティは、いくつかの重要なことを制御します。

• ルーティングルール（Routing rules）： トリガーと自動化は、多くの場合チャネルに依存します。チケットが電話として分類されているが、フォローアップがEmailで行われる場合、「Email」ルーティングルールは発動しません。
• エージェントの行動： エージェントは誤って間違ったチャネルを介して返信する可能性があります。Emailを送信するつもりだったのに、「こんにちは[名前]」というチャットメッセージを送信するサポート担当者を誰もが見たことがあるでしょう。
• レポート： チャネルメトリクス（channel metrics）が歪められます。通話として開始されたが、Emailで完全に解決されたチケットは、レポートでは依然として電話チケットとしてカウントされます。

このマルチチャネルタッチの世界では、新しいチケットを作成したり、管理チームが電話から別のエージェントにチケットをプッシュするビューを監視したりする必要があるのは意味がありません。プラットフォームは、通話からチャット、チケット、メッセージ、通話へとシームレスに移行する必要があります。

Zendesk Community

Zendeskの見解

コミュニティの投稿によると、Zendeskはこの制限を認識しています。プロダクトマネージャーは、チャネル変更を有効にすることがロードマップにあり、2026年初頭が可能性のあるタイムフレームとして言及されていると述べています。しかし、今のところ、ネイティブソリューション（native solution）はありません。

出典：Zendeskコミュニティ：チャネル変更を有効にする（Zendesk Community: Enable Channel Change）

チャネル切り替えがワークフロー（workflow）にとって重要な理由

「だから何？チケットはどちらにしても解決される」と考えているかもしれません。しかし、チャネルの不一致は、実際の運用上の問題を引き起こします。

ルーティングの失敗

チケットのチャネルが実際に通信している方法と一致しない場合、自動ルーティングが中断される可能性があります。一般的なシナリオを次に示します。

1. 顧客が電話をかけ、ボイスメール（voicemail）を残します。チケットは「電話（着信）（Phone call (incoming)）」として作成されます。
2. エージェントが電話をかけ直しますが、応答が得られず、フォローアップEmailを送信します。
3. 顧客がEmailに返信します。
4. 「Email」チケットをサポートチームに割り当てるトリガーは、チケットがまだ電話として分類されているため、発動しません。
5. チケットは、誰かが手動でルーティングするまで、宙ぶらりんの状態になります。

これは、特に複数のチャネルを処理するチームでは、思ったよりも頻繁に発生します。

エージェントの混乱

インターフェース（interface）がエージェントの意図と一致すると、エージェントはより迅速に作業できます。チケットが間違ったチャネルにデフォルト（default）設定されている場合、間違いが発生します。エージェントはEmailを送信するつもりだったのに、チャットメッセージを送信します。間違ったマクロ（macro）をトリガー（trigger）します。アクティブ（active）なチャネルを確認するのに時間を無駄にします。

チケットがEmailチャネルになったら、デフォルトとしてその状態を維持する必要があります。

Zendesk Community

レポートの頭痛の種

チャネルのパフォーマンス（performance）を測定しようとしている場合、混合チャネルチケットはデータを汚染します。通話として開始されたが、Emailで解決されたチケットは、実際の問題がEmailで解決されたにもかかわらず、低い「通話解決」メトリクス（metrics）を示す可能性があります。これにより、どのチャネルが顧客にとって実際に機能しているかを理解することが困難になります。

実際に機能する回避策

Zendeskがネイティブのチャネル変更を追加するまでは、次の3つのアプローチが役立ちます。

カスタムフィールドアプローチ

「通信方法（Communication Method）」または「実際のチャネル（Actual Channel）」というカスタムドロップダウンフィールド（custom dropdown field）を作成します。エージェントがあるチャネルから別のチャネル（通話からEmailなど）に切り替えるとき、このフィールドを更新します。次に、ネイティブのチャネルプロパティの代わりに、カスタムフィールドを参照するようにルーティングトリガーを構築します。

長所： セットアップが簡単で、エージェントに制御を提供します 短所： フィールドを更新するにはエージェントの規律が必要で、デフォルトの返信チャネルは修正されません

トリガーベースのルーティング

チケットの通信パターン（communication pattern）が変化したときに検出するトリガーを設定します。次に例を示します。

• 「電話（Phone call）」チケットがEmailの返信を受信した場合、「email_follow_up」のようなタグ（tag）を追加します
• このタグを探すビューまたはルーティングルールを作成します
• これらのチケットを、マルチチャネルフォローアップを処理する特定のグループ（group）に自動割り当てします

これにより、チャネルは変更されませんが、チケットがとにかく正しくルーティングされるようになります。

チャネルの一貫性のためのマクロ

エージェントがチャネルを切り替えるときに使用できるマクロを作成します。たとえば、「Emailに切り替え（Switch to Email）」マクロは次のようになります。

• チャネル変更を文書化する内部メモ（internal note）を追加します
• ルーティングの目的でタグを適用します
• スイッチ（switch）を顧客に説明する標準応答（standard response）を追加します
• 必要に応じてチケットの優先度（priority）を更新します

これにより、プロセス（process）が標準化され、何も見落とされないようになります。

より良いアプローチ：eesel AIがマルチチャネルサポートを処理する方法

回避策は役立ちますが、根本的な問題は解決しません。本当の問題は、Zendeskがチャネルを固定プロパティ（fixed properties）として扱っていることです。最新のサポートは本質的に流動的であるにもかかわらずです。顧客は「チャネル」について考えることなく、Email、チャット、電話、ソーシャルメディア（social media）間をジャンプ（jump）します。

eesel AIでは、異なるアプローチを採用しています。チャネルプロパティの管理を試みる代わりに、どこで発生したかに関係なく、会話を解決することに焦点を当てています。

Zendeskでの仕組みを次に示します。

段階的な自律性： まず、eeselにエージェントレビュー（agent review）用の返信案を作成させます。自信がついたら、応答を直接送信させます。最終的には、定義した複雑な問題のみをエスカレーション（escalate）しながら、最前線のサポート全体を処理できます。

チャネル全体で機能： eeselは、Zendeskの任意のチャネル（Email、チャット、メッセージング、電話メモ）からチケットを読み取り、適切な応答案を作成します。AIが会話のコンテキスト（context）を理解しているため、チャネルは関係ありません。

平易な英語での制御： ルーティングおよびエスカレーションルールを自然言語で定義します。「常に請求の紛争をサラにエスカレーションする」または「払い戻し要求が30日を超える場合は、丁寧に拒否する」。複雑なトリガー構成は不要です。

履歴から学習： eeselを過去のチケット、ヘルプセンター（help center）の記事、マクロに接続します。最初からトーン（tone）、ポリシー（policy）、および一般的な問題を理解します。手動トレーニング（manual training）は必要ありません。

すでにZendeskに投資しているチームの場合、Zendesk用AIエージェント（AI Agent for Zendesk）は、既存のセットアップ（setup）に直接統合されます。ヘルプデスク（help desk）を置き換えるのではなく、強化します。AIはすべてのチャネルでルーチン（routine）応答を処理するため、エージェントは実際に人間のタッチ（touch）が必要な会話に集中できます。

チャネルの複雑さなしに統合されたサポートがどのように機能するかに興味がある場合は、Zendeskで複数のサポートチャネルを統合する（unifying multiple support channels in Zendesk）に関するガイドで、補完的な戦略について説明します。

チームに適したアプローチの選択

では、あなたの状況に最適なソリューション（solution）は何でしょうか？

ルーティングが簡単な小規模チームの場合： カスタムフィールドアプローチで十分でしょう。チャネルを切り替えるときにフィールドを更新するようにエージェントをトレーニングし、ルーティングを処理するためのいくつかのトリガーを構築します。

複雑なルーティングルールがある場合： トリガーベースのアプローチが必要です。セットアップにはより多くの作業が必要ですが、スケーリング（scaling）が向上し、エージェントがフィールドの更新を覚えておく必要はありません。

チャネル切り替えが日常的な頭痛の種である場合： AIでZendeskを強化することを検討してください。eesel AIのようなツールは、会話がどこから始まったかに関係なく、自律的に応答を処理することにより、チャネルの複雑さを完全に取り除きます。

結論：Zendeskのチャネル制限は現実のものですが、乗り越えられないものではありません。適切な回避策（または適切なAIチームメイト（teammate））を使用すると、ネイティブのチャネル変更が到着するのを待ちながら、サポートをスムーズ（smooth）に実行し続けることができます。