Zendeskトリガーで担当者への割り当て通知を設定する方法

チケットがキューに届いたとき、エージェントはすぐに知る必要があります。タイムリーな通知がないと、応答時間が遅れ、顧客は必要以上に長く待つことになります。そこで、Zendeskトリガーの担当者への割り当て通知が役立ちます。

このトリガーはZendeskのデフォルト構成の1つですが、多くのアドミニストレーターはカスタマイズしたり、再作成したり、単にその動作の理由を理解したりする必要があります。新しいヘルプデスクを設定する場合でも、エージェントに通知が届かない理由をトラブルシューティングする場合でも、このガイドでは知っておくべきことをすべて説明します。

このトリガーの仕組み、適切な構成方法、および期待どおりに動作しない場合の対処法について説明します。

このトリガーの機能とその必要性

「担当者への割り当てを通知」トリガーは、チケットがエージェントに割り当てられるたびに、エージェントにメール通知を送信します。これは、応答時間とエージェントの生産性に大きな影響を与える簡単な概念です。

ビジネスケースは次のとおりです。多忙なサポート環境では、チケットは複数のチャネルを通じて割り当てられます。マネージャーが緊急の問題を手動で割り当てる場合があります。Zendeskトリガーは、カテゴリに基づいてチケットをルーティングする場合があります。または、ラウンドロビン割り当てによってワークロードが均等に分散される場合があります。どのシナリオでも、割り当てられたエージェントは、チケットが自分のものであることを知る必要があります。

この通知がないと、エージェントは常にビューまたはダッシュボードを確認する必要があります。チケットは見過ごされたままになります。顧客は待ちます。SLA（Service Level Agreement：サービス品質保証）が侵害されます。

Zendeskには、新しいアカウントにデフォルトでこのトリガーが含まれていますが、再構築する必要がある正当な理由があります。

• トラブルシューティング中に誤って非アクティブ化した
• 特定のチームまたはブランドに対して異なるロジックが必要
• 追加のコンテキストを使用してメールテンプレートをカスタマイズしたい
• 別のシステムから移行しており、ワークフローを再作成する必要がある

このトリガーは、スキルベースのルーティングまたは自動割り当てを使用するチームにとって特に価値があります。チケットが手動で介入することなくエージェントに流れる場合、通知は新しい作業が到着したことを示す唯一のシグナルになります。

Zendeskは基本的な通知を処理しますが、最新のAIチームメイトはこれをさらに進めることができます。エージェントにチケットがあることを警告するだけでなく、AIは問題を事前に分類し、最初の応答を下書きし、そのすべてのコンテキストを通知自体に配信できます。しかし、代替案を検討する前に、基本的なトリガーが正しく機能していることを確認しましょう。

よりスマートな割り当てワークフローをお探しの場合は、eesel AIがZendeskと統合して、インテリジェントなトリアージおよび自動下書き機能を既存のセットアップに追加します。

トリガーロジックの理解

「担当者への割り当てを通知」トリガーは、アドミニストレーターを混乱させる可能性のある2つの特定の条件を使用します。両方の条件が存在する理由を理解することで、後でトラブルシューティング時間を節約できます。

2つの条件の説明

標準トリガーには、「次のすべての条件を満たす」の下に次の条件があります。

1. 担当者 > 変更済み - 担当者フィールドの値が変更されるたびにトリガーを起動します
2. 担当者 > 次と異なる > （現在のユーザー） - エージェントが自分自身にチケットを割り当てるときにトリガーが起動しないようにします

これがどのように機能するかを確認するために、2つのシナリオを見てみましょう。

シナリオA：マネージャーがエージェントに割り当てる

• サラ（サポートマネージャー）がチケットを開き、マイクに割り当てます
• 担当者は空/未割り当てからマイクに変更されました
• 現在のユーザーはサラです
• マイクはサラではないため、「担当者が（現在のユーザー）ではない」という条件が満たされます
• 結果：マイクは通知メールを受信します

シナリオB：エージェントが自己割り当てする

