Zendeskトリガーアクションを使用してユーザーグループに通知する方法

サポートチケットは、見過ごされがちです。顧客が緊急のリクエストを送信し、それがあなたのZendesk（ゼンデスク）のキューに届き、その後...沈黙。チームの誰も、誰かが自分のビューをチェックするまで、そこにチケットがあることを知りません。その時までに、あなたの応答時間のメトリクスは打撃を受け、顧客はすでに不満を抱いています。

ここで、Zendeskのトリガーアクションを使用してユーザーグループに通知することが役立ちます。トリガーは、特定の条件が満たされたときに発動する自動化されたビジネスルールです。新しいチケットをキャッチし、適切な人にすぐに通知して、何も見逃さないようにする安全ネットと考えてください。

このガイドでは、新しいチケットが届いたときにグループに通知するZendeskトリガーの設定について説明します。デフォルトの「割り当てられたグループに通知」トリガー、ワークフローに合わせてカスタマイズする方法、および避けるべき一般的な落とし穴について説明します。また、チームが実際のチケットパターンから学習するAI（人工知能）搭載のルーティングに移行し、厳格なトリガーロジックを超えていく方法についても共有します。

開始する前に必要なもの

始める前に、次のものが揃っていることを確認してください。

• Teamプラン以上のZendesk Supportアカウント（トリガーはすべての有料プランで利用可能）
• トリガーを作成および変更するための管理者アクセス
• Zendeskで既に設定されているグループ（管理センター > ユーザー > グループ）
• チケットがチーム内でどのように流れるべきかの明確な理解

まだグループを設定していない場合は、最初にそれを行ってください。グループは、トリガーベースの通知の基礎です。グループがなければ、通知する相手がいません。

トリガーの設定が扱いにくくなっている場合は、別の方法があります。当社では、履歴チケットからルーティングパターンを学習するAI搭載の代替手段を提供しており、複雑な条件チェーンの必要性を排除します。ただし、まずは基本から始めましょう。

Zendeskトリガーアクション通知ユーザーグループ機能について

基本から始めましょう。Zendeskのトリガーは、条件とアクションのセットです。チケットがすべての条件を満たすと、トリガーが発動し、アクションを実行します。これは単純なif-thenロジックです。チケットが作成され、請求グループに割り当てられた場合、そのグループの全員にメールを送信します。

グループは、機能別に編成されたエージェントの集まりです。一般的な問い合わせのためのサポートグループ、支払い問題のための請求グループ、バグや機能リクエストのためのテクニカルグループがあるかもしれません。チケットが届くと、Zendeskはトリガーに基づいて適切なグループにルーティングします。

Zendeskには、すべてのアカウントにあらかじめ設定された標準トリガーのセットが付属しています。これらの1つが「割り当てられたグループに通知」トリガーです。これは、チケットがグループに割り当てられたが、まだ個々のエージェントに割り当てられていない場合に発動します。これが私たちが取り組むトリガーです。

デフォルトのトリガーとカスタムトリガーの主な違いは、制御です。デフォルトのトリガーは、すべての人に合うように設計されたソリューションです。カスタムトリガーを使用すると、「チケットが緊急の場合のみ通知する」または「週末に請求グループに通知しない」などの条件を追加できます。

ステップバイステップ：基本的なグループ通知トリガーの設定

ステップ1：トリガー管理ページにアクセスする

開始するには、Zendeskの管理センターでトリガーセクションに移動する必要があります。

1. 左側のサイドバーにある歯車アイコンをクリックして、管理センターを開きます。
2. サイドバーメニューのオブジェクトとルールを展開します。
3. ビジネスルール > トリガーを選択します。
4. チケットタブをクリックして、すべてのチケットトリガーを表示します。

アカウント内のすべてのトリガーのリストが表示されます。これには、あらかじめ設定されていた標準トリガーも含まれます。トリガーは、このリストに表示される順に、上から下に実行されます。トリガーの順序は重要です。あるトリガーがチケットを変更し、別のトリガーが発動する原因となる可能性があるためです。

ステップ2：新しいトリガーを作成する（または既存のトリガーを複製する）

