Zendeskトリガー条件のエージェント応答数を使用する方法：完全ガイド

エージェントがチケットに何回応答したかを追跡することは、品質保証、エスカレーションワークフロー、およびチケットの複雑さを理解するのに役立ちます。Zendeskにはこのための組み込み条件がありますが、自動化を構築する前に理解しておく必要のあるいくつかの癖があります。

このガイドでは、エージェント応答条件が正確に何をするのか、その設定方法、一般的なユースケース、および知っておくべき制限事項について説明します。また、ネイティブ機能がニーズを完全に満たさない場合の回避策についても説明します。eesel AIのようなツールがこれらの制限を克服するのにどのように役立つかを含みます。

Zendeskのエージェント応答条件とは？

Zendeskのチケット > エージェント応答条件は、エージェントがチケットに追加した公開コメントの数を測定します。内部メモや最初のチケット作成ではなく、別の顧客またはエージェントからのコメントへの応答のみをカウントします。

実際の動作は次のとおりです。

• 顧客がチケットを送信します（これは応答としてカウントされません）。
• エージェントが公開コメントを追加します（これは1つのエージェント応答としてカウントされます）。
• 顧客が応答します。
• エージェントが再度応答します（これは2つのエージェント応答としてカウントされます）。

これを関連するメトリックと区別することが重要です。

エージェント応答条件は、Zendesk Suite Teamプラン以上で利用できます。基本的なSupport Teamプランには含まれていないため、エントリーレベルの階層を使用している場合はアップグレードする必要があります。Zendeskのドキュメントによると、この条件は長年自動化システムの定番であり、チームが追加の注意が必要な複雑なチケットを特定するのに役立っています。

エージェント応答条件でトリガーを設定する

エージェント応答条件を使用するトリガーの作成は、他のZendeskトリガーと同じプロセスに従います。ステップバイステップの内訳は次のとおりです。

ステップ1：管理センターでチケットトリガーにアクセスする

管理センター > オブジェクトとルール > ビジネスルール > トリガーに移動します。設定済みのトリガーがある場合は、既存のトリガーのリストが表示されます。

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

トリガーを作成をクリックして、わかりやすい名前を付けます。適切な命名規則は、管理するトリガーが多数ある場合に役立ちます。「エージェント応答3回後にエスカレーション」や「高タッチチケットにフラグを立てる」などが適切です。

ステップ3：エージェント応答条件を設定する

次のすべての条件を満たすで、エージェント応答条件を追加します。

1. 条件を追加をクリックします。
2. チケット > エージェント応答を選択します。
3. 演算子を選択します：次と等しい、次と等しくない、次より小さい、または次より大きい
4. 数値を入力します。

たとえば、エージェント応答が3回を超えた場合にチケットをエスカレーションする場合は、エージェント応答 > 次より大きい > 2を設定します。

ステップ4：サポート条件を追加する

通常、トリガーが不適切に起動するのを防ぐために、追加の条件が必要になります。一般的な追加条件は次のとおりです。

• チケット > ステータスが終了ではない（トリガーは終了したチケットでは実行されませんが、これにより明確さが追加されます）。
• チケット > 担当者が「-」ではない（チケットが割り当てられていることを確認します）。
• チケット > タグに次のいずれも含まれていない：「エスカレーション済み」（再エスカレーションを防ぎます）。

ステップ5：トリガーアクションを定義する

条件が満たされたときに何が起こるかを選択します。エージェント応答トリガーの一般的なアクションは次のとおりです。

• タグを追加：「high_touch」または「escalated」のようなタグをチケットに追加します。
• 担当者を変更：上級エージェントまたは専門チームに再割り当てします。
• 内部メモを追加：エスカレーションについてチームに通知します。
• ステータスを設定：カスタムステータスを使用する場合は、「エスカレーション済み」に変更します。

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

トリガーを保存し、テストチケットを作成して、正しく起動することを確認します。Zendeskのトリガーテストは気難しい場合があるため、手動テストが最も信頼できるアプローチであることがよくあります。Zendeskのトリガードキュメントに記載されているように、実際のチケットシナリオでテストすると、自動化が本番環境で期待どおりに動作することが保証されます。

エージェント応答トリガーの一般的なユースケース

チームは、エージェント応答条件をいくつかの実用的な方法で使用します。最も一般的なシナリオを次に示します。

複雑なチケットのエスカレーション

一部のチケットは、他のチケットよりも多くのやり取りが必要です。特定のエージェント応答数を超えた場合にチケットを自動的にエスカレーションして、複雑な問題が上級者の注意を引くようにすることができます。

