ステータスが「オープン」に変更されたときにZendeskトリガーを作成する方法

ヘルプデスクで適切な自動化を設定すると、毎週手作業の時間を節約できます。作成できる最も便利な自動化の1つは、チケットのステータスが「オープン」に変更されたときに発動するトリガーです。この簡単な設定により、エージェントに顧客の返信を通知したり、再オープンされたチケットをエスカレーションしたり、サポートワークフローをスムーズに実行したりできます。

このガイドでは、チケットのステータスが「オープン」に変更されたときに反応するZendesk（ゼンデスク）トリガーを作成するために知っておくべきことをすべて説明します。トリガーの仕組みを学び、ステップバイステップの設定手順を確認し、一般的なユースケースを調べ、トリガーが期待どおりに発動しない場合に問題をトラブルシューティングする方法を発見します。

Zendesk（ゼンデスク）の管理が初めての場合でも、既存の設定を改善したい場合でも、これらのテクニックは、より効率的なサポート業務を構築するのに役立ちます。

Zendesk（ゼンデスク）のチケットステータスとトリガーについて

トリガーの作成に入る前に、Zendesk（ゼンデスク）でチケットステータスがどのように機能するかを理解しておくと役立ちます。すべてのチケットは、ステータスによって定義されたライフサイクルを通過し、各ステータスはサポートワークフローの特定の状態を表します。

Zendesk（ゼンデスク）は、5つの標準チケットステータスを使用します。

• 新規（New）　チケットは作成されましたが、まだエージェントに割り当てられていません。これは、すべての受信リクエストの開始点です。
• オープン（Open）　チケットはエージェントに割り当てられ、積極的に作業中です。
• 保留中（Pending）　エージェントはリクエスターからの情報を待っています。チケットは顧客が応答するまで保留になります。
• 保留（On-hold）　保留中（Pending）と同様ですが、待機は（リクエスターではなく）サードパーティに対して行われます。これは、顧客には表示されない内部ステータスです。
• 解決済（Solved）　エージェントはソリューションを送信し、問題が解決されたと考えています。
• クローズ（Closed）　チケットはロックされており、変更できません。チケットは、解決済（Solved）ステータスで設定された期間が経過すると自動的にクローズされます。

一部のステータス変更は自動的に行われます。エージェントが新規（New）チケットに割り当てられると、ステータスはオープン（Open）に変更されます。顧客が保留中（Pending）チケットに返信すると、ステータスは自動的にオープン（Open）に戻ります。これらの組み込みルールにより、ワークフローが論理的な進行に従うことが保証されます。

トリガーは、特定の条件が満たされたときにアクションを自動化するためのZendesk（ゼンデスク）のメカニズムです。（スケジュールで実行される）自動化とは異なり、トリガーはチケットが作成または更新されたときにすぐに発動します。トリガーをチケットの「もしこれなら、あれ」ルールと考えてください。

このガイドの重要な区別は、「ステータスが変更された」と「ステータスは」の違いです。「変更された」条件は、更新中にステータスフィールドが特定の値に移行した場合にのみ発動します。「ステータスは」条件は現在の状態を確認しますが、変更は検出しません。チケットが再オープンされたことを検出するには、「ステータスがオープンに変更された」を使用します。

必要なもの

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

• Teamプラン以上のZendesk Supportアカウント（トリガーはすべての有料プランで利用できます）
• 管理者権限またはトリガーを管理する権限を持つロール
• トリガーが発動したときに何が起こるかを明確に理解していること
• 管理センター（Zendesk（ゼンデスク）ナビゲーションの歯車アイコン）へのアクセス

コーディングの知識やサードパーティツールは必要ありません。すべてZendesk（ゼンデスク）の標準インターフェイス内で発生します。詳細な参考資料については、Zendesk（ゼンデスク）トリガーのドキュメントを参照してください。

ステップバイステップ：ステータスが「オープン」に変更されたときにZendesk（ゼンデスク）トリガーを作成する

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