トリガーリストをスクロールして、「割り当てられたグループに通知」を見つけます。これは、すべてのZendeskアカウントに付属する標準トリガーの1つです。それをクリックして、現在の設定を表示します。

条件とアクションの2つの主要なセクションが表示されます。条件は、トリガーがいつ発動するかを決定します。アクションは、トリガーが発動したときに何が起こるかを決定します。

デフォルトの条件は次のとおりです。

• チケット > グループ：「-」ではない（チケットにグループが割り当てられている）
• チケット > 担当者：「-」（個々のエージェントはまだ割り当てられていない）
• および次のいずれか：チケット > グループ：変更済み OR チケット > 担当者：変更済み

これは、チケットがグループに割り当てられたが、まだ特定の担当者に割り当てられていない場合にトリガーが発動することを意味します。「変更済み」条件は、新しいチケットがグループ割り当てで作成された場合と、既存のチケットが再割り当てされた場合の両方で発動することを保証します。

**ベストプラクティス：**デフォルトのトリガーを直接編集しないでください。代わりに、それを複製してコピーを変更します。これにより、何か問題が発生した場合にフォールバックできます。複製するには、トリガー名の横にある3つのドットをクリックし、「複製」を選択します。Zendeskトリガーの仕組みの詳細はこちら。

ステップ3：トリガー条件を設定する

次に、特定のワークフローに合わせて条件をカスタマイズする方法を見てみましょう。

次のすべての条件を満たす

トリガーが発動するには、これらの条件がすべてtrueである必要があります。

• チケット > グループ：「-」ではない - これにより、チケットに実際にグループが割り当てられていることが保証されます。「-」の値は、未割り当てを意味します。
• チケット > 担当者：「-」 - これにより、個々のエージェントがまだチケットを要求していないことが保証されます。誰かがすでに所有権を取得している場合は、グループに通知する必要はありません。

次のいずれかの条件を満たす

少なくとも1つがtrueである必要があります。

• チケット > グループ：変更済み - この更新でグループの割り当てが変更されました
• チケット > 担当者：変更済み - 担当者が変更されました（たとえば、未割り当てから割り当て済み、またはその逆）

これらの「いずれか」条件は重要です。グループ割り当てで新しいチケットが作成されている場合と、既存のチケットが別のグループに再割り当てされている場合の両方のシナリオをキャッチするためです。

追加するオプションの条件

ワークフローに応じて、次の条件を追加することもできます。

• チケット > ステータスカテゴリ：解決済みではない - 再開されてすぐに再割り当てされる解決済みのチケットについてグループに通知しないでください
• チケット > 現在のユーザー：（エンドユーザー） - 顧客がチケットを作成した場合のみ通知し、エージェントが内部チケットを作成した場合は通知しません
• チケット > タグ：次のいずれも含まない：auto_reply - 自動応答を受信したチケットの通知をスキップします

条件を追加するには、適切なセクション（すべてまたはいずれか）の下にある「条件を追加」をクリックし、ドロップダウンメニューからフィールド、演算子、および値を選択します。

ステップ4：通知アクションを設定する

条件を設定したら、トリガーが発動したときに何が起こるかを定義する必要があります。

デフォルトのアクションは次のとおりです。

• 通知方法 > グループメール > （割り当てられたグループ）

これにより、チケットが割り当てられたグループのすべてのエージェントにメールが送信されます。メールには、主要なチケット情報を含むテンプレートが使用されます。

件名と本文フィールドを編集して、メールの内容をカスタマイズできます。Zendeskは、プレースホルダー（Liquidマークアップとも呼ばれます）を使用して、動的なチケットデータを挿入します。

使用する一般的なプレースホルダー：

• {{ticket.id}} - チケット番号
• {{ticket.title}} - 件名
• {{ticket.description}} - 顧客の最初のメッセージ
• {{ticket.url}} - チケットへの直接リンク
• {{ticket.group.name}} - 割り当てられたグループの名前
• {{ticket.priority}} - チケットの優先度レベル

シンプルだが効果的なメールテンプレートは次のようになります。

件名： 新しいチケット#{{ticket.id}}が{{ticket.group.name}}に割り当てられました：{{ticket.title}}

本文： 新しいチケットがあなたのグループに割り当てられました。