たとえば、エージェント応答 > 次より大きい > 3のトリガーを設定して、チケットを上級サポートキューに移動します。これにより、問題が発生する前に長引く問題をキャッチします。

品質保証ワークフロー

応答数が異常に多いチケットは、混乱、対応の難しい顧客、または問題を解決するのに苦労しているエージェントを示していることがよくあります。これらにQAレビューのフラグを立てると、コーチングの機会を特定するのに役立ちます。

エージェント応答 > 次より大きい > 5のトリガーは、「qa_review」タグを追加し、解決後の分析のためにチームリーダーにチケットを割り当てることができます。

SLA管理

応答数が多いと、SLAコミットメントに違反するリスクのあるチケットを示す可能性があります。エージェント応答が2を超えた場合に「sla_at_risk」タグを追加するトリガーを作成して、より迅速な応答時間を促すことができます。

ZendeskのSLAドキュメントによると、応答数をSLAポリシーと組み合わせることで、チケットの状態をより完全に把握できます。

最初の応答で自動割り当て

エージェント応答条件の賢い使用法は、エージェントが最初に応答したときに、割り当てられていないチケットを自動的に割り当てることです。エージェント応答 > 次と等しい > 0を**担当者が「-」**と組み合わせて、**担当者 > （現在のユーザー）**のアクションを設定します。

これにより、最初にエンゲージしたエージェントがチケットを所有し、孤立した会話を防ぎます。

制限事項を理解する

エージェント応答数に基づいてワークフロー全体を構築する前に、いくつかのドキュメント化された制限事項を知っておく必要があります。

APIとの競合状態

Zendesk APIまたはWebhookをトリガーと並行して使用している場合は、競合状態が発生する可能性があります。これは、トリガーとAPI呼び出しが同じチケットを同時に更新しようとした場合に発生します。

Zendeskコミュニティメンバーは、この正確な問題を説明しました。

Webhookを介してこのトリガーを使用して、エージェントがチケットを更新する回数をカウントするトリガーを作成しました。トリガーは正常に起動しています。ただし、ステータスがOn_holdとして選択されている場合、別の応答が送信され、ステータスがOpen、Pending、またはSolveとして更新されない限り、エージェント応答数は更新されません。これは、ビジネスルール（例：トリガー、自動化）とAPIを同時に使用すると発生する競合状態が原因であると言われています。

Zendesk Community

これは、正確な応答数に依存するカスタム統合を構築している場合は、追加のエラー処理または再試行ロジックが必要になる可能性があることを意味します。この問題の詳細については、Zendeskコミュニティディスカッションを参照してください。

保留中のステータスの複雑さ

チケットステータスが保留中に設定されている場合、別の応答が送信され、ステータスがオープン、保留中、または解決済みに変わるまで、エージェント応答数が正しく更新されないことがあります。

これは、サードパーティの依存関係または待機期間に保留中のステータスを使用する場合に特に問題となります。応答数トリガーは、これらの期間中に期待どおりに起動しない場合があります。

公開コメントと内部コメント

エージェント応答条件は公開コメントのみをカウントします。内部メモは合計にカウントされません。これは通常、必要な動作です。ただし、エージェントが公開応答の前に内部メモを頻繁に使用する場合、カウントは実際に費やされた労力を反映していない可能性があります。

内部メモを含むすべてのエージェントアクティビティを追跡する必要がある場合は、代わりにZendesk Exploreのエージェント更新メトリックを使用してください。

トリガーごとのコメント制限

Zendeskは、トリガーがチケットイベントごとに追加できる公開コメントと内部メモの最大数を1つに制限しています。同じ更新で複数のトリガーが起動する可能性がある場合、最初のトリガーのコメントアクションのみが実行されます。

これは、複数のトリガーが応答数に基づいてコメントを追加しようとする複雑な自動化を構築している場合に重要です。

トリガーサイズ制限

トリガーを含むすべてのZendeskビジネスルールは、65 KB未満である必要があります。多くの条件とアクションを含む複雑なトリガーは、この制限に達する可能性があります。高度な応答ベースのワークフローを構築している場合は、ロジックを複数のトリガーに分割する必要がある場合があります。

APIとWebhookの回避策

ネイティブのエージェント応答条件がニーズを満たさない場合は、カスタムソリューションを構築するためのいくつかのオプションがあります。

Webhookを使用したカスタムカウンター

トリガーが起動するたびにチケットデータを外部システムに送信するWebhookを設定できます。この外部システムは、Zendeskのネイティブ制限をバイパスして、独自に応答数を維持できます。