上部のナビゲーションバーにある歯車アイコンをクリックして、管理センターに移動します。左側のサイドバーで、オブジェクトとルールをクリックし、次にビジネスルールを選択し、その後にトリガーを選択します。最後に、チケットタブをクリックして、既存のトリガーを表示します。

現在（いま）のトリガーのリストが表示されます。これには、アカウントを設定したときにZendesk（ゼンデスク）が作成した標準トリガーが含まれます。これらのデフォルトトリガーは、チケットの受信確認や更新の担当者への警告などの基本的な通知を処理します。

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

右上隅にあるトリガーを追加ボタンをクリックします。新しいトリガーを構成できるフォームが表示されます。

まず、トリガーにわかりやすい名前を付けます。良い名前は、トリガーの機能を明確に説明しています。例：

• 「顧客が返信したときに担当者に通知する」
• 「再オープンされたチケットを優先度高にエスカレーションする」
• 「解決済（Solved）から再オープンされたチケットにタグを付ける」

名前だけではトリガーの目的を完全に説明できない場合は、オプションの説明を追加します。これにより、他の管理者はトリガーが存在する理由と、いつ発動する必要があるかを理解できます。

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

ここでは、トリガーがいつ発動するかを定義します。条件は2つのセクションに分割されています。

次のすべての条件を満たす（Meet ALL of the following conditions）　トリガーが発動するには、ここにあるすべての条件がtrueである必要があります。

次のいずれかの条件を満たす（Meet ANY of the following conditions）　少なくとも1つの条件がtrueである必要があります（オプションのセクション）。

基本的なステータス変更トリガーの場合は、「次のすべてを満たす（Meet ALL）」の下にこの条件を追加します。

• チケット（Ticket）＞ステータス（Status）＞変更された（Changed to）＞オープン（Open）

これにより、チケットのステータスフィールドが更新中にオープン（Open）に移行するたびにトリガーを発動するようにZendesk（ゼンデスク）に指示します。

追加の条件を追加して、トリガーをより具体的にすることができます。一般的な組み合わせを次に示します。

顧客の返信を検出するには：

• チケット（Ticket）＞ステータス（Status）＞変更された（Changed to）＞オープン（Open）
• チケットの詳細（Ticket details）＞現在のユーザー（Current user）＞である（Is）＞（エンドユーザー）

解決済（Solved）から再オープンされたチケットをキャッチするには：

• チケット（Ticket）＞ステータス（Status）＞変更された（Changed to）＞オープン（Open）
• チケット（Ticket）＞タグ（Tags）＞次のいずれかを含む（Contains at least one of the following）＞解決済（solved）

特定のグループをターゲットにするには：

• チケット（Ticket）＞ステータス（Status）＞変更された（Changed to）＞オープン（Open）
• チケット（Ticket）＞グループ（Group）＞である（Is）＞[グループ名]

トリガーは、チケットの更新直後に条件を評価することを忘れないでください。「変更された（Changed to）」演算子は、特に移行を探すため、すでにオープン（Open）になっているチケットでは発動しません。

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

条件が満たされたときに何が起こるかを定義します。アクションセクションは、条件と同様に機能します。Zendesk（ゼンデスク）が自動的に実行する1つ以上のアクションを追加します。

ステータス変更トリガーの一般的なアクションは次のとおりです。

割り当てられたエージェントに通知する：

• 通知方法（Notify by）＞ユーザーメール（User email）＞（担当者（assignee））
• 件名：「チケットが再オープンされました：{{ticket.title}}」
• 本文：プレースホルダーを使用して関連するチケットの詳細を含めます

Slackに投稿する：

• 通知方法（Notify by）＞Zendesk（ゼンデスク）連携（Zendesk integration）＞Slack連携（Slack integration）
• 適切なチャネルに投稿するようにSlack Webhookを構成します

レポート用にタグを追加する：

