Zendeskメールチャネルの基本|仕組み・受信・送信・トラブル対応を整理

Zendeskのメールチャネルでは、カスタマーから届いたメールをチケットとして管理し、チケットの更新をメール通知として返します。

設定項目は多く見えますが、基本は「受信メールをチケットにする」「ビジネスルールで必要な通知を送る」という流れです。この記事では、Zendesk公式のメールガイド全4パートから、管理者が最初に理解しておきたい点をお伝えします。

設定項目や利用できる機能は、契約プランやアカウントによって異なる場合があります。変更時はZendesk公式情報と実際の管理画面をご確認ください。

メール運用の要点

  • 受信メールはチケットになり、返信は同じチケットの会話として管理される
  • カスタマーやエージェントへのメール通知は、主にトリガと自動化が生成する
  • 外部メールアドレスを使う場合は、転送設定と送信ドメイン認証を分けて確認する
  • 公開コメントはカスタマーへ通知され、内部メモは通知されない
  • メールが届かない場合は、最初にチケットイベントと通知トリガを確認する

1. チケットと通知の仕組み

カスタマーがサポートアドレスへメールを送ると、Zendeskにチケットが作成されます。その後の返信はメールスレッドとして続きますが、Zendesk上では一つのチケットに履歴が集約されます。

メール関連の設定は、管理センターの「チャネル」から「Talkとメール」>「Email」を開いて確認します。この画面から、サポートアドレス、認証済みSMTPコネクタ、メールテンプレートの各設定へ移動できます。

Zendesk管理センターでチャネル内のメール設定を確認している画面

メール通知は大きく二つに分かれます。

  • 受信側の通知:新規リクエスト、担当グループへの割り当て、カスタマーからの返信などをエージェントへ知らせる
  • 送信側の通知:受付完了、エージェントの公開返信、解決通知などをカスタマーへ送る

これらの通知は、主にトリガや自動化の条件とアクションによって生成されます。文面の変更はできますが、デフォルトの通知トリガを目的なく停止すると、受付完了や返信が送られず、会話そのものが途切れる可能性があります。

変更する前に、誰へ、どのチケット更新を、どの条件で通知しているかを確認することが重要です。

2. 受信アドレスとスレッドの判定

Zendeskでは、複数のサポートアドレスを利用できます。製品、窓口、部門ごとにアドレスを分けると、受信したアドレスを条件にして担当グループへ振り分けたり、レポートで集計したりできます。

管理センターのメール設定で「サポートアドレスを管理」を選ぶと、登録済みアドレスの一覧、接続方式、検証状態などを確認できます。

Zendeskのサポートアドレス一覧画面

既存の自社ドメインのメールアドレスを使う場合は、一般的に次の設定が必要です。

  1. Zendeskに外部サポートアドレスを追加し、接続方式を選ぶ
  2. メールサービス側でZendeskへの転送を設定する
  3. Zendeskから自社ドメインとして送信するための認証設定を行う

現在の管理画面では、「外部アドレスを接続する」画面で、メール転送、Microsoft Exchangeコネクタ、Gmailコネクタ、認証済みSMTPコネクタなどから接続方式を選びます。利用中のメールサービスと送受信要件に合う方式を選択してください。

Zendeskで外部サポートアドレスの接続方式を選ぶ画面

受信メールのリクエスタは、原則としてメールヘッダーのReply-To、存在しない場合はFromを基に判定されます。本文に書かれたメールアドレスで自動判定されるわけではありません。

返信を同じチケットへ結び付けるために、Zendeskはメールヘッダー、本文中の非表示情報、返信先アドレスなどに含まれるチケット参照情報を利用します。既存のメールスレッドを別のサポートアドレスへ転送しても、参照情報が残っていれば元のチケットへ追加される場合があります。

あわせて確認したいのが、一時停止中のチケットです。正当な問い合わせがスパム判定される可能性もあるため、受信漏れが疑われる場合は一時停止中のチケットのキューも確認します。

3. 通知本文とメールテンプレート