チケット： #{{ticket.id}} - {{ticket.title}} 優先度： {{ticket.priority}} リクエスター： {{ticket.requester.name}}

{{ticket.description}}

チケットを表示

ステップ5：トリガーを保存してテストする

最後のステップは、トリガーを保存し、本番環境で信頼する前に徹底的にテストすることです。

Zendeskは、ライブチケットに影響を与えることなくトリガーをテストできるサンドボックス環境を提供しています。または、テストチケットを作成して、次のことを確認できます。

1. 適切な人が通知を受信する
2. メールの内容が正しい
3. 通知ループを作成していない（トリガーが互いに無期限に発動し続ける）

特定のチケットで「プレビュー」機能を使用して、どの条件が一致し、どの条件が一致しないかを確認します。これは、トリガーが期待どおりに発動しない場合にデバッグするのに役立ちます。

Zendeskトリガーアクション通知ユーザーグループの一般的なユースケース

デフォルトのトリガーは良い出発点ですが、ほとんどのチームはよりニュアンスのあるルーティングを必要としています。ここでは、4つの一般的なシナリオと、それらを設定する方法について説明します。

ユースケース1：サポートチームの新しいチケットアラート

最も基本的なユースケース：新しいチケットがキューに届くたびにグループに通知します。

条件：

• 次のすべてを満たす：チケット > チケット：作成済み
• 次のすべてを満たす：チケット > グループ：「-」ではない
• 次のすべてを満たす：チケット > 担当者：「-」

アクション：

• 通知方法 > グループメール：（割り当てられたグループ）

これにより、すべての新しいチケットが割り当てられたグループに即時のメールをトリガーすることが保証されます。キューで気付かれずに放置されるチケットはもうありません。

ユースケース2：VIP顧客のルーティング

高価値の顧客の場合、チケットが一般的なキューをスキップして、プレミアムサポートグループに直接移動するようにします。

まず、VIP顧客に「vip」という組織タグがあることを確認します。次に、このトリガーを作成します。

条件：

• 次のすべてを満たす：組織 > タグ：次のいずれかを少なくとも1つ含む：vip
• 次のすべてを満たす：チケット > グループ：「-」ではない
• 次のすべてを満たす：チケット > 担当者：「-」
• 次のいずれかを満たす：チケット > チケット：作成済み

アクション：

• チケット > グループ：プレミアムサポート
• チケット > 優先度：高
• 通知方法 > グループメール：（割り当てられたグループ）

この設定の詳細については、Zendeskトリガー通知のガイドをご覧ください。

ユースケース3：営業時間外の緊急チケットのエスカレーション

営業時間外に発生する緊急の問題については、オンコールチームにすぐに通知する必要があります。

条件：

• 次のすべてを満たす：チケット > 営業時間内ですか？：いいえ
• 次のすべてを満たす：チケット > 優先度：緊急
• 次のすべてを満たす：チケット > チケット：作成済み

アクション：

• チケット > グループ：オンコールチーム
• 通知方法 > グループメール：（割り当てられたグループ）

注：「営業時間内」条件を使用するには、Zendeskで営業時間（管理センター > アカウント > 営業時間）を設定する必要があります。

ユースケース4：カテゴリベースのルーティング

チケットの内容または顧客が使用したフォームに基づいてチケットをルーティングします。

条件：

• 次のすべてを満たす：チケット > 件名テキスト：次のいずれかを少なくとも1つ含む：払い戻し 請求書 請求
• 次のすべてを満たす：チケット > グループ：「-」ではない
• 次のすべてを満たす：チケット > 担当者：「-」
• 次のいずれかを満たす：チケット > グループ：変更済み OR チケット > 担当者：変更済み

アクション：

• チケット > グループ：財務チーム
• 通知方法 > グループメール：（割り当てられたグループ）

グループ通知トリガーのベストプラクティス

さまざまなチームのために数十のトリガー構成を設定した後、何が機能し、何が機能しないかについていくつかの教訓を学びました。

1つのトリガーは1つのジョブを実行します。 複数のアクションを1つのトリガーにバンドルしないでください。優先度を設定し、グループを割り当て、通知を送信する必要がある場合は、3つの個別のトリガーを使用します。これにより、トラブルシューティングがはるかに簡単になり、意図しない副作用を防ぐことができます。

