顧客がサポートメールを送信すると、次に何が起こるかによって、問題が迅速に解決されるか、混乱の中で失われるかが決まります。Zendesk は、その引き継ぎをシームレスにし、メールを追跡可能なチケットに自動的に変換することで評判を築いてきました。しかし、本当の力は、それらのチケットをどのように構成するかにあります。つまり、どのような情報がキャプチャされ、どこに送信され、どのように適切なアクションをトリガーするかです。
このガイドでは、基本的なメールチャネルの設定から高度なカスタムフィールドの自動化まで、Zendeskのメールからチケットへのマッピングとフィールドの仕組みを詳しく解説します。初めてサポートアドレスを設定する場合でも、特定のデータが期待どおりに入力されない理由をトラブルシューティングする場合でも、知っておくべき実践的な手順と実際の制限事項が見つかります。
Zendeskがメールをチケットに変換する方法
メールチャネルは、ほとんどのZendesk実装のバックボーンです。顧客がサポートアドレスにメールを送信すると、舞台裏で次のことが起こります。
- チケットの作成：Zendeskはメールを受信し、件名をチケットのタイトルとして、メール本文を説明として新しいチケットを作成します。
- ユーザーの検索：システムは、送信者のメールアドレスが既存のユーザープロファイルと一致するかどうかを確認し、必要に応じて新しいユーザーを作成します。
- 自動応答：顧客は、リクエストが受信されたことを知らせる確認メールを受信します。
- ルーティング：トリガーとビジネスルールに基づいて、チケットはグループ、特定のエージェントに割り当てられるか、キューに置かれます。
- スレッド化：両側からの返信は、同じチケットの会話に自動的にスレッド化されます。
このワークフローは手動による介入なしに行われるため、メールは依然として最も人気のあるサポートチャネルです。ただし、デフォルトの動作では、送信者、件名、本文テキストなどの基本的な情報のみがキャプチャされます。メッセージを受信したメールアドレスに基づいて、製品ライン、優先度、または部門ごとにチケットを分類する必要がある場合は、カスタムフィールドとトリガーを構成する必要があります。
メールチャネルは、2種類の通知も生成します。サポートスタッフは、新しいチケットが到着したとき、割り当てが変更されたとき、または顧客がコメントを追加したときにアラートを受信します。顧客は、確認、エージェントの返信、およびステータスの更新を受信します。これらの通知はトリガーによって制御され、カスタマイズできます（ただし、Zendeskは、通信フローを維持するために、デフォルトの通知トリガーをアクティブにしておくことを推奨しています）。
Zendeskチケットフィールドの理解
Zendeskのすべてのチケットには、システムフィールドとオプションのカスタムフィールドが混在しています。違いを理解することで、キャプチャするデータとそれを使用する方法を計画できます。
システムフィールドは組み込みであり、件名、説明、リクエスタ、優先度（低/普通/高/緊急）、ステータス（新規/オープン/保留/解決済み/クローズ済み）、およびタイプ（質問/インシデント/問題/タスク）などの必須項目が含まれます。これらを削除することはできず、すべてのチケットで自動的に利用できます。
カスタムチケットフィールドは、独自のデータポイントを追加する場所です。Zendeskは多数のフィールドタイプをサポートしており、それぞれが異なる種類の情報に適しています。
| フィールドタイプ | 最適な用途 | トリガーサポート |
|---|---|---|
| テキスト（単一行） | 注文番号などの短いエントリ | トリガーを介して設定できません |
| テキスト（複数行） | 詳細なメモまたは説明 | トリガーを介して設定できません |
| ドロップダウン | 事前定義されたカテゴリ（製品、部門） | 関連付けられたタグを設定します |
| 複数選択 | 複数の適用可能なオプション | 関連付けられたタグを設定します |
| チェックボックス | はい/いいえフラグ | 関連付けられたタグを設定します |
| 日付 | 締め切りまたはイベントの日付 | 直接設定できます |
| 数値 | 数量または評価 | サポートは限定的です |
| 正規表現 (Regex) | パターン検証されたエントリ（電話番号など） | サポートは限定的です |
| ルックアップ関係 | 他のZendeskレコードへのリンク | トリガー/ビューでサポートされています |
多くの管理者を悩ませる重要な詳細は、テキストフィールドはトリガーを介して入力できないことです。これはZendeskのハードリミテーションです。メールから情報（顧客名や注文IDなど）を抽出し、カスタムテキストフィールドに自動的に入力しようとする場合、トリガーは機能しません。Zendesk API、サードパーティの統合、またはテキストフィールドの代わりにタグを使用するなどの代替アプローチが必要になります。
ドロップダウン、チェックボックス、および複数選択フィールドは、異なる動作をします。選択するとタグが生成され、トリガーは対応するタグを追加することでこれらのフィールド値を設定できます。この区別は、メールからフィールドへのマッピング戦略を計画する際に重要になります。
Zendeskでのカスタムチケットフィールドの作成
カスタムフィールドの設定は、管理センターで行います。作成または変更するには、管理者権限が必要です。
カスタムチケットフィールドを追加するには：
- 管理センター > オブジェクトとルール > チケット > フィールドに移動します。
- フィールドを追加をクリックし、フィールドタイプを選択します。
- 表示名を入力します（「チャネル」などの予約語は避けてください）。
- 権限を設定します。
- エージェントは編集可能：内部使用のみ
- 顧客は編集可能：チケットとサポートリクエストフォームに表示されます
- 顧客は表示可能：エンドユーザーに対して読み取り専用
- フィールド固有のオプション（ドロップダウンの値、検証用の正規表現パターン）を構成します。
- 保存をクリックします。
単一のチケットフォームの場合、新しいフィールドは自動的に表示されます。複数のチケットフォームを使用する場合（Enterpriseプランで利用可能）、表示する必要がある各フォームにフィールドを手動で追加する必要があります。
命名規則が重要です。 エージェントにとって意味のある一貫性のある説明的な名前を使用します。「Product_Category」は「Field_01」よりも明確です。また、カスタムフィールドを削除すると、タグ生成フィールド（ドロップダウン、チェックボックス、または複数選択）でない限り、既存のチケットからデータが削除されることに注意してください。それらは、フィールドが消えた後でもタグとして保持されます。
フィールドを作成する前に、それらをどのように使用するかを検討してください。トリガーと自動化で機能するフィールドは、チケットに存在するだけのフィールドよりも価値があります。レポートも計画してください。Zendesk Exploreで特定のディメンションでチケットを分析する場合は、チケットのコメントだけでなく、適切なフィールドにデータが必要です。
トリガーを使用したメールデータからチケットフィールドへのマッピング
トリガーは、チケットイベント用のZendeskの自動化エンジンです。「これが起こったら、あれをする」ルールを定義できます。メールからチケットへのマッピングの場合、トリガーは、メッセージを受信したメールアドレスなどの条件に基づいてフィールド値を設定できます。
トリガーの仕組み：
トリガーは、チケットが作成または更新されたときに条件を評価します。すべての条件が一致すると、トリガーが起動し、アクションを実行します。複数のトリガーが同じチケットで起動し、配置した順に実行されます。
一般的なメールベースのトリガー条件：
- チケット > チケット | 次の場合 | 作成済み（新しいチケットで起動します）
- チケット > 受信日時 | support@company.com（特定のサポートアドレス）
- チケット > リクエスタのメールアドレスドメイン | example.com（顧客組織のルーティング用）
- チケット > 件名テキスト | 次の文字列を含む | "緊急"（キーワード検出）
サポートアドレスに基づいて優先度を設定する：
実用的な例：一般的なサポートとVIP顧客のために別々のメールアドレスがあります。VIPメールを自動的に高優先度としてマークしたいとします。
- 新しいトリガーを作成します。
- 条件を追加します。
- チケット > チケット | 次の場合 | 作成済み
- チケット > 受信日時 | vip@company.com
- アクションを追加します。
- チケット > 優先度 | 高
- トリガーを保存します。
これで、vip@company.comへのメールから作成されたすべてのチケットは、高優先度で開始されます。
テキストフィールドの制限（再検討）：
メールの件名または本文からテキストを抽出し、カスタムテキストフィールドに入力するトリガーを作成することはできません。誰かが「注文＃12345の払い戻しが必要です」というメールを送信した場合、ネイティブのZendeskトリガーを使用して「12345」を注文番号テキストフィールドに自動的に解析することはできません。
回避策は次のとおりです。
- 代わりにタグを使用する（トリガーはメールコンテンツに基づいてタグを追加でき、タグは検索可能です）
- エージェントにフィールドに情報を手動でコピーするようにトレーニングする
- 高度な解析のためにサードパーティのアプリまたはZendesk APIを使用する
- 構造化されたデータ収集のために、顧客をヘルプセンターのチケットフォームに誘導する
eesel AIを使用した高度なフィールドマッピング
手動のトリガー構成は、単純なルーティングルールには機能しますが、制限があります。重要な開発作業なしに、メールから非構造化データを抽出したり、自然言語を解析したり、コンテンツに基づいてチケットを自動的に分類したりすることはできません。
ここで、eesel AI で異なるアプローチを取ります。複雑なトリガーロジックを構築する代わりに、当社のAIチームメイトは過去のチケットから学習し、ビジネスを自動的に理解します。
eesel AIをヘルプデスクに接続すると、既存のチケット、ヘルプセンターの記事、およびマクロを読み取り、トーン、一般的な問題、およびリクエストの分類方法を理解します。そこから、次のことができます。
- メールコンテンツを自動的に解析する：手動ルールなしで、非構造化メールテキストから注文番号、製品名、または問題の種類を抽出します。
- フィールドをインテリジェントに入力する：履歴データから学習したことに基づいて、カスタムフィールドを設定します。
- チケットをコンテキストに応じてルーティングする：受信したメールアドレスだけでなく、コンテンツに基づいて適切なチームに問題を送信します。
- 会話全体を処理する：応答を下書きし、Shopifyなどの統合システムで顧客データを検索し、エンドツーエンドでチケットを解決します。
重要な違いは、厳格なルールでeeselを構成しないことです。新しいチームメンバーとして採用し、監督から開始し（送信前に下書きを確認します）、それが証明されるにつれて完全な自律性にレベルアップします。間違いを犯した場合、それを平易な英語で修正すると、次回のために学習します。
メールの解析とフィールドマッピングに関するZendeskのネイティブの制限に苦労しているチームにとって、このアプローチにより、複雑なトリガーチェーンやカスタム開発の必要性がなくなります。既存のZendesk設定でどのように機能するか を確認するか、自動チケットフィールド入力のためのAIトリアージ機能 を調べてください。
一般的な課題と解決策
適切な設定を行っても、メールからチケットへのマッピングには摩擦が生じます。最も頻繁に見られる問題とその対処方法を次に示します。
メールの署名と免責事項が説明を乱雑にする
長いメールスレッドには、署名、法的免責事項、および以前の会話履歴が含まれていることがよくあります。Zendeskはこれらの一部を削除しようとしますが、完璧ではありません。その結果、実際の問題がノイズに埋もれているチケットが発生します。
解決策：実際のメッセージをメールの先頭に配置するようにユーザーをトレーニングします。Zendeskに送信する自動システムの場合は、メールの代わりにAPIを使用して、チケットコンテンツを完全に制御できるようにします。
複数のメールアドレスが重複するユーザーを作成する
課題：顧客が今日john@work.comから、明日john@gmail.comからメールを送信します。Zendeskは2つの別々のユーザープロファイルを作成し、サポート履歴を断片化します。
解決策：発見されたらユーザープロファイルをマージするか、SSOを使用して一貫したIDを確保します。一部の組織では、マージする前にメールの所有権を確認するために検証手順を追加しています。
テキスト抽出の制限
課題：メールから特定のデータ（アカウント番号や製品SKUなど）をキャプチャする必要があり、トリガーでは実行できません。
解決策：受信メールを解析するミドルウェアサービスでZendesk APIを使用するか、自由形式のメールの代わりにデータ収集のためにチケットフォームに切り替えます。または、AI搭載ツールは、カスタム開発なしでこの抽出を処理できます。
HTML形式の問題
課題：リッチHTMLメールがZendeskで適切にレンダリングされないか、形式が削除されて読みやすさが損なわれます。
解決策：Zendeskは、チケットの説明のためにHTMLをプレーンテキストに変換します。複雑な形式設定されたコンテンツの場合は、インラインメールHTMLの代わりにヘルプセンターまたは添付ファイルの使用を検討してください。
条件付きフィールドの表示
課題：特定のフィールドに特定の値がある場合にのみ、特定のフィールドを表示したい（タイプが「払い戻し」の場合にのみ「払い戻し理由」フィールドを表示するなど）。
解決策：これには、Suite Professional以上で利用可能な条件付きチケットフィールドが必要です。これらは、管理センター > オブジェクトとルール > チケットフォームで構成します。
Zendeskメールマッピングを最大限に活用する
メールからチケットへのマッピングの構成は、1回限りのタスクではありません。ビジネスが進化するにつれて、フィールド戦略も進化する必要があります。
構築する前に計画してください。 キャプチャする必要があるデータ、そのデータの取得元、およびそのデータの使用方法をマッピングします。誰もレポートしたり、自動化で使用したりしないフィールドは、単なる混乱です。
一貫した命名を使用します。 早めに規則を確立します。「Product_Category」と「Department_Code」は、「Field1」と「Custom2」よりも明確です。
徹底的にテストします。 メールでテストチケットを作成し、トリガーが期待どおりに起動することを確認します。フィールド値が正しく表示され、ルーティングが適切なグループに発生することを確認します。
セットアップを文書化します。 数十のトリガーとカスタムフィールドがある場合、それらを構築した人でさえ、特定のルールが存在する理由を忘れてしまいます。簡単な参照ドキュメントを保管してください。
代替案を検討してください。 メール解析を処理するためにますます複雑なトリガーチェーンを構築している場合、またはエージェントがフィールドに手動でデータをコピーするのにかなりの時間を費やしている場合は、AI搭載の代替案を検討する時期かもしれません。目標は、チケットメタデータを管理することではなく、顧客の問題を解決することです。
Zendeskのメールチャネルは強力ですが、データ抽出とフィールド入力には実際の制限があります。これらの境界を理解することで、Zendeskの制約内で作業するか、自動的に重労働を処理するツールを探索するかにかかわらず、実際に機能するワークフローを設計できます。