Zendeskから送るメールには、全体のデザインを決めるメールテンプレートと、トリガや自動化が生成する通知本文があります。

  • メールテンプレート:ヘッダー、フッター、色、HTML・テキスト版など、メール全体の外枠
  • 通知本文:受付完了、公開返信、解決通知など、各ビジネスルールから送る内容

管理センターの「メールテンプレート」では、HTML版とテキスト版の外枠を編集します。画面に表示されている {{content}} には、トリガや自動化が生成した通知本文が差し込まれます。

ZendeskのHTML版とテキスト版のメールテンプレート設定画面

文面にはプレースホルダやLiquidを利用できます。ただし、チケット番号、コメント、リクエスタ情報など、運用に必要な情報を誤って削除しないよう注意が必要です。

送信者名、エージェント名、署名、エイリアスなども調整できます。ブランド表現だけでなく、カスタマーが「誰から、どの問い合わせについて届いたメールか」を判断できることを優先します。

チケット上の公開コメントはカスタマーへのメール通知につながり、社内メモ(内部メモ)は通常カスタマーへ送られません。エージェントワークスペースでは、返信欄の上部に「パブリック返信」と表示されます。送信前にコメント種別を確認し、カスタマーへの連絡開始時期を制御します。

Zendeskの新規チケット画面にあるパブリック返信欄

外部ドメインを使う場合は、SPFに加えてDKIMやDMARCも確認します。これは、Zendeskから送られたメールが正当な送信であることを受信側へ示し、なりすまし判定や迷惑メール振り分けを抑えるための重要な設定です。

4. メール未着の原因の切り分け

メールが届かない場合、すぐにテンプレートやDNSを変更するのではなく、次の順で確認すると原因を絞りやすくなります。

通知トリガは、管理センターの「オブジェクトとルール」>「ビジネスルール」>「トリガ」で確認できます。初期設定の通知トリガには、リクエスト受信時やコメント更新時にリクエスタへメールを送るものがあります。

Zendesk管理センターでメール通知に関係するトリガを確認している画面

  1. チケットイベントに通知アクションが記録されているか
  2. 対象の通知トリガや自動化が有効か
  3. トリガの条件をチケットが満たしているか
  4. カスタマーのユーザープロフィールに正しいメールアドレスがあるか
  5. 受信側の迷惑メールフォルダやフィルタに入っていないか
  6. 外部ドメインのSPF、DKIM、DMARCが適切か

チケットイベントに送信記録がなければ、まずビジネスルールと条件を確認します。送信記録がある場合は、宛先、ドメイン認証、受信側のフィルタへ確認範囲を移します。

また、自動返信システム同士が応答を繰り返すメールループにも注意が必要です。休暇通知、メーリングリスト、別の問い合わせ管理システムなどが関係する場合は、双方の自動返信条件を確認します。

設定・変更時のチェックリスト

  • 使用するサポートアドレスと担当部門を整理する
  • 外部アドレスの転送を、エージェント以外のメールアドレスからテストする
  • 受付完了、公開返信、解決通知が届くか確認する
  • 公開コメントと社内メモ(内部メモ)の通知範囲を確認する
  • デフォルトトリガを変更する前に、現在の役割を記録する
  • チケットイベントから通知処理を追える状態にする
  • 一時停止中のチケットを確認する担当と頻度を決める
  • SPF、DKIM、DMARCをドメイン管理者と確認する

まとめ

Zendeskのメールチャネルを安定して運用するには、メール文面だけでなく、サポートアドレス、チケットのスレッド判定、トリガ、コメント種別、ドメイン認証を一つの流れとして理解する必要があります。

設定変更は一度に広く行わず、受信、チケット化、担当者通知、カスタマー通知、返信の順にテストすると、問題が起きた箇所を判断しやすくなります。

KIRIKOMIでは、Zendeskの設定・運用改善を、実際の受付窓口や担当体制に合わせて整理・実装しています。

新着問い合わせの分類と担当先への振り分けを見直す場合は、AI分類・担当先への振り分け支援をご覧ください。顧客向けの自動返信とは分けて、受付のルールと確認待ちの行き先を設計します。

参考資料

掲載内容は公開時点の情報です。利用できる機能や提供時期は、契約プランやアカウントによって異なる場合があります。

コラム一覧へ