• マイクは未割り当てのチケットを表示しており、「担当にする」をクリックして自分自身に割り当てます
• 担当者は空からマイクに変更されました
• 現在のユーザーはマイクです
• マイクは現在のユーザーであるため、「担当者が（現在のユーザー）ではない」という条件が失敗します
• 結果：通知は送信されません

この2番目のシナリオは、混乱がよく発生する場所です。多くのアドミニストレーターはトリガーを見て、「割り当てられたばかりの人に通知するために「担当者が現在のユーザーである」であるべきではないか？」と考えます。

答えはノーです。「現在のユーザーではない」という条件は、エージェントが自己割り当てするときに通知スパムを防ぐために特に存在します。マイクが「担当にする」をクリックすると、彼はすでにチケットを持っていることを知っています。彼がしたことを伝えるメールは必要ありません。

トリガーが起動する場合と起動しない場合

トリガーは、次の場合に起動します。

• 任意のユーザー（エージェント、管理者、またはシステム）がチケットをエージェントに割り当てる場合
• 割り当てが手動選択、別のトリガー、または自動化によって行われる場合
• チケットが初めて割り当てられるか、別のエージェントに再割り当てされる場合

トリガーは、次の場合には起動しません。

• エージェントが自分自身にチケットを割り当てる場合
• 担当者フィールドが更新されたが、同じエージェントのままである場合（実際の変更なし）
• トリガーが、このトリガーが一致しないようにチケットをすでに変更した別のトリガーの下に配置されている場合

トリガーの順序に関するこの最後の点は強調する価値があります。Zendeskトリガーは上から下に実行されます。担当者フィールドを変更するトリガーが通知トリガーの上に配置されている場合、通知が間違った値で起動するか、まったく起動しない可能性があります。ベストプラクティスは、通知トリガーをトリガーリストの最後に配置することです。Zendeskのトリガー編成に関するドキュメントによると、トリガーの実行順序はワークフローの結果に大きな影響を与える可能性があります。

ステップバイステップのセットアップガイド

このトリガーを最初から作成する必要がある場合は、完全なプロセスを次に示します。

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

管理センターに移動し、次にオブジェクトとルール、次にビジネスルール、次にトリガーに移動します。これは、すべてのチケット自動化が存在する場所です。Zendesk管理インターフェイスのナビゲーションの詳細については、Zendeskの公式ドキュメントを参照してください。

ステップ2：新しいトリガーを作成する

ページの上部にある「トリガーを追加」をクリックします。「割り当てられたときにエージェントに通知する」または「担当者への割り当て通知」のような明確で説明的な名前を付けます。このトリガーの機能を説明する説明を追加します。これにより、他の管理者が後でセットアップを理解するのに役立ちます。

整理のために適切なカテゴリを選択します。ほとんどのチームは「通知」を使用するか、「エージェントアラート」のようなカスタムカテゴリを作成します。適切なカテゴリ分類により、Zendeskインスタンスの成長に合わせてトリガーを管理しやすくなります。

ステップ3：条件を設定する

「次のすべての条件を満たす」の下に、次の2つの条件を追加します。

1. チケット > 担当者 > 変更済み
2. チケット > 担当者 > 次と異なる > （現在のユーザー）

最初の条件は、割り当てが実際に変更された場合にのみトリガーが起動するようにします。2番目の条件は、前に説明した自己割り当て通知スパムを防ぎます。

このトリガーを特定のグループまたはブランドに対してのみ起動する場合は、ここに追加の条件を追加できます。たとえば、「グループ > 次と等しい > プレミアムサポート」を追加して、プレミアム層のエージェントにのみ通知することができます。Zendeskトリガードキュメントで、条件オプションの詳細を確認できます。

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

「アクション」で、次を選択します。

通知 > ユーザーにメールを送信 > （担当者）

これにより、条件が満たされた後、担当者フィールドに表示される人にメールを送信するようにZendeskに指示します。

次に、メールの件名と本文をカスタマイズします。割り当て通知に最も役立つプレースホルダーを次に示します。

適切なメールの件名は、「チケット#{{ticket.id}}があなたに割り当てられました：{{ticket.title}}」です。