ワークフローは次のようになります。

1. チケットの更新時にトリガーが起動します。
2. WebhookがチケットIDと現在のデータをシステムに送信します。
3. システムがZendesk APIにクエリして、完全なコメント履歴を取得します。
4. システムが独自に応答数を計算します。
5. システムがAPIを介してZendeskのカスタムフィールドを更新します。

このアプローチには開発リソースが必要ですが、応答のカウント方法を完全に制御できます。

Zendesk APIを使用して更新を追跡する

レポートと分析のために、Zendesk Tickets APIまたはZendesk開発者ドキュメントの条件リファレンスを介してチケットコメント履歴を直接クエリできます。これにより、トリガー条件に依存せずに、プログラムで公開エージェントコメントをカウントできます。

これは、次の用途に役立ちます。

• カスタムダッシュボードの構築
• Zendesk Exploreが処理できないレポートの生成
• 外部のワークフォース管理ツールとの統合

サードパーティソリューション

カスタム統合の構築が過剰に思われる場合は、eesel AIのようなツールがこれらの制限なしに応答ベースの自動化を処理します。eesel AIは、独自のインフラストラクチャを介してチケットの更新をリアルタイムで処理するため、ネイティブのZendeskトリガーに影響を与える競合状態やタイミングの問題を回避できます。

eesel AIが応答ベースの自動化をどのように異なる方法で処理するか

ネイティブのZendeskトリガーは、単純な自動化には適していますが、高度な応答ベースのワークフローが必要な場合は機能しません。同じ問題に対する私たちのアプローチを次に示します。

競合状態なし。 当社独自のインフラストラクチャを介してチケットの更新を処理するため、API呼び出しやWebhookとの競合はありません。応答数は、チケットのステータスや更新ソースに関係なく正確です。

平易な英語のルール。 複数の条件で複雑なトリガーロジックを構成する代わりに、自然言語でエスカレーションルールを定義します。たとえば、「エージェントが3回以上応答し、チケットがまだオープンしている場合は、上級チームにエスカレーションします。」

自動学習。 当社のAIは、過去のチケットから学習してパターンを特定します。特定のタグが付いたチケットや特定の顧客からのチケットは、より多くの応答が必要になる傾向があることに気付き、しきい値に達する前にエスカレーションを積極的に提案する場合があります。

リアルタイム認識。 チケットの更新時にのみ起動するトリガーとは異なり、eesel AIはチケットの状態を継続的に監視します。これは、チケットが更新されたばかりでなくても、応答数に基づいてアクションを実行できることを意味します。

当社はZendeskと直接統合し、チケットを自律的に処理する最前線のAIエージェント、エージェントレビューのために応答を起草するAIコパイロット、またはその両方として動作できます。エスカレーションルールを定義すると、当社のAIはネイティブトリガーの技術的な制限なしにそれらに従います。

これがどのように機能するかを知りたい場合は、eesel AIを無料で試すか、デモを予約するして、特定のワークフローのニーズについて話し合うことができます。

エージェント応答トリガーのベストプラクティス

一般的な落とし穴とZendesk自身の推奨事項に基づいて、信頼性の高い応答ベースの自動化を構築するためのヒントを次に示します。

トリガーロジックをシンプルに保ちます。 追加する条件が多いほど、問題が発生した場合のトラブルシューティングが難しくなります。複雑なロジックが必要な場合は、1つの大規模なトリガーではなく、明確な命名規則を持つ複数のトリガーを使用することを検討してください。

展開する前に徹底的にテストします。 Zendeskのトリガーテストツールは限られています。実際のテストチケットを作成し、トリガーが処理するように設計されている正確なシナリオをウォークスルーします。

トリガーをドキュメント化します。 多数のトリガーがある場合、それぞれのトリガーが存在する理由を忘れがちです。ビジネスロジックを説明する説明を追加し、複雑なワークフローのために別のドキュメントシートを維持することを検討してください。

意図しない副作用を監視します。 トリガーは予期しない方法で相互作用する可能性があります。新しい応答ベースのトリガーを展開した後、数日間チケットフローを監視して、不適切に起動していないことを確認します。

時間ベースのフォローアップに自動化を検討します。 トリガーはチケットの更新時に起動しますが、時間ベースのロジックが必要になる場合があります。応答トリガーをZendesk自動化と組み合わせて、完全にカバーします。たとえば、トリガーは3つの応答後にチケットにタグを付け、自動化は解決せずにそのタグが24時間存在する場合にエスカレーションする場合があります。