ステータスが保留中に変わったときにZendeskトリガーを作成する方法

サポートチームが1日に数十または数百のチケットを処理する場合、おそらく何か迷惑なことに気づいているでしょう。エージェントがチケットに返信するたびに、ステータスを手動で「保留中」に変更する必要があります。これは小さなクリックですが、積み重なります。数千枚のチケットでは、これらの余分な数秒が時間の浪費になります。

朗報があります。これを自動化できます。Zendeskのトリガーを使用すると、エージェントが返信を送信するときに、チケットのステータスを自動的に保留中に設定できます。ドロップダウンメニューはもう必要ありません。ステータスの変更を忘れることもありません。スムーズで自動化されたワークフローだけです。

このガイドでは、ステータスが保留中に変わったときにZendeskトリガーを作成する方法について説明します。必要な正確な条件、トリガーを壊す一般的な間違い、および公開する前にすべてをテストする方法について説明します。また、eesel AIのような最新のAIツールが、トリガー構成なしでステータス管理を処理する方法についても見ていきます。

必要なもの

トリガーの構築を開始する前に、次のものがあることを確認してください。

• Teamプラン以上のZendesk Supportアカウント（トリガーはすべてのプランに含まれています）
• Zendeskインスタンスの管理者権限またはトリガー管理権限
• チームがチケットを保留中に設定するタイミングの明確な理解
• 構成とテストに約5〜10分

それだけです。コーディングスキルや技術的な専門知識は必要ありません。Zendeskトリガーは、開発者ではなく管理者向けに構築されています。

Zendeskチケットステータスの理解

効果的なトリガーを構築するには、Zendeskステータスがどのように機能するかを理解する必要があります。チケットステータスを単純なワークフローパイプラインと考えてください。

新規とは、チケットが到着したばかりで、まだ割り当てられていないことを意味します。エージェントがそれを受け取ると、ステータスはオープンに変わります。これは、チケットが処理中であることを全員に伝えます。

保留中は、物事が面白くなるところです。このステータスは、エージェントが返信し、顧客の応答を待っていることを意味します。ほとんどのSLAポリシーは、チケットが保留中の間、カウントダウンを一時停止するため、これは重要なステータスです。つまり、チームは顧客を待つために費やした時間に対してペナルティを受けません。

解決済みは、エージェントが問題を解決したと考えていることを示します。クローズは最終状態であり、通常、チケットが数日間解決された後に自動的にトリガーされます。

トリガーと自動化の違いが重要です。トリガーは、条件が満たされるとすぐに起動します。たとえば、エージェントが返信を送信したときなどです。自動化はスケジュールに従って実行され、1時間ごとに条件を確認します。エージェントのアクションに基づくステータスの変更には、トリガーが必要です。

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

始めましょう。まず、Zendeskでトリガーが存在する場所に移動する必要があります。

1. 上部のナビゲーションバーにある管理センターアイコンをクリックします。
2. 左側のサイドバーで、オブジェクトとルールを見つけます。
3. その上にカーソルを置き、ビジネスルールを選択します。
4. トリガーをクリックします。
5. チケットタブ（メッセージングトリガーではない）にいることを確認します。

既存のトリガーのリストが表示されます。Zendeskは、新しいアカウントに対して、「コメントの更新をリクエスタに通知する」など、いくつかの標準トリガーを作成します。時間をかけて、すでにそこにあるものを確認してください。既存のトリガーと競合するトリガーを作成することは避けてください。

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

次に、トリガーを構築しましょう。

右上にあるトリガーを追加ボタンをクリックします。いくつかのフィールドがあるフォームが表示されます。

**トリガー名：**チームが理解できる説明的なものを使用します。「エージェントの返信時に自動的に保留中に設定」がうまく機能します。「トリガー1」や「保留中のステータス」のようなあいまいな名前は避けてください。

**説明：**このトリガーが何をするのか、なぜ存在するのかを簡単に説明します。これにより、将来の管理者は条件をリバースエンジニアリングすることなく、ロジックを理解できます。次のようなもの：「エージェントが公開コメントを送信すると、チケットのステータスを自動的に保留中に変更します。エージェントは、すべての返信でステータスを手動で選択する必要がなくなります。」

