サポートワークフローを通過するチケットを追跡することは、明確な指標と満足している顧客を維持するために不可欠です。しかし、チケットが解決済みとしてマークされると、消えるわけではありません。顧客が再オープンしたり、自動化によってクローズされたり、エージェントが何が起こっているかを把握する必要がある移行状態にあります。
このガイドでは、解決済みチケットを監視し、再オープンされたチケットが抜け落ちる前にキャッチするのに役立つZendeskチケットビューの作成について説明します。解決済みステータスとクローズ済みステータスの違い、これらのステータスでフィルタリングするビューの設定方法、および不必要にチケットを再オープンする避けられない「ありがとう」の返信を管理するためのベストプラクティスについて説明します。
このオーバーヘッドを完全に削減する方法をお探しの場合は、別の方法を提供します。当社のAI Agentは、チケットライフサイクルの決定をインテリジェントに処理するため、ビューの設定にかかる時間を短縮し、実際にお客様を支援する時間を増やすことができます。
-----|-------------|----------------| | 新規（New） | チケットが作成されたが、エージェントの対応はまだない | システム（System） | | オープン（Open） | エージェントがチケットに積極的に取り組んでいる | エージェント（Agent） | | 保留中（Pending） | 顧客の返信を待っている | エージェント（Agent） | | 保留（On-hold） | サードパーティを待っている（オプション） | エージェント（Agent） | | 解決済み（Solved） | 問題が解決され、クローズを待っている | エージェント（Agent） | | クローズ（Closed） | システムによってロックされ、読み取り専用 | システムのみ（System only） |
解決済み（Solved）とクローズ（Closed）：違いは何ですか？
解決済みとクローズの違いは、多くのチームにとって混乱の元です。以下に内訳を示します。
**解決済みチケット（Solved tickets）**は解決済みですが、まだアクティブです。顧客は返信してチケットを再オープンできます。エージェントは、フィールドの更新、コメントの追加、ステータスの変更を行うことができます。解決済みは「顧客の確認を保留中の解決済み」と考えてください。
**クローズ済みチケット（Closed tickets）**はロックされています。チケットがクローズされると、ほとんどの場合、読み取り専用になります。顧客がクローズ済みチケットに返信すると、Zendeskは元のチケットを再オープンするのではなく、新しいフォローアップチケットを作成します。管理者のみがクローズ済みチケットの特定のフィールドを変更できますが、それでもAPIまたはエージェントワークスペース（Agent Workspace）経由でのみ可能です。
| 側面（Aspect） | 解決済み（Solved） | クローズ（Closed） |
|---|---|---|
| 顧客は再オープンできますか？（Can customer reopen?） | はい（Yes） | いいえ（No）（フォローアップを作成） |
| エージェントの更新は許可されていますか？（Agent updates allowed?） | フルアクセス（Full access） | 制限付き（タグのみ）（Limited (tags only)） |
| 誰が設定できますか？（Who can set?） | エージェント（Agents） | システム/自動化のみ（System/automation only） |
| 自動移行（Auto-transition） | 4〜28日後にクローズ（To Closed after 4-28 days） | 120日後にアーカイブ（To Archived after 120 days） |
デフォルトの自動化では、チケットは解決後4日でクローズされます。ワークフローのニーズに応じて、これを1時間から28日の範囲で調整できます。
解決済みチケットのビューを作成する
次に、クローズされる前の解決済みチケットを表示するビューを作成しましょう。これにより、最後の問題点をキャッチし、アクティブなキューから離れる可能性のあるものを把握できます。
必要なもの
- Zendeskアカウントへの管理者アクセス
- 追跡する解決済みチケットの明確なアイデア（すべて、自分だけ、特定のグループなど）
ステップ1：ビュー管理ページにアクセスする
**管理センター（Admin Center）> オブジェクトとルール（Objects and rules）> ビジネスルール（Business rules）> ビュー（Views）**に移動します。
ここには、すべてのチケットビューがあります。アクティブなビュー、誰がアクセスできるか、およびそれらがどのように順序付けられているかを確認できます。
ステップ2：新しいビューを作成する
**ビューを追加（Add view）**をクリックします。「最近解決済み - クローズ待ち（Recently Solved - Awaiting Closure）」のようなわかりやすい名前を付けて、エージェントが何を見ているのかを正確に把握できるようにします。
アクセス許可を設定します。これは以下のようにできます。
- すべてのエージェントが利用可能
- 自分だけ
- 特定のグループに限定
ステップ3：ビューの条件を設定する
ここでは、どのチケットを表示するかを定義します。解決済みチケットのビューでは、次の条件を使用します。
- **条件1：**チケット：ステータスカテゴリ（Ticket: Status category）| が（Is）| 解決済み（Solved）
- **条件2（オプション）：**チケット：解決からの時間（Ticket: Hours since solved）| 未満（Less than）| 96（過去4日以内に解決されたチケットを表示）
- **条件3（オプション）：**チケット：担当者（Assignee）| が（Is）| 現在のユーザー（Current user）（個人用ビューの場合）
「解決からの時間（Hours since solved）」条件は特に役立ちます。自動クローズ自動化が96時間（4日）後に実行される場合、これを「未満（Less than）96」に設定すると、まだクローズされていないチケットが表示されます。
ステップ4：列を設定する
次の列を追加して、エージェントに役立つコンテキストを提供します。
- チケットID（Ticket ID）
- 件名（Subject）
- リクエスタ（Requester）
- 担当者（Assignee）
- ステータス（Status）
- 解決からの時間（Hours since solved）
「解決からの時間（Hours since solved）」列は、エージェントが自動クローズに近づいているチケットを確認するのに役立ちます。何かが90時間解決されていて、顧客が応答していない場合、おそらく安全です。わずか12時間の場合、エージェントは注意を払う必要があるかもしれません。
再オープンされたチケットのビューを作成する
再オープンされたチケットは特別な注意が必要です。これらは、元の解決策が機能しなかったことを示しており、不満な顧客またはエスカレーションが必要な複雑な問題があることを意味する可能性があります。
再オープンされたチケットに独自のビューが必要な理由
顧客が解決済みチケットに返信すると、Zendeskは自動的にステータスをオープン（Open）に戻します。これが追跡している再オープンイベントです。これらのチケットには、多くの場合、次のものが必要です。
- 優先的な処理（顧客はまだ何かが間違っているためフォローアップしている）
- 異なるエージェントの割り当て（おそらく元のエージェントが利用できない）
- エスカレーション（問題が最初に解決されなかった場合）
ステップ1：再オープンされたチケットのビューを作成する
**管理センター（Admin Center）> オブジェクトとルール（Objects and rules）> ビジネスルール（Business rules）> ビュー（Views）> ビューを追加（Add view）**に移動します。
「再オープンされたチケット - 注意が必要（Reopened Tickets - Needs Attention）」のような明確な名前を付けます。
ステップ2：再オープンされたチケットの条件を設定する
次の条件を使用して、再オープンされたチケットをキャッチします。
- **条件1：**チケット：ステータス（Ticket: Status）| が（Is）| オープン（Open）
- **条件2：**チケット：コメント（Ticket: Comment）| が（Is）| 公開（Public）（顧客が返信したことを示す）
- **条件3（オプション）：**チケット：タグ（Ticket: Tags）| 次のいずれも含まない（Contains none of the following）| closure_reminder_sent
「コメントは公開（Comment is Public）」条件は、チケットのステータスを変更する可能性のある内部メモを除外するのに役立ちます。顧客の返信を具体的にキャッチする必要があります。
別の方法として、ステータス変更条件を使用します。
- **条件：**チケット：ステータスが変更された（Ticket: Status changed from）| 解決済み（Solved）
これは、解決されてからオープン（Open）に戻されたチケットをキャッチします。これは、再オープン時にまさに起こることです。
ステップ3：役立つ列を追加する
再オープンされたチケットのビューに次の列を設定します。
- チケットID（Ticket ID）
- 件名（Subject）
- リクエスタ（Requester）
- 以前の担当者（Originally solved it）（最初に解決した人）
- 最後のコメント日（Last comment date）
- 優先度（Priority level）
以前の担当者（Previous assignee）列は、Zendeskが再オープンされたチケットを解決したエージェントに自動的に再割り当てするため便利です。そのエージェントが不在または多忙な場合は、これらを再配布する必要があるかもしれません。
「ありがとう」の再オープン問題の管理
すべてのサポートチームが知っているシナリオがあります。チケットを解決すると、顧客が「ありがとう」と返信し、チケットが再オープンされてキューに戻ります。時間の無駄ですが、顧客はただ礼儀正しいだけです。
問題の範囲
Spiceworksコミュニティメンバーは、次のように述べています。「誤解しないでください。ユーザーがありがとうと言うのはいつでも歓迎されますが、これが発生するたびにチケットを閉じる/解決するために戻る必要があると、時間がかかります。」
解決策1：トリガーベースの自動解決
一般的な「ありがとう」フレーズを検出し、チケットを再度自動的に解決するトリガーを作成します。基本的な設定は次のとおりです。
条件：
- チケット：ステータス（Ticket: Status）| 変更された（Changed from）| 解決済み（Solved）
- チケット：コメントテキスト（Ticket: Comment text）| 次の文字列を含む（Contains the following string）| ありがとう（thank you）
アクション：
- チケット：ステータス（Ticket: Status）| 解決済み（Solved）
- 通知：ユーザーにメール（Notifications: Email user）| （リクエスタ）（requester）| 「どういたしまして！返信は不要です。（You're welcome! No need to reply.）」
「感謝します（thanks）」、「ty」、「感謝します（appreciate it）」などのバリエーションを追加して、さまざまな言い回しをキャッチします。
解決策2：顧客教育
解決済みチケットの通知を更新して、次に何が起こるかを説明します。
「お客様のチケットは解決されました。さらにサポートが必要な場合は、このメールに返信してください。すべてが期待どおりに機能している場合は、それ以上の操作は必要ありません。お客様のチケットは数日後に自動的にクローズされます。」
これにより、期待値が設定され、不必要な返信が減ります。
解決策3：インテリジェントな処理のためのAIの使用
トリガーベースのソリューションの問題は、それらが硬直的であることです。「ありがとう、すべて問題ありません」と「ありがとう、しかし、まだ問題があります」の違いを区別できません。
ここで、AIチームメイトが違いを生み出します。当社のAI Triageは、キーワードだけでなく、意図を理解します。丁寧な終了と本物の再オープンリクエストを区別し、チームの作業を作成せずにルーチンの返信を処理できます。
ますます複雑なトリガーチェーンを構築する代わりに、AIに過去のチケットから学習させ、実際にはエージェントの注意が必要な返信について、コンテキストを認識した意思決定を行うことができます。
チケットライフサイクル管理のベストプラクティス
ビューの設定は始まりにすぎません。ワークフローをスムーズに実行し続けるためのいくつかのプラクティスを次に示します。
ビューの整理のヒント
- **アクティブなビューを制限する：**ビューが多すぎると、エージェントが圧倒されます。共有ビューを絞り込み、関連性を維持します。チームごとに10〜15のアクティブなビューが適切な目標です。
- **命名規則を使用する：**エージェントがすばやくスキャンできるように、「[ステータス] - [目的]」のような構造化された名前を付けます。例：「解決済み - クローズ待ち（Solved - Pending Closure）」または「オープン - 今日再オープン（Open - Reopened Today）」。
- **ビューを戦略的に順序付けする：**最も使用されるビューをリストの一番上に配置します。エージェントは、主要なワークフロービューを見つけるためにスクロールする必要はありません。
自動化の推奨事項
- **再オープン時に通知する：**チケットが再オープンされたときに割り当てられたエージェントにメールを送信するトリガーを設定します。これにより、何も気付かれずに放置されないようにします。
- **古くなった解決済みチケットに関するアラート：**72時間以上解決されたチケットにタグを付ける自動化を作成し、自動クローズが開始される前に警告します。
- **再オープン率を追跡する：**タグまたはカスタムフィールドを使用して、再オープンされたチケットをマークします。このデータは、トレーニングのニーズまたはプロセスのギャップを特定するのに役立ちます。
レポートに関する考慮事項
再オープンされたチケットは、特定の点で指標に影響を与えます。
- **初回コンタクト解決率：**再オープンされたチケットは通常、初回コンタクトで解決されなかったと見なされます
- **エージェントのパフォーマンス：**特定のエージェントによる高い再オープン率は、トレーニングの機会を示す可能性があります
- **クローズまでの時間：**再オープンされたチケットは、解決サイクルが長くなります
これらの指標をZendesk Exploreダッシュボードで追跡して、傾向を把握します。
AIの代替手段を検討する場合
ますます複雑なビューと自動化チェーンを構築していることに気付いた場合は、一歩引いてみる必要があるかもしれません。従来のワークフロー管理が限界に達している兆候を次に示します。
- 20以上のビューを管理しているのに、エージェントは必要なものを見つけることができません
- トリガーリストが数百のルールで構成されています
- プロセスの変更にもかかわらず、再オープン率が改善されていません
- エージェントは、顧客を支援するよりもビューのナビゲートに多くの時間を費やしています
当社のAI Agentは、Zendeskと直接統合され、チケットが本当に解決されたのか、それともさらに注意が必要なのかについて、ニュアンスのある意思決定を処理します。既存のチケットとヘルプセンターから学習するため、すべてのエッジケースをトリガーにコード化する必要はありません。
よりスマートなツールでチケットライフサイクルを合理化する
チケットビュー、ステータス、および再オープンワークフローの管理には、かなりの管理時間が必要です。Zendeskのネイティブツールは、簡単なワークフローには適していますが、複雑なニーズまたは大量のチケットを抱えるチームは、ますます精巧なトリガーと自動化チェーンを構築していることがよくあります。
チケットライフサイクル管理には、異なるアプローチをとっています。時間ベースのルールとステータスフィルターのみに依存する代わりに、当社のAIは既存のチケット、マクロ、およびヘルプセンターのコンテンツから学習します。チケットが本当に解決されたのか、それともさらに注意が必要なのかを理解し、硬直的なビューよりもニュアンスのあるフォローアップを処理します。
Zendesk統合は、インスタンスに直接接続します。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.