順序が重要です。 トリガーを実行する順序で配置します。最初にカテゴリ化（優先度を設定し、タグを追加）、次にルーティング（グループに割り当て）、最後に通知を行います。これにより、チケットがアラートされる前に、すべてのプロパティが設定されていることが保証されます。

タグを使用してループを防ぎます。 トリガーアクションに「group_notified」のようなタグを追加し、「タグ：次のいずれも含まない：group_notified」という条件を追加して、同じチケットでトリガーが再度発動するのを防ぎます。

ロジックを文書化します。 各トリガーが何を行い、なぜ存在するのかを説明する共有ドキュメントを保持します。6か月後にトラブルシューティングを行う必要がある場合に、将来のあなた（およびあなたのチームメイト）は感謝するでしょう。

ライブになる前にテストします。 Zendeskのサンドボックス環境を使用するか、テストチケットを作成して、トリガーが期待どおりに機能することを確認します。適切な人が通知を受け取り、通知ループを作成していないことを確認してください。

代わりに自動化を使用するタイミングを知ってください。 トリガーは、チケットが作成または更新されるとすぐに発動します。自動化は、時間ベースの条件に基づいて、スケジュール（通常は1時間ごと）で実行されます。新しいチケットの通知には、トリガーを使用します。数時間割り当てられていないチケットのリマインダーには、自動化を使用します。

トリガーの複雑さに溺れている場合は、当社のAIトリアージ製品が代替手段を提供します。複雑な条件チェーンを持つ数十のトリガーを維持する代わりに、AIが時間の経過とともに学習する平易な英語の指示を使用できます。

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

適切な構成でも、トリガーが期待どおりに機能しない場合があります。ここでは、一般的な問題を診断して修正する方法について説明します。

問題1：トリガーが発動しない

トリガーが期待どおりに発動しない場合：

1. トリガーの順序を確認します。 トリガーは上から下に実行されます。リストの上位にある別のトリガーが、条件が満たされないようにチケットを変更した場合、トリガーは発動しません。トリガーをリストの上位に移動してみてください。
2. すべての条件が満たされていることを確認します。 特定のチケットで「プレビュー」機能を使用して、どの条件が一致し、どの条件が一致しないかを確認します。
3. 非アクティブ化されたトリガーを確認します。 テスト中に誤ってトリガーを非アクティブ化するのは簡単です。トリガー名の横にある「非アクティブ」ラベルを探します。

問題2：重複した通知

エージェントが同じチケットに対して複数のメールを受信している場合：

1. 抑制ルールを理解します。 Zendeskには、重複した通知を防ぐための組み込みロジックがあります。エージェントが担当者とグループメンバーの両方である場合、すでに担当者の通知を受け取っている場合は、グループメールは送信されません。
2. 重複するトリガーを確認します。 同様の条件を持つ複数のトリガーがある場合、それらがすべて発動している可能性があります。トリガーリストを確認し、可能な場合は統合します。
3. タグを使用してループを防ぎます。 トリガーアクションに「group_notified」のようなタグを追加し、タグがまだ存在しないことを確認する条件を追加して、発動を防ぎます。

問題3：通知がスパムになる

グループメンバーが通知メールがスパムフォルダに届いていると報告している場合：

1. メールの内容を確認します。 メールテンプレートで、「緊急」、「今すぐ行動」、「過度の感嘆符」などのスパムトリガーワードを避けてください。
2. SPFおよびDKIMレコードを確認します。 これらのDNSレコードはメールを認証し、配信可能性を向上させます。Zendeskは、メール構成ドキュメントでSPFおよびDKIMの設定手順を提供しています。
3. エージェントに送信者をホワイトリストに登録するように依頼します。 通知は、Zendeskサポートメールアドレスから送信されます。エージェントにこのアドレスを連絡先または安全な送信者リストに追加してもらいます。

問題4：間違ったグループに通知が送信される

予期していなかったグループに通知が送信される場合：

