Zendeskのメールチケットリクエスタ通知を設定する方法：完全ガイド

メール通知を正しく設定することは、簡単そうに見えて実はそうではないことの1つです。顧客は、あなたがチケットに返信したり、チケットが解決されたりしたときに自動的に知ると思うかもしれません。しかし、Zendeskでは、トリガーが正しく設定されている場合にのみ、それが起こります。

このガイドでは、Zendeskのメールチケットリクエスタ通知について知っておくべきことをすべて説明します。システムの仕組み、通知の設定とカスタマイズの方法、問題が発生した場合の対処法について説明します。

開始するために必要なもの

トリガーの設定に入る前に、次のものがあることを確認してください。

• Zendesk Supportアカウント（Teamプラン以上）
• 管理者権限、またはロールでトリガーを管理する機能
• サポートプロセスにおけるチケットの流れに関する基本的な知識
• オプション：ブランド通知が必要な場合は、カスタムメールテンプレート

管理者でない場合は、管理者権限を持つ人と連携する必要があります。トリガーの管理には、通常の担当者にはデフォルトで与えられていない特定の権限が必要です。

Zendeskのメール通知の仕組みを理解する

短いバージョンは次のとおりです。Zendeskのすべてのメール通知は、ビジネスルールから送信されます。例外はありません。

ビジネスルールは、次の2つのタイプに分かれています。

• トリガーは、チケットが作成または更新されたときにすぐに実行されます
• 自動化は、スケジュールに従って実行されます（通常は時間ベースで、「チケット作成後4時間」など）

リクエスタ通知の場合、主にトリガーを使用します。これらは、チケットに何かが起こるとすぐに起動し、すぐに顧客にメールを送信します。

リクエスタに通知するデフォルトのトリガー

Zendeskには、顧客に通知するために事前に設定されたいくつかのトリガーが付属しています。

トリガー	起動するタイミング	実行する内容
受信したリクエストのリクエスタとCCに通知する	エンドユーザーによって新しいチケットが作成された	リクエストが受信されたことを確認する確認メールを送信します
コメント更新のリクエスタとCCに通知する	公開コメントがチケットに追加された	担当者の返信または顧客自身の返信を顧客に通知します
新しいプロアクティブチケットのリクエスタに通知する	担当者が顧客に代わってチケットを作成する	顧客にチケットが作成されたことを通知します

これらのトリガーが無効になっているか、正しく変更されていない場合、顧客はメールを受信しません。それはとても簡単です。

Zendeskが誰が誰であるかを識別する方法

メールがZendeskに入ってくると、システムは誰が送信したかを推測しません。特定のメールヘッダーを確認します。

1. まず、reply-to:ヘッダーを確認します
2. それが存在しない場合は、from:ヘッダーを使用します
3. メール本文は、リクエスタを識別するために使用されることはありません

これは重要です。誰かがメールをサポートアドレスに転送した場合、ヘッダーが保持されない限り、Zendeskはチケットを元の送信者ではなく転送者に割り当てる可能性があるためです。

ステップ1：デフォルトのトリガーにアクセスして確認する

まず、現在設定されている内容を確認しましょう。

管理センター > オブジェクトとルール > ビジネスルール > トリガーに移動します。アカウント内のすべてのトリガーのリストが表示されます。これには、Zendeskが提供する標準のトリガーも含まれます。

次の特定のトリガーを探します。

• 受信したリクエストのリクエスタとCCに通知する これは、「メールを受け取りました」という自動返信を送信します
• コメント更新のリクエスタとCCに通知する これは、担当者が返信したとき、または顧客が公開コメントを追加したときに更新を送信します
• 新しいプロアクティブチケットのリクエスタに通知する これは、顧客に代わってチケットを作成したときに顧客に通知します

変更を加える前に、これらのトリガーがアクティブであることを確認してください。トリガーがアクティブでない場合、どれだけ完璧に設定されていても起動しません。各トリガー名の横に「アクティブ」または「非アクティブ」のラベルが表示されます。

**ベストプラクティス：**標準のトリガーを変更する場合は、最初にそれを複製し、元のトリガーを非アクティブにします。これにより、何か問題が発生した場合にバックアップが得られます。

ステップ2：リクエスタ通知メールをカスタマイズする

トリガーが見つかったので、実際に送信する内容を見てみましょう。

トリガーをクリックして編集します。条件（いつ実行されるか）とアクション（何を実行するか）の2つの主要なセクションが表示されます。メール通知は、アクションセクションにあります。

動的コンテンツにプレースホルダーを使用する

