すべてのサポートチケットは、ある道のりをたどります。顧客がリクエストを「送信」した瞬間から最終的な解決まで、各チケットは、チームが組織化され、顧客が常に情報を把握できるように、明確な段階を経ます。この道のり、つまりZendesk（ゼンデスク）チケットライフサイクルを理解することは、効率的なサポート業務を行う上で不可欠です。
Zendeskを初めて使用する場合でも、既存のワークフローを最適化したい場合でも、このガイドでは、チケットが作成からクローズまでどのように移行するかについて知っておく必要のあるすべてのことを解説します。6つの標準ステータス、それらの接続方法、およびチームがよく行き詰まる場所について説明します。また、eesel AIがこれらのワークフローを効率化し、チケットをスムーズに動かし続けるのにどのように役立つかについても見ていきます。
Zendeskチケットライフサイクルとは？
チケットライフサイクルとは、すべてのサポートリクエストがZendeskインスタンスを通過する経路のことです。サポート業務の心臓部と考えてください。ライフサイクルの各段階には特定の目的があります。それは、チームに次に何をする必要があるかを伝え、顧客に進捗状況を知らせることです。
ライフサイクルを理解すると、ボトルネックが問題になる前に見つけることができます。保留中のチケットが長すぎる？それはシグナルです。再オープンされたチケットが積み上がっている？別のシグナルです。ライフサイクルは単なる管理上のオーバーヘッドではありません。サポートプロセスがどれだけうまく機能しているかを明らかにする診断ツールです。
改善を目指すチームにとって、ライフサイクルを正しく理解することは、解決時間の短縮、顧客満足度の向上、キューの混乱の軽減につながります。eesel AIなどのツールは、ステータスの移行を自動化し、チケットが抜け落ちないようにすることで役立ちます。
6つの標準的なZendeskチケットステータスの説明
Zendeskでは、6つの標準ステータスを使用して、チケットがライフサイクルのどこにあるかを追跡します。各ステータスには視覚的なインジケーター（色付きのドット）があり、キューを簡単にスキャンして、チケットの状態を一目で理解できます。
新規（オレンジ色のインジケーター）
「新規」ステータスは、エージェントがまだチケットに触れていないことを意味します。すべてのチケットは、メール、ウェブフォーム、チャット、電話など、どのように到着したかに関係なく、ここから始まります。オレンジ色のインジケーターにより、これらのチケットはビューで見つけやすくなっています。
ここで重要なことがあります。チケットが新規から移動すると、元に戻すことはできません。これにより、チケットが解決されずに無限にサイクルするのを防ぎます。エージェントが新規チケットに自分自身を割り当てると、自動的にオープンになります。
オープン（赤色のインジケーター）
オープンチケットには担当者がいます。エージェントは積極的にそれに取り組み、解決策を調査したり、応答を準備したりしています。赤いインジケーターは、このチケットが注意を必要としていることを示しています。
オープンチケットは個人のキューに表示され、ワークロードにカウントされます。これは、実際のサポート作業のほとんどが行われる場所です。チケットは、解決されるまでにオープンと保留の間を何度も行き来する可能性があります。
保留中（青色のインジケーター）
保留中とは、顧客を待っていることを意味します。おそらく、詳細情報を求めたり、解決策を送信して、それが機能するかどうかを聞くのを待っています。青色のインジケーターは、ボールが顧客のコートにあることを示しています。
ここで重要な詳細：保留中のステータスは、SLAタイマーを一時停止します。顧客がどれだけ早く応答するかを制御できないため、これは公平です。顧客が返信すると、チケットは自動的にオープンにリセットされます。
保留（濃い灰色のインジケーター）
保留は保留中と似ていますが、顧客以外の誰かを待っています。おそらく、エンジニアリングからのインプットが必要だったり、ベンダーからの出荷を待っていたりします。濃い灰色のインジケーターは、これらを保留中のチケットと区別します。
これは、管理者が有効にする必要のあるオプションのステータスです。保留中とは異なり、保留はSLAタイマーを一時停止しません。これは、問題の解決に引き続き責任があるためです。また、顧客は保留中のチケットをビューで「オープン」として認識します。これは内部ステータスのみです。
解決済み（薄い灰色のインジケーター）
問題を解決したら、チケットを解決済みにマークします。これは、システム（および顧客）に、問題が修正されたと信じていることを伝えます。薄い灰色のインジケーターは、チケットが基本的に完了していることを示しています。
顧客は、解決済みのチケットに返信することで再オープンできます。これは、解決策が機能しなかった場合、または関連する問題が発生した場合に役立ちます。多くのチームは、チケットが解決済みに移行すると、CSAT（顧客満足度）調査をトリガーします。
クローズ（薄い灰色のインジケーター）
クローズは終点です。チケットを手動でクローズに設定することはできません。代わりに、自動化により、設定された期間（デフォルトは4日間）解決済みになった後、自動的にクローズされます。クローズされると、チケットは読み取り専用になります。
顧客は、クローズされたチケットを再オープンできません。返信すると、Zendeskは元のチケットにリンクする新しい「フォローアップ」チケットを作成します。これにより、古いチケットが再浮上するのを防ぎながら、履歴を保持します。
チケットがZendeskチケットライフサイクルをどのように移動するか
ステータスがわかったので、チケットが実際にステータス間をどのように流れるかを見てみましょう。
典型的な流れ
最も単純なパスは次のようになります。
新規 → オープン → 保留中 → 解決済み → クローズ
顧客がリクエストを送信します（新規）。エージェントがそれを受け取ります（オープン）。詳細情報が必要なため、質問をします（保留中）。顧客が返信し、エージェントが問題を解決します（解決済み）。4日後、システムがそれをクローズします（クローズ）。
この線形のパスは発生しますが、それが標準ではありません。
一般的なバリエーションとループ
ほとんどのチケットは、ステータス間を何度も行き来します。より現実的な例を次に示します。
- チケットが到着します（新規）
- エージェントが割り当てて作業を開始します（オープン）
- エージェントは明確化が必要です（保留中）
- 顧客が返信します（オープン）
- エージェントはエンジニアリングからのインプットが必要です（保留）
- エンジニアリングが応答します（オープン）
- エージェントが解決策を送信します（解決済み）
- 顧客はそれが機能しなかったと言います（オープン）
- エージェントが別の解決策を見つけます（解決済み）
- システムは4日後にクローズします（クローズ）
これらのループは正常です。これらは、複雑な問題が解決される方法です。重要なのは、チケットが特定のステータスで長時間スタックしないようにすることです。
自動ステータス変更と手動ステータス変更
エージェントは、ほとんどのステータス変更を直接制御します。「送信」ボタンのドロップダウンを使用して、チケットを手動でオープン、保留中、保留、または解決済みに設定します。
ただし、2つのステータスはシステムによって制御されます。
- 新規：チケットが到着すると自動的に設定されます
- クローズ：解決済み期間が終了した後、自動化によって自動的に設定されます
この分割された設計により、ライフサイクルが動き続けます。エージェントは問題の解決に集中し、システムは解決済みのチケットをクローズする管理作業を処理します。
Zendeskチケットライフサイクルにおけるタイミングルールと自動化
ステータス変更はランダムに発生するわけではありません。キューを正常に保つルールによって管理されています。
チケットが自動的にクローズされるタイミング
デフォルトでは、Zendeskは、チケットが解決済みにマークされてから4日後にクローズします。これは構成可能で、数時間から最大28日まで設定できます。
なぜ28日？それはオーバーライドできないシステムルールです。チケットをクローズする自動化を無効にした場合でも、Zendeskは28日後に自動的にクローズします。これにより、解決済みのチケットが無期限にオープンしたままになるのを防ぎます。
アーカイブの考慮事項
クローズステータスで120日後、チケットはアーカイブされます。これは、次の2つの理由で重要です。
まず、アーカイブされたチケットは、ストレージ制限に引き続きカウントされます。次に、アーカイブされたチケットで自動化を実行することはできません。それらは基本的に読み取り専用の履歴レコードになります。
古いチケットを定期的に参照する必要がある場合は、アーカイブされたチケット検索に頼るのではなく、エクスポートするか、Zendeskのレポートツールを使用することを検討してください。
トリガーと自動化の使用
トリガーと自動化は、ライフサイクルを自動的に機能させるものです。
トリガーは、何かが発生するとすぐに発動します。例：
- チケットが作成されたら、自動返信を送信します
- チケットが緊急に設定されたら、マネージャーに通知します
- チケットが解決されたら、CSAT調査を送信します
自動化は、スケジュールに従って（通常は1時間ごと）実行され、時間ベースの条件を確認します。
- チケットが24時間オープンになっている場合は、上級エージェントにエスカレートします
- チケットが48時間保留中の場合は、リマインダーメールを送信します
- チケットが4日間解決済みの場合は、クローズします
これらのルールにより、チケットが動き続け、抜け落ちるのを防ぎます。それらがなければ、すべてのチケットの年齢とステータスを手動で監視する必要があります。
Zendeskチケットライフサイクルにおける再オープンされたチケットとフォローアップ
すべてのチケットがクローズへの幸せな道をたどるわけではありません。顧客がさらに支援を必要とする場合があります。
再オープンされたチケット
顧客が解決済みのチケットに返信すると、自動的に再オープンされます。チケットはオープンステータスに戻り、最初に解決したエージェントに割り当てられます。
これは、フォローアップの質問や、解決策が完全に機能しなかった場合に役立ちます。しかし、それは問題を示す可能性もあります。おそらく、エージェントがチケットを早まってクローズしたか、完全に解決されなかったより深い問題がある可能性があります。
一部のチームは、再オープン率を品質メトリックとして追跡します。高い再オープン率は、チームがより多くのトレーニングやより良いトラブルシューティングプロセスを必要としていることを意味する可能性があります。
フォローアップチケット
顧客がクローズされたチケットに返信すると、別のことが起こります。Zendeskは、再オープンする代わりに、元のチケットにリンクするまったく新しい「フォローアップ」チケットを作成します。
この区別が重要なのは、次の理由によります。
- クローズされたチケットは、永続的な記録を目的としています
- フォローアップは、新規ステータスで新たに開始されます
- エージェントは、リンクされた元のチケットから完全なコンテキストを取得します
フォローアップは、自動クローズ期間が終了した後も顧客が会話を続ける方法でもあります。顧客が5日目（4日間のクローズウィンドウの後）に返信すると、古いチケットを再オープンするのではなく、新しいフォローアップチケットが作成されます。
カスタムチケットステータス
6つの標準ステータスだけでは十分ではない場合があります。そこで、カスタムステータスが登場します。
カスタムステータスを使用すると、標準カテゴリにマッピングしながら、より具体的なワークフローステージを作成できます。たとえば、次のようなものを作成できます。
- 「払い戻し処理済み」（解決済みにマッピング）
- 「エンジニアリングにエスカレート」（保留にマッピング）
- 「ベンダーを待機中」（保留にマッピング）
これにより、エージェントはチケットで何が起こっているかについてより多くのコンテキストを得ることができます。また、レポートもより正確になります。チケットが保留中であるだけでなく、具体的にその理由を確認できます。
カスタムステータスは、ZendeskのProfessionalおよびEnterpriseプランで利用できます。有効にすると、標準ステータスは「ステータスカテゴリ」になり、カスタムステータスはそのカテゴリ内に配置されます。
出典：Zendeskカスタムチケットステータスのドキュメント
eesel AIでZendeskチケットライフサイクルを最適化する
チケットライフサイクルを手動で管理することは、小規模では問題なく機能します。しかし、チームが成長するにつれて、チケットが抜け落ち始めることがあります。そこで、AIが役立ちます。
eesel AIは、Zendeskインスタンスと連携して、ライフサイクル管理を自動化および最適化します。
インテリジェントなトリアージ：すべての新規チケットを手動でルーティングする代わりに、eesel AIはコンテンツを読み取り、トピック、感情、および緊急度に基づいて、適切なチームまたはエージェントに自動的に割り当てます。
スマートなステータス提案：eesel AIは、チケットのコンテンツを分析し、適切なステータスを提案できます。これは、解決済みに直接進むべき単純な質問ですか？それとも、フォローアップ作業のためにオープンにしておく必要がありますか？
スタックしたチケットの防止：eesel AIはキューを監視し、保留中または保留中の状態が長すぎるチケットにフラグを立てます。顧客または内部チームにプロアクティブなリマインダーを送信することもできます。
感情認識処理：顧客が解決済みのチケットに「ありがとうございます！」と返信した場合、eesel AIはこれをクローズの感情として認識し、不必要に再オープンする代わりにチケットをクローズしたままにします。
シミュレーションモード：ワークフローの変更を展開する前に、過去の数千件のチケットでテストして、どのように実行されたかを正確に確認できます。これにより、自信を持って最適化できます。
当社のAIエージェントは、最前線のサポートを自律的に処理し、当社のAIコパイロットは、人間のエージェントがレビューするための返信を下書きします。どちらもZendeskとシームレスに統合され、既存のライフサイクルルールを尊重します。
Zendeskチケットライフサイクルで避けるべき一般的な間違い
経験豊富なチームでも、これらの間違いを犯します。注意すべき点は次のとおりです。
保留中のチケットが長すぎる：顧客の返信を待っているチケットを忘れがちです。顧客が48時間以内に応答しない場合は、リマインダーを送信するか、エスカレートするように自動化を設定します。
保留の乱用：保留は、困難な作業を回避するためではなく、第三者を待つために使用する必要があります。数週間保留になっているチケットは、通常、顧客の問題ではなく、プロセスの問題を示しています。
適切な自動化ルールの設定を怠る：手動ステータス管理は拡張できません。チケットを手動でクローズしたり、リマインダーメールを1つずつ送信したりしている場合は、実際の問題の解決に費やすことができる時間を無駄にしています。
再オープンされたチケットのパターンを無視する：同じ種類のチケットが再オープンされ続ける場合は、対処する価値のある根本原因があります。カテゴリ別に再オープン率を追跡し、根本的な問題を修正します。
不十分なフォローアップチケット管理：フォローアップは、重要なコンテキストを持つ新しいチケットです。チームが応答する前に、リンクされた元のチケットを確認することを知っていることを確認してください。
今すぐZendeskチケットライフサイクル管理を改善しましょう
Zendeskチケットライフサイクルは、単なるステータスのセットではありません。それはあなたのサポート業務のバックボーンです。チケットが新規からクローズまでどのように流れるかを理解すると、問題を早期に発見し、ルーチンワークを自動化し、チームが重要なこと、つまり顧客の問題の解決に集中できるようにすることができます。
6つの標準ステータス（新規、オープン、保留中、保留、解決済み、クローズ）は、作業を追跡するための共通言語を提供します。トリガーと自動化により、常に手動で介入しなくてもチケットが動き続けます。カスタムステータスは、必要なときに精度を追加します。
ライフサイクル管理を次のレベルに引き上げたい場合は、eesel AIがZendeskと直接統合して、インテリジェントなルーティング、感情分析、およびプロアクティブな監視を追加します。ライブに移行する前に、シミュレーションモードですべてをテストできるため、何を期待できるかを正確に把握できます。
よくある質問
この記事を共有
Article by
Stevia Putri
Stevia Putri is a marketing generalist at eesel AI, where she helps turn powerful AI tools into stories that resonate. She’s driven by curiosity, clarity, and the human side of technology.
