メールスレッドは、ヘルプデスクの中で最も華やかな機能ではないかもしれませんが、間違えると、顧客は混乱し、エージェントは不満を抱き、会話は混沌と化します。顧客がチケットに返信した場合、そのメッセージが正しい場所に届く必要があります。常にです。
このガイドでは、Zendeskのメールスレッドについて知っておくべきことをすべて解説します。その仕組み、簡略化されたスレッドと元のスレッドの違い、既存のワークフローを壊さずに最新のアプローチを実装する方法について説明します。また、サポートチームがつまずく一般的な問題とその解決方法についても見ていきます。
会話管理の別のアプローチをお探しの場合は、eesel AIがZendeskと連携する代替手段を提供しています。詳細については後述します。
Zendeskにおけるメールスレッドとは？
メールスレッドとは、Zendeskが関連するメッセージを1つのチケット会話にグループ化する方法です。顧客がサポートアドレスにメールを送信し、エージェントが返信した場合、その顧客からの後続の返信は同じチケットにとどまるようにする必要があります。新しいチケットを作成したり、間違ったチケットに添付したりするのではなく、所属する場所に留まるようにします。
ここで重要な区別は、メールスレッドは技術的なメカニズム（関連するメッセージのチェーン）であり、メール会話は人々の間の実際のやり取りであるということです。スレッドはすべてを整理し、会話が意味をなすようにします。
Zendeskは、受信メール内のシグナルを調べて、既存のチケットにリンクしているかどうかを自動的に処理します。一致するものが見つかった場合、返信はコメントとして追加されます。そうでない場合は、新しいチケットが作成されます。理論的には簡単ですが、詳細が重要です。
ここでの進化は注目に値します。従来のメールシステムは、スレッド化のために件名に大きく依存していました。最新のアプローチ（これについては後述します）では、人々が実際に今日メールを使用する方法とうまく連携する、より洗練されたシグナルを使用します。
Zendeskがメールをチケットにスレッド化する方法
Zendeskは、受信メールが既存のチケットに属するかどうかを判断するために、3つの方法を使用します。これらを理解することは、スレッドの問題をトラブルシューティングする際に役立ちます。
メールヘッダー（ReferencesとIn-Reply-To）
すべてのメールには、通常の表示では見えないヘッダーがあります。これらのうち2つは、スレッド化にとって非常に重要です。
- Message-ID（メッセージID）: 送信されたすべてのメールに割り当てられる一意の識別子
- In-Reply-To（返信先）: 返信されるメールのMessage-IDが含まれています
- References（参照）: 会話の以前のMessage-IDのリスト
Zendeskはメールを受信すると、既存のチケットのMessage-IDに対して、In-Reply-ToヘッダーとReferencesヘッダーをチェックします。一致するものがある場合、メールはそのチケットにスレッド化されます。
メッセージ本文にエンコードされたID
Zendeskは、送信通知メールにエンコードされたチケットIDを含めます。これは[1G7EOR-0Q2J]のように見え、メール本文に表示されます。顧客が返信し、このIDを含めると（ほとんどのメールクライアントで自動的に行われます）、Zendeskはそれを使用して返信を正しいチケットにルーティングします。
エンコードされたIDを手動でメールに含めて、正しくスレッド化されるようにすることもできます。
受信アドレスにエンコードされたID
Zendeskサポートメールアドレスは、エンコードされたチケットIDを含むエイリアスを使用できます。たとえば、support+id1G7EOR-0Q2J@company.zendesk.comです。この構造により、他の参照が存在しない場合でも、メールが対応するチケットにスレッド化されるようになります。
この方法は、外部転送アドレスではなく、Zendeskサポートアドレスでのみ機能します。
簡略化されたメールスレッドの説明
2022年6月、Zendeskは簡略化されたメールスレッドを導入しました。アカウントが2022年6月15日以降に作成された場合は、すでに使用しています。アカウントが古い場合は、元のエクスペリエンスを使用している可能性があります。
違いは何ですか？
元のスレッドエクスペリエンスでは、すべてのメール通知で会話の完全な履歴が繰り返されます。したがって、チケットに10個のコメントがある場合、11番目の通知には以前の10個のコメントがすべて含まれます。これは、メールクライアントの洗練度が低かった数年前には理にかなっていましたが、今日では冗長です。
簡略化されたスレッドでは、各通知で最新のコメントのみが送信されます。Gmailのような最新のメールクライアントは、スレッドをネイティブに処理するため、顧客は各メッセージで繰り返されるコンテンツではなく、クライアントのインターフェイスを通じて会話の完全なコンテキストを確認できます。
比較は次のとおりです。
| 側面 | 元のエクスペリエンス | 簡略化されたエクスペリエンス |
|---|---|---|
| メッセージコンテンツ | スレッドの完全な履歴を繰り返す | 最新のコメントのみを表示 |
| メールクライアントの互換性 | 基本 | Gmail、Outlook、Apple Mailに最適化 |
| 新しいアカウントのデフォルト | 2022年6月以前のアカウント | 2022年6月15日以降のアカウント |
| 冗長なメッセージ | すべての通知に含まれる | 削除済み |
| モバイルエクスペリエンス | スクロールする長いメール | 簡潔で読みやすいメッセージ |
簡略化されたスレッドの利点
エンドユーザーにとって、エクスペリエンスはより自然な会話のように感じられます。各メールには、繰り返されるテキストの壁ではなく、新しい情報のみが含まれています。たとえば、Gmailでは、会話ビューにスレッドがネイティブに表示され、冗長性がありません。
エージェントにとって、メール通知はよりクリーンでスキャンしやすくなります。チケットが更新されたという通知を受け取ると、すでに知っている履歴全体ではなく、何が変更されたかを確認できます。
簡略化されたメールスレッドの実装方法
古いZendeskアカウントを使用しており、簡略化されたスレッドに切り替えたい場合は、物事を壊さずにそれを行う方法を次に示します。
前提条件
開始する前に：
- アクティブなトリガーと自動化を確認します
- 現在のメールテンプレートをバックアップします
- ボリュームの少ない期間中に実装を計画します
- これはすべてのメール通知に影響することを理解してください
ステップ1：更新するトリガーと自動化を特定する
古いコメントプレースホルダーを使用してメール通知を送信するすべてのアクティブなトリガーと自動化を見つける必要があります。メール本文のコンテンツでこれらを探してください。
{{ticket.comments}}{{ticket.latest_comment}}{{ticket.comments_formatted}}{{ticket.latest_comment_formatted}}{{ticket.latest_comment_rich}}{{ticket.public_comments}}{{ticket.latest_public_comment}}{{ticket.public_comments_formatted}}{{ticket.latest_public_comment_formatted}}{{ticket.latest_public_comment_rich}}
通常、更新が必要なデフォルトのトリガーには、次のものがあります。
- コメントの更新をリクエスターとCCに通知する
- コメントの更新をアサイン担当者に通知する
- アサイン担当者に割り当てを通知する
- 再開されたチケットをアサイン担当者に通知する
- 受信したリクエストをすべてのエージェントに通知する
- グループに割り当てを通知する
出典：実装ガイド
ステップ2：新しいプレースホルダーでトリガーを複製して更新する
既存のトリガーを直接編集しないでください。代わりに：
- 更新が必要な各トリガーを複製します
- クローンを名前変更します（名前に「（簡略化）」を追加します）
- 次のマッピングを使用して、古いプレースホルダーを新しいプレースホルダーに置き換えます。
| 元のプレースホルダー | 簡略化されたプレースホルダー |
|---|---|
{{ticket.comments}} | {{ticket.latest_comment_html}} |
{{ticket.latest_comment}} | {{ticket.latest_comment_html}} |
{{ticket.comments_formatted}} | {{ticket.latest_comment_html}} |
{{ticket.latest_comment_formatted}} | {{ticket.latest_comment_html}} |
{{ticket.latest_comment_rich}} | {{ticket.latest_comment_html}} |
{{ticket.public_comments}} | {{ticket.latest_public_comment_html}} |
{{ticket.latest_public_comment}} | {{ticket.latest_public_comment_html}} |
{{ticket.public_comments_formatted}} | {{ticket.latest_public_comment_html}} |
{{ticket.latest_public_comment_formatted}} | {{ticket.latest_public_comment_html}} |
{{ticket.latest_public_comment_rich}} | {{ticket.latest_public_comment_html}} |
- クローンされたトリガーを作成し、すぐに非アクティブ化します
- リストにあるすべてのトリガーに対して繰り返します
ステップ3：メールテンプレートを更新する
次の2つのテンプレートを更新する必要があります。
- フォロワーまたはCCテンプレート（アカウント設定によって異なります）
- アカウントレベルのHTMLおよびプレーンテキストテンプレート
最初に現在のテンプレートをバックアップします。次に、Zendeskのドキュメントから簡略化されたスレッドバージョンでコンテンツを置き換えます。
テストと検証
簡略化されたトリガーをアクティブ化する前に：
- いくつかの内部チケットでテストします
- Gmail、Outlook、Apple Mailでメールが正しくスレッド化されることを確認します
- 添付ファイルがまだ機能することを確認します
- エージェント通知が正しく表示されることを確認します
- 簡略化されたトリガーをアクティブ化し、元のトリガーを非アクティブ化します
一般的なスレッドの問題と解決策
適切な設定でも、スレッドの問題は発生します。最も一般的な問題とその解決方法を次に示します。
関係のない会話が一緒にスレッド化される
問題： 2つの異なる顧客の会話が同じチケットにまとまります。
原因： 共有されたMessage-IDまたはIn-Reply-Toヘッダー。これは通常、次の場合に発生します。
- エージェントが自分の受信トレイからZendeskにメールを複数回転送する
- 誰かが既存のZendeskメールに返信するが、件名と受信者を変更する
- 静的なMessage-IDを持つメールテンプレートが再利用される
解決策：
- 元のメールソースをチェックして、一致するMessage-IDを見つけます
- エージェントに、既存のメールを転送するのではなく、新しいメールを作成するようにトレーニングします
- Zendesk通知から発信されたメールテンプレートを再利用しないでください
件名の変更によりスレッドが中断される
問題： エージェントがチケットの件名を更新すると、後続のメールにより、顧客のメールクライアントに新しいスレッドが作成されます。
原因： 多くのメールクライアント（Gmailを含む）は、ヘッダーだけでなく、スレッド化に件名を使用します。
回避策： チケットIDを含む静的な件名を使用するように通知トリガーを変更できますが、これにより通知から件名のコンテキストが削除されます。Zendeskはこれを機能リクエストとして認識していますが、まだ修正プログラムを実装していません。
メールを転送するとスレッドの問題が発生する
問題： 転送されたメールが間違ったチケットにスレッド化されるか、予期しない動作が発生します。
原因： 転送は元のヘッダーを保持するため、Zendeskはそれを元の会話への返信と見なします。
解決策： 転送する代わりに、メールコンテンツをまったく新しいメールにコピーします。または、元のメールを添付ファイルとして保存し、新しいメッセージに添付します。
メールスレッドのベストプラクティス
スレッドの頭痛を防ぐためのいくつかの習慣：
- まだ使用していない場合は、簡略化されたスレッドを使用します。最新のメールクライアントではよりクリーンです。
- トリガーの衛生状態を維持します。四半期ごとにメールトリガーを確認して、古いものを削除します。
- チームをトレーニングします。エージェントが転送とテンプレートがスレッドにどのように影響するかを理解していることを確認します。
- 問題を監視します。予期せずコメント数が多いチケットのビューまたはレポートを設定します（スレッドの問題を示す可能性があります）。
- 変更後にテストします。メールテンプレートまたはトリガーを変更するたびに、完全に展開する前に、いくつかのチケットでスレッドをテストします。
eesel AI：会話管理への別のアプローチ
Zendeskのメールスレッドが管理するよりも複雑に感じる場合は、別のオプションがあります。eesel AIは、会話を異なる方法で処理します。
メールヘッダーとエンコードされたIDに依存する代わりに、AIは各メッセージのコンテンツを読み取り、理解します。それはできます：
- アドレスだけでなく、コンテンツに基づいて会話を適切なチームに自動的にルーティングします
- 会社のトーンとポリシーに一致する応答を下書きします
- チケットをまったく作成せずにルーチンな質問を処理します
- 完全なコンテキストで複雑な問題を人間にエスカレートします
AIが会話の流れを理解しているため、スレッドは自然に発生します。Message-ID、ヘッダー形式、またはテンプレートの更新について心配する必要はありません。
すでにZendeskを使用しているチームの場合、eesel AIは直接統合されます。AIエージェントは既存のZendeskセットアップ内で動作するため、ヘルプデスクを置き換えることなく、よりスマートな会話処理を実現できます。
コストを比較する場合は、eesel AIの価格を確認してください。Eesel AIはエージェントごとではなく、インタラクションごとに課金するため、大量のサポートチームの計算が変わります。
メールスレッドの設定を最大限に活用する
Zendeskのメールスレッドは、メカニズムを理解するとうまく機能します。重要なポイント：
- 簡略化されたスレッドが最新の標準です。まだ切り替えていない場合は切り替えてください。
- スレッドの問題は通常、ヘッダーの問題または転送の習慣に起因します。
- トリガーをクリーンに保ち、展開する前に変更をテストします。
- チームに適切なメール処理をトレーニングして、スレッドの事故を防ぎます。
顧客の問題を解決するよりもスレッドの問題の管理に多くの時間を費やしている場合は、代替手段を検討する時期かもしれません。ZendeskのAIエージェントは、会話の複雑さを処理するため、実際のサポートに集中できます。
サポートワークフローを合理化する準備はできましたか？eesel AIがZendeskとどのように連携するかを確認するか、無料トライアルを開始して、実際のチケットでテストしてください。
よくある質問
この記事を共有
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.
