Eメール通知は、Zendeskでの顧客とのコミュニケーションを円滑に進めます。顧客がチケットを送信したり、返信を受け取ったり、解決状況の更新を受け取ったりするとき、トリガーがそれらのEメールを実現します。適切に設定されたトリガーがないと、顧客はリクエストの状況を知ることができず、エージェントは重要な更新を見逃す可能性があります。
ここでは、ZendeskのEメー ルトリガーと通知の仕組み、デフォルトのトリガーの機能、チームのワークフローに合わせたカスタム通知の設定方法について説明します。
ZendeskのEメー ルトリガーと通知とは？
Zendeskでは、トリガーはチケットが作成または更新されるたびに自動的に実行されるビジネスルールです。「もし〜ならば〜」というステートメントと考えてください。特定の条件が満たされた場合、特定のアクションが発生します。最も一般的なアクションの1つは、Eメール通知の送信です。
ZendeskのすべてのEメール通知は、ビジネスルール、主にトリガーと自動化によって生成されます。トリガーは条件が満たされるとすぐに起動しますが、自動化はスケジュールに従って実行されます（たとえば、24時間保留になっているチケットを1時間ごとに確認するなど）。
覚えておくべき重要なことは、アクティブなトリガーがない場合、通知は送信されないということです。Zendeskには、一般的なシナリオを処理するためのデフォルトのトリガーが含まれていますが、それらの仕組み（およびいつカスタマイズするか）を理解することは、顧客の期待を管理するために不可欠です。
トリガーと通知の関係は簡単です。
- 条件は、トリガーが実行されるタイミングを定義します（チケットの作成、優先度の変更、ステータスの更新）。
- アクションは、何が起こるかを定義します（リクエスターにEメールを送信、担当者に通知、チケットフィールドの更新）。
チケットが条件を満たすと、トリガーが起動し、アクションが実行されます。Eメール通知の場合、これはメッセージを作成し、指定された受信者に送信することを意味します。
ZendeskのデフォルトのEメー ルトリガーを理解する
Zendeskには、最も一般的な通知シナリオを処理するために設計されたいくつかのデフォルトのトリガーが付属しています。これらのトリガーはすぐに使用でき、顧客とサポートチーム間の基本的なコミュニケーションニーズをカバーします。
知っておくべき主な通知トリガー：
リクエスト受付の通知は、新しいチケットを送信したときに確認Eメールを顧客に送信します。これにより、メッセージが受信されたことが顧客に通知され、参照用のチケット番号が提供されます。
コメント更新の通知は、エージェントがチケットに公開コメントを追加したときに顧客に警告します。これは、顧客がサポートチームから返信を受け取る主な方法です。
リクエスト解決の通知は、チケットが解決済みとしてマークされたときに顧客に通知します。通常、さらに支援が必要な場合は返信を求めるメッセージが含まれています。
担当者への割り当て通知は、チケットが割り当てられたときにエージェントに警告します。これにより、エージェントは新しい作業がキューに追加されたことを認識します。
コメント更新の担当者への通知は、顧客がチケットに返信したときに割り当てられたエージェントに通知します。これにより、エージェントはキューを常に確認しなくても、顧客の応答を把握できます。
グループへの割り当て通知は、チケットがそのグループに割り当てられたときに、グループのすべてのメンバーに通知を送信します。これは、複数の人が受信チケットを処理するチームベースのワークフローに役立ちます。
各トリガーには、いつ起動するかを決定する特定の条件があります。たとえば、「リクエスト受付の通知」トリガーは通常、チケットが新しく作成され、公開コメント（顧客の最初のメッセージ）があることを確認します。これらの条件が満たされると、トリガーはチケットリクエスターに受信確認のEメールを送信します。
これらのデフォルトのトリガーは、管理センターのオブジェクトとルール > ビジネスルール > トリガーで表示および変更できます。変更する予定がない場合でも、顧客とエージェントがどのような経験をしているかを理解できるように、構成方法を確認する価値があります。
ZendeskでカスタムEメー ルトリガーを作成する方法
デフォルトのトリガーは基本的なシナリオを処理しますが、ほとんどのチームは最終的に特定のワークフロー用のカスタムトリガーを必要とします。VIP顧客がチケットを送信したときにマネージャーに通知したり、チケットのカテゴリに基づいて異なる自動応答を送信したりする必要があるかもしれません。
ここでは、カスタムEメー ルトリガーを最初から作成する方法について説明します。
必要なもの
開始する前に、次のものがあることを確認してください。
- Zendeskアカウントへの管理者アクセス
- 何が通知をトリガーするかについての明確な理解
- 受信者の特定（特定のユーザー、グループ、またはチケットデータに基づく動的な受信者）
ステップ1：トリガーページに移動する
管理センター > オブジェクトとルール > ビジネスルール > トリガーに移動します。これにより、アクティブおよび非アクティブなトリガーを含む現在のトリガーリストが表示されます。
ステップ2：新しいトリガーを作成する
右上のトリガーを追加をクリックします。トリガーに明確でわかりやすい名前を付けます。トリガーが多数ある場合は、適切な命名が重要です。そのため、「VIP通知」ではなく、「VIPチケットのマネージャーに通知」のようにします。
トリガーが何を行い、なぜ存在するのかを説明する意味のある説明を追加します。将来の自分（またはチームメイト）は、トラブルシューティングを行うときに感謝するでしょう。
ステップ3：条件を設定する
条件は、トリガーがいつ起動するかを決定します。「すべて」の条件（すべてが真である必要がある）と「いずれか」の条件（少なくとも1つが真である必要がある）を設定できます。
たとえば、VIP顧客が緊急のチケットを送信したときにマネージャーに通知するには：
すべての条件：
- チケット > 次の場合 > 作成済み
- チケット > 優先度 > 次の場合 > 緊急
- 組織 > タグ > 次のいずれかを含む > vip
ステップ4：アクションを設定する
アクションは、条件が満たされたときに何が起こるかを定義します。Eメール通知の場合、次のいずれかを使用します。
- Eメールユーザー - 特定のユーザーまたは動的な受信者（チケット担当者、リクエスターなど）に送信します。
- Eメールグループ - Zendeskグループのすべてのメンバーに送信します。
Eメールユーザーを選択し、受信者を選択します。件名と本文フィールドでは、{{ticket.id}}、{{ticket.requester.name}}、{{ticket.description}}などのプレースホルダーを使用して、動的なコンテンツを含めることができます。
ステップ5：テストしてアクティブ化する
アクティブ化する前に、プレビュー機能を使用してトリガー条件をテストします。条件に一致するテストチケットを作成し、トリガーが正しく起動することを確認します。
自信がついたら、作成をクリックしてトリガーを保存します。すぐにアクティブになります。
例：優先度エスカレーション通知
チケットが緊急の優先度にエスカレートされたときに、上級サポートチームに通知するとします。設定は次のとおりです。
条件：
- チケット > 優先度 > 次に変更 > 緊急
- チケット > ステータス > 次の場合 > 解決済みではない
アクション：
- Eメールグループ > 上級サポート
- 件名：「緊急：チケット#{{ticket.id}}は至急対応が必要です」
- 本文：チケットの詳細、顧客情報、チケットへのリンクを含めます。
これにより、上級チームはキューを常に監視しなくても、緊急の問題を認識できます。
Eメール通知テンプレートのカスタマイズ
Eメール通知のコンテンツは、グローバルEメールテンプレートとトリガー固有のメッセージ本文の2つの場所から取得されます。
グローバルEメールテンプレート（管理センター > チャネル > Eメール > テンプレートにあります）は、すべての通知のラッパーを提供します。ヘッダー、フッター、スタイルが含まれています。トリガーのEメール本文アクションは、特定のメッセージコンテンツを提供します。
Liquidマークアップの使用
Zendeskは、動的コンテンツにLiquidマークアップをサポートしています。これにより、条件付きロジックとパーソナライズされた情報をEメールに含めることができます。
一般的なプレースホルダーは次のとおりです。
{{ticket.requester.name}}- 顧客の名前{{ticket.id}}- チケット番号{{ticket.description}}- チケットの内容{{ticket.url}}- チケットへのリンク{{ticket.assignee.name}}- 割り当てられたエージェントの名前
条件付きも使用できます。
{% if ticket.priority == 'urgent' %}
これは緊急のリクエストであり、すぐに対応されます。
{% endif %}
HTMLカスタマイズの基本
トリガーEメール本文の場合、HTMLを使用してメッセージをフォーマットできます。Eメールクライアントの互換性を最大限に高めるために、シンプルに保ちます。
- インラインCSSを使用します（スタイルブロックではありません）。
<p>、<strong>、<a>、<br>などの基本的なHTML要素を使用します。- 展開する前に、複数のEメールクライアントでテストします。
- 画像の使用は最小限に抑えます（多くのEメールクライアントはデフォルトで画像をブロックします）。
Eメールのフォーマットに関するベストプラクティス
- 件名は明確にし、60文字未満にします。
- 最も重要な情報を上部に配置します。
- 明確な行動喚起を含めます（このEメールに返信、オンラインでチケットを表示など）。
- モバイルデバイスでEメールをテストします（多くの顧客は携帯電話でサポートEメールを読みます）。
トリガーを整理するためのベストプラクティス
Zendeskの設定が拡大するにつれて、トリガーの整理が重要になります。トリガーリストが乱雑になると、ルールが競合したり、通知が見逃されたり、デバッグが困難になったりします。
1つのトリガーは1つのジョブを実行する
経験豊富なZendeskコンサルタントは、「1つのトリガーは1つのジョブを実行する」という考え方を推奨しています。優先度を設定し、グループに割り当て、通知を送信する単一のトリガーを作成する代わりに、3つの個別のトリガーを作成します。
- 条件に基づいて優先度を設定するもの
- 優先度に基づいて適切なグループに割り当てるもの
- 割り当てが完了した後に通知を送信するもの
これにより、トラブルシューティングが容易になります。何かがうまくいかない場合は、どの特定のトリガーが問題の原因となっているかを特定できます。
トリガーの順序が重要
Zendeskは、トリガーを上から下に処理します。一致するトリガーはすべて起動し、最初のトリガーだけではありません。これは、順序が結果に影響を与える可能性があることを意味します。
デフォルトを設定し、チケットを分類するトリガーをリストの早い段階に配置します。すべてのチケットプロパティが設定された後、通知トリガーを最後に配置します。これにより、通知に正しい、完全に更新された情報が含まれるようになります。
推奨される組織構造
トリガーをカテゴリに整理することを検討してください。
- デフォルトの設定 - ブランド、優先度、タイプ、スケジュール
- 分類 - カテゴリ、カスタムフィールド、タグの設定
- エンリッチ - フォロワーの追加、ユーザーデータの更新
- ルーティングと割り当て - グループへの割り当て、ステータスの設定
- 通知 - Eメールの送信（すべてのコンテキストが設定された後のみ）
Zendeskのトリガーカテゴリ機能を使用して、関連するトリガーを視覚的にグループ化します。これにより、トリガーリストのナビゲーションとメンテナンスが容易になります。
命名規則
明確な名前は時間を節約します。トリガーが何を行うかを説明するわかりやすい名前を使用します。
- ✅ 「リクエスターへの通知 - ブランドA - コメントの更新」
- ❌ 「ブランドAトリガー」
可能な場合は、アクションと条件を名前に含めます。これにより、リストを確認したり、トラブルシューティングを行ったりするときに、トリガーをすばやく識別できます。
設定を文書化する
トリガー構造を説明する内部ドキュメントを作成します。含めるもの：
- どのトリガーがどのシナリオを処理するか
- トリガーの順序付けの背後にあるロジック
- 一般的なトラブルシューティングの手順
- 何かが壊れた場合に連絡する人
これは、複数の管理者がZendeskアカウントを管理している場合に特に重要です。
一般的な問題とトラブルシューティング
慎重に設定しても、トリガーの問題は発生します。最も一般的な問題とその解決方法を次に示します。
トリガーが起動しない
トリガーが期待どおりに起動しない場合は：
- トリガーがアクティブであることを確認します（ドラフトモードではない）。
- 条件が正確に一致することを確認します（タグとテキストでは大文字と小文字が区別されます）。
- トリガーの順序を確認します。別のトリガーが変更を加えて、このトリガーが一致しないようにしている可能性があります。
- チケットイベントログを確認して、実際にどのトリガーが起動したかを確認します。
重複した通知
顧客が同じ更新に対して複数のEメールを受信する場合、通常は複数の通知トリガーが起動していることを意味します。これを防ぐには：
- 無効化条件を使用します（タグが存在しないことを確認し、アクションでそのタグを追加するなど）。
- トリガーの順序を確認します。特定のトリガーを一般的なトリガーの前に配置します。
- トリガー間の重複する条件を確認します。
Eメールのフォーマットの問題
特定のクライアントでEメールが正しく表示されない場合：
- 複数のEメールクライアント（Gmail、Outlook、Apple Mail）でテストします。
- 複雑なフォーマットにはテーブルベースのレイアウトを使用します（古い方法ですが信頼性があります）。
- CSSショートハンドを避け、インラインスタイルを使用します。
- 画像の幅を600px未満に保ちます。
Guideの通知の制限
知っておくべき重要な制限の1つ：Zendesk Guide（ヘルプセンター）の通知は、トリガーベースのブランディングを尊重しません。記事のコメント通知、サブスクリプションEメール、コミュニティ投稿は、グローバルEメールテンプレートのみを使用します。これは、マルチブランド設定に影響を与える既知の制限です。
回避策としては、グローバルテンプレートをニュートラルに保つか、Guideの通知がチケット通知と完全に一致しないことを受け入れることが挙げられます。
テスト戦略
トリガーを本番環境に展開する前に：
- 各シナリオのテストチケットを作成します。
- チケットイベントログを確認して、正しいトリガーが起動したことを確認します。
- 実際のテストEメールを送信し、さまざまなクライアントで確認します。
- 同僚に顧客としてロールプレイングしてもらい、問題を見つけます。
- 広範囲に展開する前に、少数の実際のチケットから開始します。
AIによる通知の合理化
マルチブランドまたはマルチチーム環境向けの複雑なトリガー設定を管理すると、圧倒される可能性があります。各ブランドには独自の通知トリガーセットが必要になる場合があり、多数のトリガー全体で一貫性を維持するには、多大な労力がかかります。
ここで、AI（人工知能）搭載のサポートツールが役立ちます。ブランド固有のメッセージングを処理するための複雑なトリガーチェーンを構築する代わりに、受信チケットを分析して、適切な応答を自動的に生成できます。
私はZendeskと直接統合し、通知を異なる方法で処理します。
- 自動ブランド検出 - Eメールアドレス、チケットフィールド、またはリクエストコンテンツに基づいて、顧客がどのブランドに連絡したかを識別します。
- ブランドに適した応答 - トリガーでHTMLテンプレートをハードコーディングする代わりに、各ブランドの声と要件に一致する応答を生成します。
- トリガーのメンテナンス不要 - 複数のトリガーを複製してカスタマイズするのではなく、新しいブランドについて私に伝えるだけで追加できます。
- チャネル全体で一貫性 - 顧客がEメール、チャット、またはヘルプセンターを使用するかどうかにかかわらず、私は適切なブランドの声を守ります。
複数のブランドまたは複雑な通知要件を管理するチームにとって、このアプローチは、一貫性を向上させながら、メンテナンスのオーバーヘッドを大幅に削減できます。
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.