**カテゴリ：**Zendeskインスタンスがトリガーカテゴリを使用している場合は、「ステータス管理」や「エージェントワークフロー」のような適切なカテゴリに割り当てます。

今のところ、トリガーを非アクティブのままにします。アクティブ化する前にテストします。

ステップ3：ステータスが保留中に変わったときにZendeskトリガーのトリガー条件を構成する

これは、ロジックがまとまるところです。条件は、Zendeskにトリガーを起動するタイミングを正確に伝えます。

次のすべての条件を満たすで、次の3つの条件を追加します。

**条件1：**チケット>ステータス|は|オープン

これにより、トリガーが現在オープンになっているチケットでのみ実行されるようになります。トリガーが新規チケット（最初にオープンになるはずです）またはすでに保留中、解決済み、またはクローズステータスになっているチケットで起動するのを防ぎます。

**条件2：**チケット>コメント|は|公開

この条件は、更新に公開コメントが含まれているかどうかを確認します。つまり、エージェントが実際に顧客に返信したかどうかを確認します。これがないと、トリガーは内部メモやエージェントの返信を表さない他の更新で起動する可能性があります。

**条件3：**現在のユーザー|は|（エージェント）

これが重要なものです。この条件は、トリガーが顧客の返信時ではなく、エージェントが更新を行った場合にのみ起動するようにします。この条件がないと、深刻な問題が発生します。顧客が保留中のチケットに応答すると、トリガーはオープンになるのではなく、保留中に戻し続けます。

各条件が重要な理由を分解してみましょう。ステータス条件は、どのチケットが対象となるかを定義します。コメント条件は、実際のコミュニケーションが発生していることを確認します。現在のユーザー条件は、トリガーが顧客のアクションを妨げるのを防ぎます。

一部の管理者は、「ステータス|変更された|オープン」を「ステータス|は|オープン」の代わりに使用することを好みます。違いは微妙です。「は」は現在の状態を確認し、「変更された」はステータスが移行したばかりかどうかを確認します。ほとんどのユースケースでは、「は」がうまく機能し、制限が少なくなります。

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

条件は、トリガーがいつ起動するかを定義します。アクションは、何が起こるかを定義します。

アクションで、次を追加します。

**アクション：**チケット>ステータス|設定|保留中

それがコアアクションです。ただし、ワークフローで必要な場合は、さらに追加できます。

• **タグを追加：**レポート用に「agent_replied」でチケットにタグを付けます
• タグを削除：「awaiting_agent」タグを使用している場合はクリアします
• **ターゲットに通知：**外部システムにWebhookを送信します
• **コメントを追加：**他のエージェントのために内部メモを挿入します

アクションは、表示される順序で実行されます。複数のアクションがある場合は、それらを正しい順序にドラッグします。

保存する前に、条件とアクションを再確認してください。1つの設定を間違えると、チケットワークフロー全体で予期しない動作が発生する可能性があります。

ステップ5：ステータスが保留中に変わったときにZendeskトリガーをテストしてアクティブ化する

最初にテストせずにトリガーをアクティブ化しないでください。すべてが機能することを確認する方法は次のとおりです。

1. **トリガーを非アクティブとして保存します。**保存ボタンの横にあるドロップダウンをクリックし、「非アクティブとして作成」を選択します。

2. **テストチケットを作成します。**エンドユーザーとしてチケットを送信し、エージェントとして開きます。

3. **公開返信を送信します。**コメントを入力し、オープン（デフォルト）として送信します。

4. **チケットイベントを確認します。**チケットの一番下までスクロールし、イベントをクリックします。トリガーがチェックマーク付きでリストされているはずです。これは、トリガーが正常に起動したことを示しています。

5. **ステータスが変更されたことを確認します。**チケットのステータスが保留中になっているはずです。

