Zendeskの通知が送信されない場合の修正方法：完全なトラブルシューティングガイド

顧客に通知が届いていないことに気づいたときのパニックに勝るものはありません。 チケットに対応し、解決済みにマークを付けたのに... 静寂。 確認メールも、更新もありません。 ただ、自分のメッセージが虚空に消えてしまったのではないかと心配している顧客がいるだけです。

Zendesk の通知が機能しなくなると、その影響はすぐに現れます。 顧客は不満を感じ、エージェントは更新を見逃し、サポートワークフローが崩壊します。 幸いなことに、ほとんどの通知の問題は予測可能なパターンに従っており、髪の毛をむしり取ることなく体系的に修正できます。

このガイドでは、根本原因を見つけて修正するための診断アプローチについて説明します。 通知の失敗の3つの主要なカテゴリ（トリガー、メールの配信性、エージェントの設定）について、それぞれの手順を説明します。 また、顧客を実際に支援するよりもトリガーの管理に多くの時間を費やしていることに気づいた場合は、eesel AI での通知へのアプローチの違いについても触れます。

Zendeskの通知が失敗する原因

修正に入る前に、Zendesk で通知が実際にどのように機能するかを理解しましょう。 すべてのメール通知は、トリガーがチケットイベントを検出し、トリガーがアクションを起動し、そのアクションがメールを送信するというパスをたどります。 このチェーンのいずれかのリンクが切れると、通知は失敗します。

どこから調べ始めるかについての簡単な意思決定フレームワークを次に示します。

• トリガーの問題 通知が突然停止した場合、または特定のチケットタイプにのみ影響する場合は、まずこれを確認してください
• メールの配信性 一部の顧客はメールを受信するが、他の顧客は受信しない場合、またはバウンスメッセージが表示される場合は、これを確認してください
• エージェントの設定 特定のエージェントのみが通知を受信していない場合は、これを確認してください

カテゴリ別に分類してみましょう。

ステップ1：Zendeskの通知が送信されない場合のトリガー構成を確認する

トリガーは、Zendesk のすべての通知の背後にあるエンジンです。 トリガーが壊れると、すべてが停止します。 トリガーの問題を診断する方法を次に示します。

トリガーがアクティブであることを確認する

まず、通知トリガーが実際にオンになっているかどうかを確認します。 [管理センター（Admin Center）] > [オブジェクトとルール（Objects and rules）] > [ビジネスルール（Business rules）] > [トリガー（Triggers）] に移動し、通知を処理するデフォルトのトリガーを探します。

• 受信したリクエストのリクエスタに通知
• コメントの更新をリクエスタに通知
• 解決済みのリクエストをリクエスタに通知

これらのいずれかが非アクティブとして表示されている場合は、それが問題です。 チェックボックスを選択し、[アクティブ化（Activate）] をクリックします。

トリガーの条件とアクションを確認する

アクティブなトリガーでも、条件またはアクションが間違っていると失敗する可能性があります。 各通知トリガーをクリックして、以下を確認します。

条件には以下を含める必要があります。

• チケットステータスの確認（作成済み、更新済み、解決済み）
• コメントの表示（公開コメントは顧客通知をトリガーします）
• ワークフローに必要なカスタム条件

アクションには以下を含める必要があります。

• 顧客通知の場合は [メールユーザー（Email user）] > [（リクエスタ）（(requester)）]
• エージェント通知の場合は [担当者にメール（Email assignee）]
• チーム通知の場合は [グループにメール（Email group）]

一般的な間違いは、デフォルトの「コメントの更新を担当者に通知」トリガーを編集し、誤ってメールアクションを削除することです。 トリガーが起動してもメールアクションが含まれていない場合、何も送信されません。

チケットイベントを使用して診断する

チケットイベントログには、チケットが更新されたときに何が起こったか（または起こらなかったか）が正確に表示されます。 アクセスするには、影響を受けるチケットを開き、URLの末尾に /events を追加します。

以下を探します。

• チケットの更新でどのトリガーが起動したか
• メール通知アクションがトリガーされたかどうか
• エラーメッセージまたは警告

イベントログにトリガーが表示されているが、メールが送信されなかった場合は、問題は Zendesk の外部にある可能性があります（メールの配信性）。 トリガーがまったく表示されない場合は、トリガーの条件を確認してください。

ステップ2：メールの配信性の設定を確認する

トリガーが機能しているのにメールが届かない場合、通常、問題はメールの配信性です。 ここからが技術的な部分になりますが、修正は簡単です。

SPFレコードを確認する

SPF（Sender Policy Framework） は、どのサーバーがドメインの代わりにメールを送信できるかをメールプロバイダーに伝えます。 適切な SPF 構成がないと、Zendesk からのメールはスパムとしてフラグが立てられるか、完全に拒否されることがよくあります。

ドメインの SPF レコードには、以下を含める必要があります。

現在の SPF レコードを確認するには：

1. [管理センター（Admin Center）] > [チャネル（Channels）] > [メール（Email）] に移動します
2. サポートメールアドレスの横にある SPF チェックステータスを探します
3. エラーが表示された場合は、DNS レコードを更新する必要があります

完全な SPF レコードは次のようになります。

Zendesk の include が見つからない場合は、ドメイン管理者に連絡して追加してもらいます。 ドメインごとに SPF レコードは1つしか存在できないため、新しいレコードを作成するのではなく、既存のレコードを変更する必要があります。