• チケット（Ticket）＞タグを追加（Add tags）＞再オープン（reopened）
• これにより、チケットが再オープンされる頻度を追跡できます

優先度をエスカレーションする：

• チケット（Ticket）＞優先度（Priority）＞高（High）
• 緊急の再オープンシナリオに使用します

内部メモを追加する：

• チケット（Ticket）＞内部メモ（Internal note）＞「{{ticket.updated_at}}にチケットが再オープンされました」
• これにより、チケットに監査証跡が作成されます

1つのトリガーで複数のアクションを組み合わせることができます。たとえば、担当者に通知し、「再オープン（reopened）」タグを追加し、優先度を一度にエスカレーションすることができます。

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

**作成（Create）**をクリックして、トリガーを保存します。トリガーがアクティブになり、条件が満たされると発動します。

本番環境でトリガーに依存する前に、テストします。

1. テストチケットを作成するか、既存のチケットを使用します
2. チケットを保留中（Pending）ステータスに設定します
3. エンドユーザーとして公開コメントを追加します（シークレットウィンドウまたは別のアカウントを使用する必要がある場合があります）
4. ステータスがオープン（Open）に変更されることを確認します
5. トリガーアクションが実行されたことを確認します（メール、Slack、タグなどを確認します）

トリガーが期待どおりに発動しない場合は、チケットのイベントログを確認します。どのトリガーがどの順序で実行されたかを正確に確認できます。これは、別のトリガーが干渉しているか、条件が満たされていないかを特定するのに役立ちます。

重要な詳細の1つ：トリガーの位置が重要です。Zendesk（ゼンデスク）は、リストに表示される順序でトリガーを評価します。2つのトリガーが競合する可能性がある場合、位置番号が低いトリガーが最初に実行されます。トリガーリストでトリガーをドラッグして、トリガーの順序を変更できます。

ネイティブトリガーだけでは不十分な場合：代替としてのeesel AI

Zendesk（ゼンデスク）トリガーは、簡単な自動化には強力ですが、制限があります。正確なフィールドマッチングに依存しており、コンテキストや意図を理解できません。ここで、eesel AIが別のアプローチを提供します。

Zendesk（ゼンデスク）トリガーを使用すると、厳密な条件ロジックに制限されます。不満を抱いた顧客が再オープンした場合にのみチケットをエスカレーションしたい場合、ネイティブトリガーで感情やトーンを簡単に検出することはできません。複雑なタグベースの回避策またはサードパーティアプリが必要になります。

当社のAIエージェントは、ステータス変更を異なる方法で処理します。フィールド値を照合する代わりに、eesel AIは過去のチケットデータから学習して、さまざまなタイプの再オープンイベントの意味を理解します。顧客の返信の内容を読み取り、不満、緊急性、または満足度を検出し、インテリジェントなルーティングの決定を行うことができます。

たとえば、次のような自然言語の指示を設定できます。

• 「チケットが再オープンされ、顧客が「緊急」または「不満」について言及した場合、シニアチームにエスカレーションし、優先度を「高」に設定します。」
• 「解決済（Solved）チケットが請求に関する質問で再オープンされた場合、元のエージェントではなく、財務チームに直接割り当てます。」
• 「VIP顧客の場合、チケットが再オープンされた場合は、アカウントマネージャーに完全なコンテキストを添えてすぐに通知します。」

これらは、複雑なタグ条件を持つ複数のトリガーではありません。これらは、eesel AIが解釈して実行する単一の読みやすい指示です。

もう1つの利点は、継続的な学習です。従来のトリガーでは、エスカレーションの動作を変更する場合は、各トリガーを手動で編集します。eesel AIを使用すると、指示を平易な英語で更新すると、AIがすべてのワークフローにすぐに変更を適用します。

Zendesk（ゼンデスク）トリガーが扱いにくくなっている場合、または単純なフィールド値を超えたコンテキストを理解する自動化が必要な場合は、eesel AIがZendesk（ゼンデスク）と直接統合し、複雑なトリガー設定を補完または置き換えることができます。