6. **ネガティブケースをテストします。**誰かにエンドユーザーとしてチケットを送信させ、そのエンドユーザーとして返信させます。ステータスはオープンに変更されるはずです（保留中のままではありません）。これは、「現在のユーザーはエージェントです」という条件が機能していることを証明しています。

すべてが機能することを確認したら、トリガーを編集してアクティブ化します。最初の数日間はチケットを監視して、見逃したエッジケースをキャッチします。

一般的な間違いとその回避方法

経験豊富なZendesk管理者でも、これらの間違いを犯します。注意すべき点は次のとおりです。

間違い1：「現在のユーザーはエージェントです」を忘れる

これが最も一般的なエラーです。この条件がないと、顧客が保留中のチケットに返信すると、ステータスはオープンになるのではなく、保留中のままになります。エージェントは更新を見ることができません。チケットは気づかれずに放置されます。常にこの条件を含めてください。

間違い2：「ステータスが変更されました」を誤って使用する

「ステータス|変更された|オープン」は、チケットがオープンのステータスに移行したときにのみ起動します。チケットがすでにオープンでコメントを受け取った場合、この条件は満たされません。ほとんどの自動保留ユースケースでは、「ステータス|は|オープン」の方がうまく機能します。

間違い3：競合するトリガーを作成する

ステータスを変更する複数のトリガーがある場合、それらは競合する可能性があります。1つのトリガーがステータスを保留中に設定し、別のトリガーがステータスを別のものに設定します。トリガーリストで重複する条件を確認してください。Zendeskはトリガーを表示される順序で処理するため、位置が重要です。

間違い4：異なるユーザータイプでテストしない

エージェント、エンドユーザー、および管理者としてテストします。各ユーザータイプは、権限設定に応じて異なる動作をする可能性があります。

**トラブルシューティングのヒント：**トリガーが誤動作する場合は、チケットイベントログを確認してください。これにより、起動したすべてのトリガーと、条件が満たされたかどうかが表示されます。これは、デバッグの最初のステップです。

ステータスが保留中に変わったときにZendeskトリガーの高度なバリエーション

基本的なトリガーが機能したら、次の拡張機能を検討してください。

チケットタイプによる条件付き自動保留：「チケット>タイプ|は|質問」のような条件を追加して、特定のチケットタイプのみを自動保留にします。技術的な問題は、追跡のためにオープンにしておく必要がある場合があります。

グループ固有のトリガー：「チケット>グループ|は|[特定のグループ]」を追加して、特定のチームのみが自動保留動作を取得するようにします。営業チームは、サポートチームとは異なるワークフローを必要とする場合があります。

営業時間のみ：「チケット>営業時間内ですか？|は|はい」を追加して、営業時間外のステータス変更を防ぎます。これは、SLA計算に役立ちます。

**タグベースのワークフロー：**ステータストリガーをタグと組み合わせます。トリガーが起動したら、「pending_sent」のようなタグを追加します。次に、そのタグが付いているがステータスがオープンのすべてのチケットを表示するビューを作成します（トリガーが失敗したか、バイパスされたことを示します）。

**メッセージングチャネルのサポート：**Zendeskメッセージングを使用している場合は、メッセージングセッションの状態条件を使用して、同様のトリガーを作成できます。非アクティブな会話を、一定期間非アクティブになった後、自動的に保留中に設定します。

代替案：eesel AIを使用したステータス管理の自動化

トリガーは機能しますが、制限があります。それらはルールベースです。つまり、指定した正確な条件に従います。コンテキストを解釈したり、会話のニュアンスを理解したりすることはできません。

ここで、eesel AIが異なるアプローチを取ります。トリガーを構成する代わりに、ワークフローを学習するAIチームメイトとしてeeselを雇います。

仕組みは次のとおりです。eeselはZendeskインスタンスに接続し、過去のチケット、ヘルプセンターの記事、およびマクロを読み取ります。チームがどのようにコミュニケーションを取り、コンテキストでステータス変更が何を意味するかを学習します。次に、ステータス管理を含むチケットを自律的に処理します。

重要な違い：eeselは実際