記事を読むよりも動画での確認を好む方は、以下の動画をご覧ください：

新しいメールを受信すると、ソフトウェアはそのメールのソースコードを検査し、新しいチケットを生成するか、既存のチケットに追加するかを判断します。ソースコードには、有用な情報を含むさまざまなメールヘッダーが含まれています。システムは以下のレコードを指定された順序で検索します：

  • In-Reply-To
  • References
  • Thread-Index（Outlookから送信されたメールにのみ適用）
  • Feedback-ID（eBayから送信されたメールにのみ適用）

In-Reply-ToヘッダーとReferencesヘッダーについては、システムはMessage-IDヘッダーで確認できるメールの固有IDを、既存のチケット内で検索します。いずれかのチケット内のメッセージのMessage-ID値が、受信メールのIn-Reply-ToまたはReferencesに含まれている場合、そのメールは既存のチケットに追加されます。Thread-IndexヘッダーとFeedback-IDヘッダーについては、システムは既存のチケットの同じヘッダー内で同じ値を検索します。

上記のヘッダーに基づいて一致するチケットが見つからない場合、ソフトウェアはメールの件名にLiveAgentのチケットIDが含まれているかどうかを確認します。含まれている場合、そのチケットにメッセージが追加されます。チケットIDの確認も失敗した場合は、新しいチケットが作成されます。

メールメッセージのソースを取得する方法については、こちらの記事をご確認ください。

以下のスクリーンショットの例は、件名が異なる一見無関係な2通のメールが1つのチケットに統合された様子を示しています。ソースコードにアクセスしてヘッダーを確認すると、内容が異なるにもかかわらず、2通目のメールが実際には1通目への返信であることがわかります。これは、1通目のメールのMessage-ID値が、2通目のメールのIn-Reply-ToヘッダーとReferencesヘッダーに記載されているためです。

チケットのステータスに関する考慮事項

メールのソースコードやチケットIDに関わらず、既存のチケットに追加されるべきメールが代わりに新しいチケットを作成する特殊なケースがあります。これは、メッセージが追加されるべきチケットのステータスに関係しています。チケットが「Closed」または「Deleted」ステータスの場合、そのチケットへの返信はすべて新しいチケットを作成します。また、「Configuration」（設定）> 「System」（システム）> 「General」（一般）で「Reopen Resolved Ticket」（解決済みチケットを再オープン）設定がオフになっている場合、「Resolved」ステータスのチケットも同様の動作をします。

メールサーバーによるIDの上書き

まれなケースとして、送信元のメールサーバーがLiveAgentの生成したMessage-IDを上書きしてしまう場合があります。このような場合、顧客の返信にLiveAgentが生成したMessage-ID値が含まれないため、既存のチケットに返信が追加されるのではなく、新しいチケットが作成されてしまいます。この例としてAmazon SES（Simple Email Service）が挙げられ（詳細はこちら）、この動作のため使用はお勧めしません。

この問題は、生成されたMessage-ID値を送信メッセージのReferencesヘッダーに挿入することで回避できます。これにより、Message-ID値が上書きされた場合でも、LiveAgentはReferencesヘッダー内に生成されたIDを見つけ出し、返信受信時にデータベース内でそのIDを検索することができます。クラウドホスト型をご利用のお客様は、サポートにお問い合わせいただき、アカウントへのこの機能の有効化をリクエストしてください。セルフホスト型をご利用のお客様は、“qu_g_settings” データベーステーブルに新しいレコード “mail_references_myself = Y” を追加することで、データベース上でこの機能を有効化できます。