ステータスが「オープン」に変更されたときのZendesk（ゼンデスク）トリガーの一般的なユースケース

顧客が返信したときにエージェントに通知する

これは最も一般的なユースケースです。顧客が保留中（Pending）チケットに応答すると、ステータスは自動的にオープン（Open）に変更されます。トリガーは、割り当てられたエージェントにすぐに通知できます。

構成：

• 条件：ステータスがオープンに変更された（Status Changed to Open）+現在のユーザーである（Current user Is）（エンドユーザー）
• アクション：メールで担当者に通知する

これにより、エージェントは顧客がフォローアップしたときにすぐに把握し、応答時間を短縮し、チケットが気付かれずに放置されるのを防ぎます。

再オープンされたチケットをエスカレーションする

一部のチケットは、注意を払わずに再オープンしないでください。チケットが解決済（Solved）からオープン（Open）に戻ると、多くの場合、ソリューションが機能しなかったか、顧客が関連する問題を抱えていることを示します。

構成：

• 条件：ステータスがオープンに変更された（Status Changed to Open）+以前のステータスが解決済（Solved）だった
• アクション：優先度を「高（High）」に設定+マネージャーに通知+「再オープン（reopened）」タグを追加

このアプローチは、再オープンされたチケットを適切な緊急性で扱い、マネージャーが解決品質を追跡するのに役立ちます。

レポート用にチケットの再オープンを追跡する

チケットが再オープンされる頻度を理解することは、サポート品質を測定するのに役立ちます。再オープン率が高い場合は、トレーニングのニーズまたはプロセスの問題を示している可能性があります。

構成：

• 条件：ステータスがオープンに変更された（Status Changed to Open）
• アクション：「再オープン（reopened）」タグを追加+タイムスタンプ付きの内部メモを追加

次に、Zendesk（ゼンデスク）Exploreでレポートを作成して、エージェント、カテゴリ、または期間ごとの再オープン率を分析できます。

再オープンされたチケットを自動割り当てする

チケットが担当者なしで再オープンされることがあります。これは、APIの更新、一括操作、またはシステム連携で発生する可能性があります。トリガーは、これらのチケットが利用可能なエージェントに割り当てられるようにすることができます。

構成：

• 条件：ステータスがオープンに変更された（Status Changed to Open）+担当者が（-）である
• アクション：特定のグループまたはエージェントに割り当てる

これにより、割り当てられていない孤立したチケットがキューに放置されるのを防ぎます。

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

単純なトリガーでさえ、期待どおりに機能しない場合があります。最も一般的な問題の解決策を次に示します。

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

トリガーが発動しない場合は、次の項目を確認してください。

**トリガーの位置：**位置の高いトリガーが最初に実行されます。別のトリガーが条件を変更する方法でチケットを変更した場合、トリガーが発動しない可能性があります。トリガーをリストの上位に移動してみてください。

条件ロジック：「次のすべてを満たす（Meet ALL）」と「次のいずれかを満たす（Meet ANY）」を正しく使用していることを確認してください。複数の条件がある場合は、すべてが満たされている（すべて（ALL）の場合）か、少なくとも1つが一致している（いずれか（ANY）の場合）必要があります。

**評価のタイミング：**トリガーは、チケットの更新直後に評価します。後続の更新でチケットが再度変更された場合、トリガーの機会の窓は過ぎます。

**チケットイベントの確認：**ルールを発動する必要があったチケットを開き、イベントログをクリックします。発動したすべてのトリガーとその結果を確認できます。

ステータスは変更されたが、通知が送信されない

トリガーは発動するが、メールが届かない場合：

**スパムフィルターを確認する：**Zendesk（ゼンデスク）の通知メールがスパムに分類されることがあります。Zendesk（ゼンデスク）のメールドメインをホワイトリストに登録します。

