すべてのサポートチケットは、ある道のりをたどります。顧客が「送信」ボタンを押した瞬間から、問題が完全に解決されるまで、各チケットは明確な段階を経ます。Zendesk（ゼンデスク）のチケットステータスのライフサイクルを理解することは、単にボタンが何をするかを知ることだけではありません。チームを組織化し、顧客に情報を伝え、サポート業務を円滑に進めることが重要です。
もし、ビューから一部のチケットが消えてしまう理由や、顧客が「完了」したチケットを再オープンできるのに、「解決済」のチケットには触れられない理由について疑問に思ったことがあるなら、このガイドで明確になるでしょう。各ステータスについて説明し、いつ使用するかを解説し、ワークフローを最適化する方法を紹介します。また、eesel AIのようなツールが、このプロセスを自動化し、強化するのにどのように役立つかについても見ていきます。
Zendesk（ゼンデスク）のチケットステータスのライフサイクルとは？
チケットライフサイクルとは、すべてのサポートリクエストが作成から完了までたどる道のりです。サポート業務の心臓部と考えてください。各ステータスは特定の進捗状況を表し、これらのステータスを正しく移動することで、全員が同じ認識を持つことができます。公式ドキュメントについては、Zendeskのチケットステータスに関するガイドを参照してください。
なぜこれが重要なのでしょうか？まず、チケットステータスはレポート作成を強化します。どのチケットがどのビューに表示されるかを決定します。SLA（サービス品質保証）タイマーを制御します。そして、おそらく最も重要なこととして、何か変更があるたびに手動で更新する必要なく、顧客に進捗状況を伝えます。
ステータスを適切に管理すると、エージェントは注意を払う必要があるものを正確に把握できます。顧客はリクエストの状況を理解できます。そして、マネージャーはチームのパフォーマンスとボトルネックに関する正確なデータを取得できます。
6つの標準的なZendesk（ゼンデスク）のチケットステータスについて
Zendesk（ゼンデスク）には、すぐに使用できる6つの標準ステータスが付属しています。それぞれに特定の目的、視覚的な指標、および動作を制御する一連のルールがあります。Zendesk（ゼンデスク）でのチケットの仕組みについて詳しく読むことができます。
新規（New）
「新規（New）」ステータスは、すべてのチケットが開始される場所です。顧客が任意のチャネル（メール、Webフォーム、チャット、またはAPI）を通じてリクエストを送信すると、Zendesk（ゼンデスク）は自動的に「新規（New）」ステータスを割り当てます。
視覚的な指標はオレンジ色です。これにより、新しいチケットがビューで目立ち、最初のトリアージまたは割り当てが必要であることを示します。
「新規（New）」に関する重要なルールは次のとおりです。「新規（New）」からチケットのステータスが変更されると、二度と戻ることはありません。後でチケットの割り当てを解除しても、「新規（New）」に戻ることはありません。これは設計によるものです。「新規（New）」は、最初の「未確認」状態をキャプチャすることを目的としています。
オープン（Open）
エージェントがチケットの作業を開始したら、「オープン（Open）」としてマークする必要があります。赤い視覚的な指標は、このチケットが積極的に処理されていることを示します。
「オープン（Open）」を使用する場合：
- エージェントが割り当てられ、チケットを積極的に処理している
- 内部調査または調査を待っている
- 次のアクションが顧客ではなく、チームにある
最も一般的な間違いは何でしょうか？実際には顧客からの応答を待っているときに、チケットを「オープン（Open）」ステータスのままにしておくことです。これにより、エージェントのビューが乱雑になり、実際には注意が必要なものがわかりにくくなります。
保留中（Pending）
「保留中（Pending）」とは、顧客を待っていることを意味します。青色の指標は、ボールがリクエスタのコートにあるという視覚的な合図です。
チケットを「保留中（Pending）」に設定する場合：
- SLA（サービス品質保証）タイマーを一時停止します（構成によって異なります）
- 通常、「注意が必要」ビューからチケットを削除します
- 応答し、顧客を待っていることを顧客に知らせます
重要なことがあります。顧客が「保留中（Pending）」のチケットに返信すると、自動的に「オープン（Open）」にリセットされます。これは無効にできないシステムルールです。顧客が関与した瞬間にチケットに注意を向けるように設計されています。
保留（On-hold）
「保留（On-hold）」ステータスはオプションです。管理者は最初に有効にする必要があります。有効にすると、特定の目的を果たします。顧客以外の誰かを待っているチケットを追跡します。
待っているのは次のとおりです。
- ベンダーが交換部品を発送するのを待っている
- エンジニアリングチームがバグを修正するのを待っている
- サードパーティサービスが問題を解決するのを待っている
濃い灰色の指標は、これらを「保留中（Pending）」チケットと区別します。そして、重要な点は、「保留（On-hold）」は顧客には表示されないということです。顧客には「オープン（Open）」として表示されます。これにより、内部依存関係を明らかにすることなく、問題が処理されていることを顧客に知らせます。
解決済（Solved）
顧客の問題を解決したと思われる場合は、チケットを「解決済（Solved）」としてマークします。薄い灰色の指標は、このチケットが基本的に完了しており、顧客の確認を待っていることを示します。
「解決済（Solved）」は、「完了（Closed）」とは重要な点で異なります。顧客は返信するだけで「解決済（Solved）」チケットを再オープンできます。これは、顧客が「実際には、それは修正されませんでした」と言うことができる「クールオフ」期間であり、チケットは「オープン（Open）」に戻ります。
ベストプラクティスは、チケットを「完了（Closed）」に移行する前に3〜5日間「解決済（Solved）」にしておくことです。これにより、顧客は何か問題がある場合に合理的な期間応答できます。
完了（Closed）
「完了（Closed）」は最終目的地です。チケットが「完了（Closed）」になると、ロックされます。顧客は再オープンできません。エージェントは変更できません（まれな例外を除く）。チケットは読み取り専用になります。
多くの人が驚くのは、チケットを手動で「完了（Closed）」に設定できないことです。常に自動化によって行われます。Zendesk（ゼンデスク）には、チケットを「解決済（Solved）」に設定してから4日後にクローズするデフォルトの自動化が含まれています。このタイミング（1時間から28日まで）を調整できますが、自動クローズを完全に無効にすることはできません。28日後、システムは設定に関係なく解決済みのチケットをクローズします。
顧客が「完了（Closed）」チケットに返信すると、Zendesk（ゼンデスク）は元のチケットを参照する新しい「フォローアップ」チケットを作成します。これにより、履歴が保持され、新しい会話が開始されます。
チケットがライフサイクルをどのように移動するか
各ステータスを理解したので、それらがどのように接続されているかを見てみましょう。一般的なフローを次に示します。
- 新規（New） - 顧客がチケットを送信
- オープン（Open） - エージェントが割り当てられ、調査を開始
- 保留中（Pending） - エージェントが顧客に追加情報を要求
- オープン（Open） - 顧客が詳細を返信
- 解決済（Solved） - エージェントがソリューションを提供
- 完了（Closed） - 自動化が待機期間後にチケットをクローズ
ただし、チケットは常に直線的に進むとは限りません。「オープン（Open）」と「保留中（Pending）」の間を複数回行き来する場合があります。エンジニアリングに確認している間、チケットが「オープン（Open）」から「保留（On-hold）」になり、次に「オープン（Open）」に戻り、次に顧客に修正を説明している間、「保留中（Pending）」になる場合があります。
システムには、これらの移行を制御する組み込みルールがあります。
- 顧客が「保留中（Pending）」、「解決済（Solved）」、または「保留（On-hold）」に返信すると、チケットは自動的に「オープン（Open）」に設定されます
- チケットを手動で「完了（Closed）」にすることはできません（自動化のみ）
- 「新規（New）」が変更されると、二度と戻ることはありません
- チケットは、担当者がいないと「解決済（Solved）」に設定できません（システムは解決エージェントを自動的に割り当てます）
チケットステータスを管理するためのベストプラクティス
ステータス管理を正しく行うと、サポート業務を変革できます。最も大きな違いを生むプラクティスを次に示します。
「オープン（Open）」と「保留中（Pending）」の区別をマスターする
これは、エージェントが身につけるべき最も重要な習慣です。チケットが「オープン（Open）」の場合、エージェントの注意が必要な作業に焦点を当てたビューに表示されます。「保留中（Pending）」の場合、これらのビューから削除されます。
エージェントが実際には顧客を待っているときにチケットを「オープン（Open）」のままにすると、これらのチケットはアクティブな作業キューを乱雑にします。他のエージェントは、アクションを必要としないチケットの確認に時間を費やす可能性があります。そして、真の「注意が必要」なチケットが埋もれてしまいます。
チームに次のことを尋ねるようにトレーニングします。「顧客を待っていますか？」はいの場合は、「保留中（Pending）」に設定します。いいえの場合は、「オープン（Open）」のままにします。
内部依存関係には「保留（On-hold）」を使用する
管理者が「保留（On-hold）」を有効にしている場合は、それを使用します。これにより、サポートチーム以外の要因によってブロックされているチケットをより詳細に把握できます。「保留（On-hold）」チケット専用のビューを作成し、チケットが待機している場合に内部チームに通知するように自動化を設定できます。
「保留（On-hold）」がない場合、エージェントは内部待機のために「保留中（Pending）」を誤用することがよくあります。これは顧客にとって混乱を招き（顧客は待っていないのに待っていると思っています）、メトリックを混乱させます（SLAタイマーは「保留中（Pending）」と「保留（On-hold）」で動作が異なります）。
バンプ解決自動化を設定する
Zendesk（ゼンデスク）で最も役立つ自動化の1つは、「バンプ解決」ワークフローです。次のように機能します。
- チケットが48時間「保留中（Pending）」になっている
- 自動化が顧客に友好的なリマインダーを送信
- さらに48時間経過しても応答がない
- 自動化が丁寧なメッセージでチケットを解決
これにより、エージェントが応答のない顧客を手動で追いかける必要なく、バックログをクリーンに保つことができます。まだ支援が必要な顧客は、返信するだけでチケットを再オープンできます。
早すぎるクローズを避ける
チケットを「完了（Closed）」に急がないでください。確かに、クリーンなバックログは気持ちが良いですが、クローズが早すぎると、フォローアップが必要な顧客が不満を感じます。新しいチケットを作成し、問題を再説明し、最初からやり直す必要があります。これは顧客満足度を損ない、エージェントの作業を増やします。
「解決済（Solved）」ステータスで3〜5日間の期間を守ってください。キューを管理可能な状態に保ち、顧客に問題が本当に解決されたことを確認する時間を与えることの間の適切なバランスを取ります。
Zendesk（ゼンデスク）でのステータス移行の自動化
Zendesk（ゼンデスク）は、ステータス変更を自動化するための2つのツールを提供します。トリガーと自動化です。それぞれをいつ使用するかを理解すると、効率的なワークフローを構築するのに役立ちます。
トリガーは、チケットが作成または更新されたときに即座に起動します。次のような即時アクションに最適です。
- チケットがエージェントに割り当てられたときに「オープン（Open）」に設定する
- 特定のキーワードまたはタグに基づいてステータスを変更する
- コンテンツに基づいてチケットを特定のグループにルーティングする
自動化は、スケジュール（通常は1時間ごと）で実行され、時間ベースの条件を確認します。次のような場合に最適です。
- チケットがX日間「解決済（Solved）」になった後にクローズする
- オープンになっている時間が長すぎるチケットをエスカレートする
- 「保留中（Pending）」のチケットのリマインダーを送信する
このトピックの詳細については、ライフサイクルイベントに関するZendesk（ゼンデスク）の自動化とトリガーに関するガイドをご覧ください。
AIによるステータス管理の強化
Zendesk（ゼンデスク）のネイティブツールは強力ですが、手動で構成したルールに依存しています。新しいシナリオごとに、新しいトリガーまたは自動化が必要です。ここでAIが役立ちます。
eesel AIは、Zendesk（ゼンデスク）と直接統合し、過去のチケットデータから学習します。考えられるすべてのシナリオのルールを作成する代わりに、eesel AIはコンテキストと意図を理解します。次のことができます。
- チケットの内容に基づいて、適切なステータスを自動的に提案または設定する
- 手動トリアージなしで、チケットを適切なチームにルーティングする
- 会話に基づいて、チケットを「保留中（Pending）」と「保留（On-hold）」のどちらにするかを判断する
- ルールが見逃す可能性のある感情と緊急性を認識する
これにより、エージェントの認知負荷が軽減され、すべてのチケットのステータスを手動で管理する必要がなくなります。また、厳格なルールが見落とす可能性のあるエッジケースもキャッチします。
よくある間違いとその回避方法
経験豊富なサポートチームでも、これらのステータス管理エラーを犯します。注意すべき点は次のとおりです。
チケットを間違ったステータスのままにしておく。 最も一般的な問題は、本来「保留中（Pending）」であるはずのチケットが「オープン（Open）」になっていることです（またはその逆）。これは通常、エージェントが区別を明確にしていないことが原因です。定期的なトレーニングとビュー監査は、これをキャッチするのに役立ちます。
チケットをクローズするのが早すぎる。 チームが解決時間で測定される場合、チケットを迅速にクローズするプレッシャーがあります。これに抵抗してください。フォローアップチケットを作成する顧客を不満にさせるよりも、わずかに長い「クローズまでの時間」メトリックの方が優れています。
サードパーティの依存関係に「保留（On-hold）」を使用しない。 「保留（On-hold）」がない場合、エージェントは「保留中（Pending）」を誤用する（顧客を混乱させる）か、チケットを「オープン（Open）」のままにする（アクティブな作業キューを膨らませる）かのいずれかです。プランがサポートしている場合は、「保留（On-hold）」を有効にして、エージェントがそれを使用するようにトレーニングします。
チーム全体でステータスの使用法が一貫していない。 あるエージェントの「オープン（Open）」は、別のあるエージェントの「保留中（Pending）」である可能性があります。チームの標準を文書化し、チケットサンプルを定期的に確認して、一貫性を確保します。
eesel AIでZendesk（ゼンデスク）のチケットステータスのライフサイクルを最適化する
チケットステータスを手動で管理することは、小規模では問題なく機能します。しかし、チームが成長し、チケットの量が増加するにつれて、オーバーヘッドが増加します。エージェントは、どのステータスを使用するかを決定するために精神的なエネルギーを費やします。管理者は、エッジケースを処理するためにますます複雑なルールを作成します。そして、チケットは依然として抜け落ちます。
ここで私たちがお手伝いできます。eesel AIは、Zendesk（ゼンデスク）と統合して、チケットライフサイクルにインテリジェントな自動化をもたらします。AIエージェントは、過去のチケットから学習して、チームの働き方を理解します。最適なステータスを提案したり、チケットをインテリジェントにルーティングしたり、ルーチンステータスの移行を自動的に処理したりできます。
エージェントが制御を維持したいチームのために、AIトリアージ製品は推奨事項を提供しながら、最終的な決定を人間に委ねます。そして、AIコパイロットは、エージェントが自然に次の適切なステータスにつながる応答の下書きを支援します。
その結果、バックログがクリーンになり、ステータスの使用法が一貫し、エージェントはチケットの状態を管理するのではなく、問題の解決に集中できます。
よくある質問
この記事を共有
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.