1. 先行するトリガーでグループ割り当てロジックを確認します。 トリガーは順番に実行されることを忘れないでください。リストの前のトリガーが、通知トリガーが実行される前にグループの割り当てを変更している可能性があります。
2. 複数のトリガーがグループの割り当てを変更しているかどうかを確認します。 グループフィールドを設定するすべてのトリガーを確認して、競合していないことを確認します。

Zendeskトリガーの代替手段を検討するタイミング

トリガーは、簡単なルーティングルールには適していますが、制限があります。すべての条件を明示的に定義する必要があります。チケットの実際の内容と意図に基づいてルーティングする場合は、すぐに数十のトリガーになり、それぞれにキーワードと例外の長いリストが含まれます。

トリガーが時代遅れになった兆候：

• ますます複雑な条件ロジックを持つ20以上のトリガーを管理している
• 新しいエッジケースが出現するたびに、毎週トリガーを更新する必要がある
• ルーティングは、キーワードマッチングではキャプチャできないニュアンスのあるチケットコンテンツに依存している
• エージェントは、トリガーが誤ってルーティングしたチケットを再割り当てするのにかなりの時間を費やしている

代替アプローチ：

Slack連携 - Zendeskユーザーだけでなく、より広範なチーム通知の場合。ZendeskのSlack連携（Zendesk Marketplaceで入手可能）を使用すると、チャネルに通知を送信できます。

Webhook（ウェブフック） - チケットイベントが発生したときに外部システムに通知する場合。他のツールでレコードを更新したり、Zendeskアクセス権を持たない関係者に通知したりする必要がある場合に役立ちます。

AI搭載のルーティング - ここで当社が登場します。eesel AIを使用すると、Zendeskアカウントを接続すると、当社のAIが過去のチケット、ヘルプセンターの記事、およびエージェントの応答をすぐに分析します。どのタイプのチケットがどのグループに移動するか、どの言語が緊急性を示しているか、チームが通常さまざまなシナリオをどのように処理するかを学習します。

数十の条件を持つトリガーの代わりに、eesel AIに平易な英語で簡単な指示を与えます。

• 「請求に関する質問は財務チームにルーティングしますが、「不正行為」について言及している場合はセキュリティグループにエスカレートします」
• 「VIP顧客のチケットはキューをスキップして、プレミアムサポートに移動する必要があります」
• 「APIに関する技術的な質問は、開発者リレーションチームに移動します」

残りは当社が処理します。AIは受信した各チケットを読み取り、意図を理解し、適切なグループにルーティングします。複雑なトリガーチェーン、キーワードリストのメンテナンス、および条件が競合する場合のデバッグは不要です。

AIは時間の経過とともに改善されます。ルーティングの決定を修正すると、eesel AIはそのフィードバックから学習します。従来のトリガーでは、エッジケースを発見するたびに、新しい条件を手動で追加する必要があります。

eesel AIをZendeskアカウントと統合するには数分しかかからず、チケットをよりインテリジェントにルーティングできます。

よりスマートなチケット通知を始めましょう

新しいチケットでグループに通知するようにZendeskトリガーを設定することは、効率的なサポートワークフローを構築するための基本的なステップです。デフォルトの「割り当てられたグループに通知」トリガーは良い出発点となり、カスタムトリガーを使用すると、より複雑なルーティングシナリオを処理できます。

重要なのは、シンプルから始めて、必要な場合にのみ複雑さを追加することです。デフォルトのトリガーから始めて、チームでテストし、VIPルーティングや営業時間外のエスカレーションなどの特定のユースケースに合わせてカスタムトリガーをレイヤー化します。

ますます複雑な条件ロジックを持つ数十のトリガーを管理している場合は、AI搭載の代替手段を検討する時期かもしれません。eesel AIのようなツールは、トリガーが苦労するニュアンスのある意思決定を処理し、すべてのシナリオに明示的なルールを必要とするのではなく、チームのパターンから学習できます。

どちらのアプローチを選択しても、目標は同じです。適切な人が新しいチケットについてすぐに知っていることを確認し、顧客がより迅速な応答を受け、チームが整理された状態を維持できるようにします。

AI搭載のチケットルーティングを試してみませんか？価格を確認すると、Zendeskで複雑なトリガーチェーンを管理することと比較してどうなるかを確認してください。