プレースホルダーを使用すると、チケット固有の情報をメールに挿入できます。リクエスタ通知に最も役立つプレースホルダーを次に示します。

プレースホルダー	挿入するもの	使用例
{{ticket.id}}	チケット番号	「リクエスト#{{ticket.id}}を受信しました」
{{ticket.requester.name}}	顧客の名前	「こんにちは{{ticket.requester.name}}様」
{{ticket.comments_formatted}}	コメントテキスト	担当者が書いた内容を表示します
{{ticket.title}}	チケットの件名	問題の内容を参照します
{{ticket.status}}	現在のステータス	「チケットは現在{{ticket.status}}です」

通知メールのベストプラクティス

通知メールを簡潔で役立つものに保ちます。

• **件名：**チケットIDと簡単なステータスを含めます。例：「リクエスト#{{ticket.id}}の更新」
• **冒頭：**顧客の名前がわかっている場合は使用します
• **本文：**顧客がログインしなくても応答を確認できるように、コメントテキストを含めます
• **結び：**サポート時間またはヘルプセンターへのリンクを追加します

重要：プレースホルダー抑制ルール

Zendeskは、セキュリティ上の理由から、特定の状況で特定のプレースホルダーを抑制します。たとえば、チケットがメールで作成された場合、最初の通知にコメントプレースホルダーが表示されない場合があります。メールに期待されるコンテンツが表示されない場合は、プレースホルダーの抑制に関するZendeskのドキュメントを確認してください。

ステップ3：解決済みチケット通知を設定する

デフォルトでは、Zendeskはチケットを解決したときに顧客に通知しません。担当者の最後のコメントで解決策がすでに説明されていると考えているためです。しかし、多くのチームは、明確な「チケットが解決されました」という通知を送信したいと考えています。

作成方法は次のとおりです。

1. 管理センター > オブジェクトとルール > ビジネスルール > トリガーに移動します

2. トリガーを追加をクリックします

3. 次の条件を設定します。

   • オブジェクト > チケット > ステータスカテゴリ | 次のように変更 | 解決済み
   • オブジェクト > チケット > コメント | 次の場合 | 公開
   • チケットの詳細 > 現在のユーザー | 次の場合 | （担当者）

4. 次のアクションを設定します。

   • その他 > 通知方法 > ユーザーメール | オブジェクト > チケット > （リクエスタ）
   • カスタムの件名とメッセージを追加します

重複するメールの回避

解決済みの通知を作成する場合は、「コメント更新」トリガーも起動しないようにする必要があります。そうしないと、顧客はコメントと解決済みのステータスの2つのメールを受信します。

コメント更新のリクエスタとCCに通知するトリガーを編集し、次の条件を追加します。

• オブジェクト > チケット > チケットステータス | 次のように変更されない | 解決済み

これにより、コメントトリガーが解決済みのチケットをスキップし、代わりに新しい解決済みの通知で処理できるようになります。

ステップ4：プロアクティブチケット通知を設定する

顧客に代わってチケットを作成する必要がある場合があります。電話がかかってきたか、影響を与える問題が特定された可能性があります。これらはプロアクティブチケットと呼ばれます。

プロアクティブチケットを作成する場合：

• 公開の場合、顧客は通知を受け取ります（「新しいプロアクティブチケットのリクエスタに通知する」トリガーを介して）
• プライベートの場合、公開コメントを追加するまで顧客に通知されません

公開プロアクティブチケットを作成するには：

1. +追加タブをクリックし、チケットを選択します
2. 公開返信が選択されていることを確認します（内部メモではありません）
3. リクエスタフィールドにリクエスタを追加します
4. チケットの詳細を入力して送信します

トリガーがアクティブな場合、リクエスタは新しいチケット通知を受信します。

一般的な通知の問題のトラブルシューティング

完璧な構成でも、問題が発生する場合があります。最も一般的な問題を診断して修正する方法を次に示します。

問題：顧客がメールを受信しない

**トリガーがアクティブかどうかを確認します。**トリガーリストに移動し、ステータスを確認します。非アクティブなトリガーは、通知が欠落している最大の原因です。

**トリガー条件を確認します。**誰かがトリガー条件を変更した場合、ロジックが壊れている可能性があります。Zendeskの標準トリガードキュメントのデフォルト条件と比較してください。

**チケットイベントを確認します。**通知が送信されるはずだったチケットを開きます。イベントタブをクリックし、通知エントリを探します。「通知が送信されました」と表示されているのに顧客が受信しなかった場合、問題はダウンストリーム（スパムフィルター、メール配信など）にあります。