一般的なエラーコードを理解する

メールの配信が失敗すると、Zendesk はチケットインターフェイスにエラーコードを表示します。 最も一般的なものを次に示します。

チケットの受信者の名前の横にある警告アイコンをクリックして、特定のエラーメッセージを表示します。

保留中のチケットを確認する

メールがチケットを作成する前に、Zendesk のスパムフィルターに引っかかることがあります。 [保留中のチケット（Suspended tickets）] ビュー（左側のサイドバーの [ビュー（Views）] の下）で、誤ってフラグが立てられた正当なメッセージを確認します。

正当なメールが保留されている場合は、フィルターをトレーニングするために復元します。 システムがその送信者からのメールを許可するように学習する前に、いくつか復元する必要がある場合があります。

ステップ3：エージェントの通知設定を確認する

エージェントの通知の問題は、顧客の通知の問題とは異なります。 トラブルシューティングの方法を次に示します。

個々のエージェントの設定を確認する

各エージェントは、独自の通知設定を制御します。 あるエージェントが通知を受信していないのに、他のエージェントが受信している場合は、そのプロファイルを確認します。

1. [管理センター（Admin Center）] > [ユーザー（People）] > [チームメンバー（Team members）] に移動します
2. 影響を受けるエージェントの名前をクリックします
3. [連絡先情報（Contact info）] セクションと [設定（Preferences）] セクションを確認します

以下を確認してください。

• メールアドレスが正しい
• メール通知が有効になっている
• 通知タイプから登録解除していない

グループ割り当て通知を確認する

エージェントがグループに割り当てられたチケットに関する通知を受信していない場合は、[割り当てをグループに通知（Notify group of assignment）] トリガーがアクティブであることを確認します。 このトリガーは、チケットがそのグループに割り当てられると、すべてのグループメンバーに通知を送信します。

一部のチームは、メールのノイズを減らすためにグループ通知を無効にすることを好みます。 それが設定である場合は、代わりにエージェントがビューを定期的に確認することを知っていることを確認してください。

エージェントと顧客の通知の違い

エージェントと顧客の通知は異なるトリガーを使用することに注意してください。

• 顧客通知 は「リクエスタに通知」トリガーを使用します
• エージェント通知 は「担当者に通知」または「グループに通知」トリガーを使用します

顧客がメールを受信しているのにエージェントが受信していない場合（またはその逆の場合）、失敗している特定のトリガーカテゴリに焦点を当てます。

ステップ4：修正をテストして確認する

変更を加えたら、すべてが機能すると想定する前にテストします。

テストチケットを作成する

最も簡単なテストは、チケットを作成し、通常のワークフローを実行することです。

1. 顧客としてテストチケットを送信します
2. 確認メールが届くことを確認します
3. エージェントとして公開コメントを追加します
4. 顧客が更新を受信することを確認します
5. チケットを解決します
6. 解決通知が送信されることを確認します

テスト顧客には、顧客に表示される内容を正確に確認できるように、個人のメールアドレス（職場のメールアドレスではない）を使用します。

チケットイベントを使用して確認する

各テストの後、チケットイベントログを確認して、以下を確認します。

• 正しいトリガーが起動した
• メール通知が送信された
• エラーメッセージが表示されなかった

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

トリガーがアクティブで、SPF が正しく構成されており、エージェントが正しい設定を持っていることを確認したが、通知がまだ機能しない場合は、Zendeskサポート に連絡してください。 管理パネルに表示されないサーバー側の問題を調査できます。

Zendeskの通知が送信されない場合の予防のベストプラクティス

通知を修正することは良いことです。 通知が壊れないようにすることはさらに良いことです。 次に、役立つ習慣を示します。

• トリガーを四半期ごとに監査する 数か月ごとにトリガーリストを確認して、非アクティブ化されたトリガーまたは競合するトリガーをキャッチします
• 設定を文書化する 特にカスタムトリガーがある場合は、どのトリガーがどの通知を処理するかを説明する内部ドキュメントを保持します
• 保留中のチケットビューを監視する 週に1回確認して、フラグが立てられている正当なメールをキャッチします
• 大幅な変更後にテストする トリガー、メール設定、または DNS レコードを変更するたびに、通知テストスイートを実行します

AIで通知を合理化する

Zendesk のトリガーは機能しますが、常にメンテナンスが必要です。 新しいブランド、チーム、またはワークフローごとに、作成および管理するトリガーが増えます。 しばらくすると、顧客を実際に支援するよりも、トリガーの競合をデバッグするのに多くの時間を費やすことになります。

eesel AI では、別のアプローチを採用しています。 複雑なトリガーチェーンを構築する代わりに、AI チームメイトがビジネスを学習し、通知をインテリジェントに処理します。

• 自動ブランド検出 顧客がメール、チケットフィールド、またはメッセージコンテンツに基づいて連絡したブランドを特定します
• チャネル全体で一貫したボイス 顧客がメール、チャット、またはヘルプセンターを使用するかどうかにかかわらず、応答は自動的にブランドと一致します
• トリガーのメンテナンス不要 複数のトリガーを複製してカスタマイズするのではなく、新しいブランドについて教えていただくだけで追加できます

トリガーのトラブルシューティングにうんざりしていて、AI がサポートワークフローをどのように簡素化できるかを知りたい場合は、Zendesk向けeesel AIの統合ページでその仕組みを確認するか、eesel AI を無料で試してください。