追加のプレースホルダーオプションと高度なカスタマイズについては、[設定] > [オブジェクトとルール] > [トリガー]の下にあるZendesk管理パネルのZendeskプレースホルダーリファレンスドキュメントを参照してください。

本文には、エージェントがチケットを開かなくても問題を理解できるように、十分なコンテキストを含めます。

こんにちは{{ticket.assignee.first_name}}様、

チケット#{{ticket.id}}があなたに割り当てられました。

顧客：{{ticket.requester.name}}
優先度：{{ticket.priority}}
件名：{{ticket.title}}

{{ticket.description}}

チケットを表示：{{ticket.url}}

ステップ5：保存してテストする

「作成」をクリックしてトリガーを保存します。次に、テストします。

1. テストチケットを作成するか、既存のチケットを使用します
2. 別のエージェント（自分自身ではない）にあなたに割り当ててもらいます
3. 通知のメールを確認します
4. メールに構成したすべての情報が含まれていることを確認します

数分以内にメールを受信しない場合は、スパムフォルダーを確認し、エージェントプロファイルでメール通知が有効になっていることを確認します。

一般的なバリエーションとカスタマイズ

基本的なトリガーが機能したら、特定のワークフローに合わせて調整することができます。次のカスタマイズは、チームのニーズに合わせて通知を調整するのに役立ちます。

自己割り当て時に通知する

エージェントが自分でチケットを取得した場合でも、チームが通知を必要とする場合は、「担当者が（現在のユーザー）ではない」という条件を削除するだけです。これは、エージェントが処理するすべてのチケットの記録をインボックスに保持する必要がある環境、またはメール通知が転送ルールを介して他のワークフローをトリガーする環境で役立ちます。この変更は、完全なメール記録を必要とする外部チケットシステムまたはコンプライアンス追跡を使用するチームで一般的です。

グループ固有の通知を追加する

「グループ > 次と等しい > [特定のグループ名]」のような条件を追加して、チームごとに異なる通知テンプレートを作成します。請求チームは、テクニカルサポートチームとは異なるコンテキストが必要になる場合があります。たとえば、請求通知には請求金額を含めることができますが、技術通知ではエラーコードと影響を受けるシステムを強調することができます。

通知にチケットの詳細を含める

基本的なプレースホルダーに加えて、次のものを含めることができます。

• {{ticket.custom_field_fieldname}}を使用したカスタムフィールド値
• {{ticket.tags}}を使用したタグ
• {{ticket.organization.name}}を使用した組織の詳細
• {{ticket.satisfaction_rating.score}}を使用した満足度評価ステータス

複数の人に通知する

マネージャーまたはチームリーダーが割り当てについて知る必要がある場合は、次の2つのオプションがあります。

1. 「CCを追加」アクションを使用して、同じメールに追加の受信者を含めます
2. チケットがメンバーに割り当てられたときにグループにメールを送信する別のトリガーを作成します

2番目のオプションを使用すると、異なる対象者向けのメッセージコンテンツをより細かく制御できます。

通知が機能しない場合のトラブルシューティング

エージェントが割り当て通知を受信していないと報告した場合は、このチェックリストを確認してください。

トリガーの位置を確認する

トリガーは、[トリガー]ページに表示される順に実行されます。通知トリガーの実行後に別のトリガーが担当者を変更した場合、通知に古い情報が含まれているか、まったく起動しない可能性があります。

ベストプラクティス：すべてのカテゴリ分類、ルーティング、およびフィールド更新トリガーの後、トリガーリストの最後に通知トリガーを配置します。

エージェントのメール設定を確認する

各エージェントは、独自の通知設定を制御します。エージェントプロファイルでは、メール通知を完全に無効にするか、特定のチケットイベントに対して無効にすることができます。エージェントが通知を受信していない場合は：

1. プロファイル設定を確認してもらいます
2. 「メール」が連絡方法として選択されていることを確認します
3. チケット通知をオプトアウトしていないことを確認します

スパムフォルダーを確認する