問題：メールがスパムになる

**SPFレコード。**外部メールアドレス（@yoursubdomain.zendesk.comではない）を使用している場合は、SPFレコードをDNSに追加する必要があります。これにより、Zendeskがあなたに代わってメールを送信することを承認されていることをメールプロバイダーに伝えます。そうしないと、メールがスパムとしてフラグ付けされる可能性が高くなります。

**メールコンテンツ。**通知テンプレートでスパムのような言葉遣いを避けてください。「緊急」、「無料」、または過度の句読点などの単語は、スパムフィルターをトリガーする可能性があります。

問題：プライベートコメントが通知を抑制する

担当者がチケットに内部メモ（プライベートコメント）を追加すると、「メールユーザー」アクションは自動的に抑制されます。公開コメントのみがリクエスタへの通知をトリガーします。

これは仕様ですが、人々を混乱させます。顧客に通知する必要がある場合は、内部メモではなく公開返信を追加していることを確認してください。

Zendeskサポートに連絡するタイミング

トリガーが正しいことを確認し、メールがまだ受信されていない場合は、Zendeskでチケットを開く時間です。サーバーログを確認し、管理インターフェースに表示されない配信の問題を特定できます。

リクエスタ通知の高度なヒント

基本をマスターしたら、次の拡張機能を検討してください。

外部メールターゲット

特別なシナリオでは、チケットリクエスタではないメールアドレスに通知できます。これは、次の場合に役立ちます。

• 緊急チケットが作成されたときにマネージャーに警告する
• メール統合を介してSlackチャネルに通知する
• 外部監視システムにアラートを送信する

これらは、管理センター > アプリと統合 > ターゲットで設定します。

CCとフォロワーの動作

チケットで誰かをCCすると、リクエスタと同じ通知を受信します。フォロワー（同様の機能）もチケットの更新に関する通知を受け取ります。複数の人をチケットに追加する場合は、メールノイズが発生する可能性があるため、注意してください。

多言語サポート

複数の言語で顧客をサポートする場合は、通知トリガーの言語固有のバージョンを作成できます。チケット > リクエスタ > 言語条件を使用して、顧客の言語設定に基づいて異なるメールテンプレートを送信します。

トリガーのテスト

ワークフロー全体にトリガーの変更を展開する前に、テストします。

1. テストチケットを作成します
2. 通知をトリガーするはずのアクションを実行します
3. メールが送信されたかどうかを確認します（[イベント]タブから）
4. 実際のメールコンテンツを確認します

顧客が実際に受信する内容を確認できるように、個人のメールアドレスでテストエンドユーザーアカウントを作成することを検討してください。

AIチームメイトで通知を合理化する

Zendeskのメール通知を設定するには、トリガー、条件、アクション、プレースホルダーを理解する必要があります。強力ですが複雑です。新しい通知ワークフローごとに、管理するトリガーが増え、テストする条件が増え、潜在的な障害点が増えます。

通知ロジックの管理に時間を費やしすぎている場合は、実際には顧客を支援するよりも、別のアプローチがあります。

eesel AIでは、顧客とのコミュニケーションを異なる方法で処理します。複雑なトリガーツリーを構築する代わりに、eeselをAIチームメイトとしてチームに招待します。仕組みは次のとおりです。

• トリガー構成は不要です。 eeselは、過去のチケット、マクロ、ヘルプセンターから自動的に学習します。条件を1つも記述しなくても、顧客といつ、どのようにコミュニケーションをとるかを理解します。

• わかりやすい英語の指示。 VIP顧客に異なる方法で通知したいですか？「エンタープライズ顧客の場合は、常にアカウントマネージャーをCCに追加してください」と指示するだけです。ドロップダウンメニューも条件ビルダーもありません。

• **ライブになる前にテストします。**過去の数千件のチケットでeeselを実行して、どのように応答するかを正確に確認します。顧客がメッセージを見る前に品質を確認してください。

• **段階的なロールアウト。**まず、eeselが担当者レビュー用の返信を下書きすることから始めます。自信がついたら、直接応答を送信させます。ペースを制御できます。

Zendeskの通知の複雑さに苦労しているチームにとって、eeselはより簡単な道を提供します。AIを構成するのではなく、AIを雇い、知識をトレーニングし、コミュニケーションパターンを学習させます。

AIチームメイトがサポートワークフローをどのように変革できるかを見てみませんか？eeselを無料で試すか、デモを予約するして、実際に動作を確認してください。