**公開コメントを確認する：**ほとんどのメール通知アクションは、チケットの更新に公開コメントが含まれている場合にのみ送信されます。非公開コメントまたはフィールドのみの更新は、多くの場合、通知を抑制します。

**抑制ルールを確認する：**Zendesk（ゼンデスク）には、重複するメールを防ぐための組み込みの抑制があります。更新が通知を受信するのと同じ人から来た場合、抑制される可能性があります。

メールアクションの構成を確認する：「通知方法（Notify by）＞ユーザーメール（User email）」アクションに有効な受信者が選択されており、メール本文が空でないことを確認します。

チケットのステータスが予期せず変更される

予期しないときにチケットのステータスが変更されることがあります。一般的な原因は次のとおりです。

**標準トリガー：**Zendesk（ゼンデスク）の組み込みトリガーは、特定のシナリオでステータスを自動的に変更します。標準トリガーを確認して、デフォルトの動作を理解してください。

**API連携：**サードパーティアプリと連携は、多くの場合、APIを介してチケットを更新します。APIアクティビティを示す「Webサービスによる（By Web Service）」エントリのイベントログを確認します。

**ライトバック連携：**アンケート結果をチケットに書き戻すCustomer Thermometerのようなツールは、誤って解決済（Solved）チケットを再オープンする可能性があります。アンケート後にチケットが再オープンされる場合は、これらの更新をキャッチし、ステータスを解決済（Solved）のままにするトリガーを作成します。

**エージェントリクエスター：**更新を送信する人がZendesk（ゼンデスク）のエージェントでもある場合、ステータス変更の動作はエンドユーザーの更新とは異なります。

高度なヒントとベストプラクティス

基本的なステータス変更トリガーをマスターしたら、次の高度なテクニックを検討してください。

**トリガーカテゴリを使用する：**トリガーを「通知」、「ルーティング」、「SLA管理」などのカテゴリに整理します。これにより、トリガーリストが増えるにつれてメンテナンスが容易になります。

**トリガーを文書化する：**説明フィールドを使用して、各トリガーが存在する理由、誰が要求したか、いつ作成されたかを説明します。将来のあなた（および他の管理者）はあなたに感謝するでしょう。

**サンドボックスでテストする：**Zendesk（ゼンデスク）サンドボックス環境がある場合は、最初にそこで複雑なトリガーをテストします。これにより、本番アカウントでの予期しない動作を防ぎます。

**トリガーのパフォーマンスを監視する：**まれですが、多数の複雑なトリガーはチケット処理を遅くする可能性があります。遅延に気付いた場合は、トリガーを監査し、冗長または不要になったトリガーを削除します。

**条件を戦略的に組み合わせる：**最も役立つトリガーは、多くの場合、複数の条件があります。たとえば、「ステータスがオープンに変更された（Status Changed to Open）」と「タグにVIPが含まれている（Tags contains VIP）」と「現在のユーザーがエンドユーザーである（Current user is end user）」を組み合わせると、高価値の顧客の返信に対して高度にターゲットを絞った通知が作成されます。

今すぐZendesk（ゼンデスク）ワークフローの自動化を開始する

ステータスが「オープン」に変更されたときにZendesk（ゼンデスク）トリガーを作成することは、メカニズムを理解すれば簡単です。重要なのは、顧客の返信についてエージェントに通知したり、再オープンされたチケットをエスカレーションしたり、解決品質を追跡したりするなど、特定のユースケースに適切な条件を一致させることです。

最も差し迫ったニーズを解決する簡単なトリガーから始めます。徹底的にテストしてから、自動化を徐々に拡張します。最高のトリガー設定は、サポート業務とともに進化することを忘れないでください。

回避策やタグベースのロジックを使用して、ますます複雑なトリガーを構築している場合は、AI搭載の代替手段を検討する時期かもしれません。コンテキストと意図を理解するインテリジェントな自動化のためにeesel AIをお試しください。フィールド値だけでなく。