Zendesk通知メールは、特に新しい実装の場合、スパムに分類される可能性があります。配信可能性のベストプラクティスによると、メール認証とドメイン構成は、通知がエージェントの受信トレイに確実に届くようにするために重要な役割を果たします。エージェントに次のことを依頼します。

1. スパム/迷惑メールフォルダーを確認します
2. Zendeskメールドメインを安全な送信者リストに追加します
3. support@yourdomain.zendesk.com（またはカスタムドメイン）からのメールをホワイトリストに登録します

トリガープレビューでテストする

Zendeskの「一致プレビュー」機能を使用すると、実際にメールを送信せずに、既存のチケットに対してトリガー条件をテストできます。これを使用して、条件が期待どおりに機能することを確認します。

1. トリガーを編集します
2. 「一致プレビュー」をクリックします
3. 通知をトリガーする必要がある最近のチケットを選択します
4. 条件が一致するかどうかを確認します

プレビューで条件が一致しないことが示されている場合は、ロジックを調整する必要があります。

一般的な条件の間違い

• 「担当者が変更された」の代わりに「担当者が次と等しい」を使用する - 「次と等しい」は現在の値を確認し、変更されたかどうかは確認しません。トリガーは、割り当ての変更だけでなく、すべての更新で起動します。

• 「現在のユーザー」を特定のエージェント名と混同する - 「（現在のユーザー）」は、変更を加えた人を動的に参照します。エージェントの名前を入力するためのプレースホルダーではありません。

• 他のフィールドを変更するチケットの更新を考慮しない - トリガーに2つの標準条件を超える追加の条件がある場合は、割り当てが発生したときにそれらの条件が満たされていることを確認してください。

基本的な割り当て通知を超える

Zendeskトリガーは、割り当てについてエージェントに通知するという基本的なタスクを処理します。しかし、最新のサポートチームは、単純な通知からインテリジェントなワークフロー自動化へと移行しています。

違いは次のとおりです。トリガーはエージェントに「チケットがあります」と伝えます。AIチームメイトはエージェントに「チケットがあります。請求の問題に関するもので、顧客は不満を感じています。これは下書きの応答であり、同様のチケットはこのように解決されました」と伝えます。

eesel AIでは、これを構成するツールではなく、採用するチームメイトとしてアプローチします。ヘルプデスク向けのAIエージェントは、成熟した展開で最大81％のチケットを自律的に解決できます。ルーティングと通知だけでなく、当社のAIは次のことができます。

• 割り当て前のスマートトリアージ：AIは受信チケットを読み取り、トピックと緊急度で分類し、可用性だけでなくコンテンツに基づいて適切なスペシャリストにルーティングします。これは、請求の専門家が請求の質問を受け、技術チームがバグレポートを受け取ることを意味します。AIトリアージ機能の詳細をご覧ください。

• コンテキスト豊富な通知：チケットの件名を送信するだけでなく、AI Copilotは顧客が求めていることの要約を生成し、感情を特定し、緊急度インジケーターにフラグを立てます。

• 自動下書き応答：エージェントは、割り当て通知とともに下書きの返信を受け取ります。下書きはナレッジベースと過去のチケットに基づいているため、チームが作成したように聞こえます。

• インテリジェントなエスカレーション：AIは、人間の注意が必要なチケットと、自律的に解決できるチケットを識別します。これは、エージェントが本当に専門知識を必要とするチケットについてのみ通知を受けることを意味します。チケットの量を減らしたいチームのために、AIエージェントは人間の関与なしにルーチンな問い合わせを処理できます。

その結果、エージェントが通知を受け取ったとき、ゼロから開始するわけではありません。彼らはコンテキスト、下書きの応答、およびこのチケットが本当に彼らの注意を必要とすることへの自信を持っています。

基本的な通知を機能させるためにZendeskトリガーの構成に多くの時間を費やしている場合は、AIチームメイトが通知ワークフローをよりインテリジェントに処理できるかどうか、また自律的な解決を通じて全体的なチケット量を減らすことができるかどうかを検討する価値があるかもしれません。

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