デフォルトでは、Zendeskでは、顧客が解決済みのチケットを自動的にクローズする前に、4日間再オープンする猶予期間が与えられています。これは、標準の「ステータスが解決済みに設定されてから4日後にチケットをクローズする」という自動化が機能しているためです。しかし、ワークフローでより迅速な処理が必要な場合はどうでしょうか？キューを整理するために24時間以内にチケットをロックダウンしたい場合や、業界でより迅速な解決サイクルが求められている場合があります。
このガイドでは、デフォルトの自動化を修正して、96時間ではなく24時間後にチケットをクローズする方法を正確に説明します。技術的な手順、重要な考慮事項、経験豊富なZendesk管理者でさえつまずく一般的な落とし穴について説明します。
Zendeskにおける解決済みチケットとクローズ済みチケットの理解
何かを変更する前に、実際に何を変更しているのかを理解する必要があります。Zendeskでは、「解決済み」と「クローズ済み」は単なるラベルではありません。これらは、次に何が起こるかについて異なるルールを持つ、根本的に異なる状態を表しています。
解決済みチケットは解決済みですが、まだアクティブです。顧客は返信してチケットを再オープンできます。エージェントは、フィールドの更新、コメントの追加、ステータスの変更を行うことができます。解決済みは「顧客の確認待ちの解決済み」と考えてください。
クローズ済みチケットはロックされています。チケットがクローズされると、ほとんどの場合、読み取り専用になります。顧客がクローズ済みチケットに返信すると、Zendeskは元のチケットを再オープンするのではなく、新しいフォローアップチケットを作成します。管理者のみがクローズ済みチケットの一部のフィールドを変更できますが、それでもAPIまたはエージェントワークスペースを通じてのみ可能です。
以下に、それらの比較を示します。
| 側面 | 解決済み | クローズ済み |
|---|---|---|
| エージェントが直接設定できますか？ | はい | いいえ（トリガーまたは自動化経由のみ） |
| 顧客の返信で再オープンしますか？ | はい | いいえ（フォローアップチケットを作成） |
| エージェントの更新は許可されていますか？ | フルアクセス | 制限付き（タグ、一部のカスタムフィールドのみ） |
| 自動移行 | 4〜28日後にクローズ済みへ | 120日後にアーカイブ済みへ |
この2段階のプロセスには正当な理由があります。ソリューションで問題が完全に解決されなかった場合に、顧客が対応するための猶予期間が与えられます。ただし、その猶予期間は、すべてのビジネスで4日間である必要はありません。単純なトランザクションリクエストを処理するサポートチームは、24時間を好むかもしれません。複雑なエンタープライズサポートでは、2週間が必要になる場合があります。
Zendeskのデフォルトの自動クローズ自動化の仕組み
Zendeskには、「ステータスが解決済みに設定されてから4日後にチケットをクローズする」という標準の自動化が含まれています。削除することはできません（パフォーマンスの問題を防ぐために存在します）が、期間を編集することはできます。
この自動化の機能は次のとおりです。
- 1時間ごとに実行: Zendeskは、約1時間ごとにすべてのチケットをチェックして、自動化の条件を満たしているかどうかを確認します。
- 解決済みチケットをターゲット: 「解決済み」ステータスのチケットを探します。
- 96時間待機: デフォルトでは、96時間（4日）以上解決されたチケットに対してアクションを実行します。
- ステータスをクローズ済みに変更: チケットをロックし、それ以上の更新を防ぎます。
この96時間のウィンドウは、1時間から28日（672時間）の間で調整できます。探している24時間の設定は、その範囲内に十分に収まります。
出典：Zendesk Standard Automations
24時間に変更する理由
より迅速なクローズは、次の場合に役立ちます。
- 単純なトランザクションリクエスト（パスワードのリセット、注文ステータスの確認）を処理する場合
- 顧客が最初の解決策の後にチケットを再オープンすることがめったにない場合
- より迅速な解決サイクルで、よりクリーンなレポートを作成したい場合
- クローズ済みチケットでより適切に機能する他のシステムと統合する場合
- コンプライアンスまたはSLAの要件で、より迅速な最終処理が必要な場合
トレードオフは何でしょうか？顧客は、ソリューションの問題を把握するための時間が短縮されます。クローズが速すぎると、顧客がクローズされた会話に返信したときに、より多くのフォローアップチケットが作成される可能性があります。
ステップバイステップ：24時間の自動クローズを設定する
自動化の変更について説明します。Zendeskアカウントへの管理者アクセスが必要です。
ステップ1：自動化にアクセスする
管理センター > オブジェクトとルール > ビジネスルール > 自動化に移動します。
アカウント内のすべての自動化のリストが表示されます。標準のものは上部にあります。
ステップ2：チケットクローズ自動化を見つける
「ステータスが解決済みに設定されてから4日後にチケットをクローズする」という名前の自動化を見つけます。クリックして編集します。
現在の条件とアクションが表示されます。デフォルトでは、次のようになります。
条件：
- チケット：ステータスカテゴリ | Is（イコール） | 解決済み
- チケット：解決済みからの時間 | Greater than（より大きい） | 96
アクション：
- チケット：ステータスカテゴリ | クローズ済み
ステップ3：時間条件を変更する
ここで重要な変更を行います。「解決済みからの時間」条件を見つけて、値を96から24に変更します。
重要：「Is（イコール）」ではなく「Greater than（より大きい）」を演算子として使用します。
なぜこれが重要なのでしょうか？Zendeskの自動化は1時間サイクルで実行されます。「Is 24」を使用すると、自動化は正確に24時間のチケットのみをキャッチします。ただし、1時間ごとのチェックが23.5時間で行われ、次に24.5時間で行われる場合があります。チケットはウィンドウを逃します。
「Greater than 24」を使用すると、24時間以上のすべてのチケットが次のチェックサイクルで確実にキャッチされます。
出典：Zendesk Hours Since Condition
ステップ4：保存して確認する
「保存」をクリックして変更を適用します。
次に、テストします。
- テストチケットを作成します
- チケットを解決します（解決済みとしてマークします）
- 24時間以上待ちます（または、自動化アクティビティログを確認します）
- チケットのステータスがクローズ済みに変更されたことを確認します
チケットのイベントを表示して、自動化がトリガーされたかどうかを確認できます。チケット履歴で自動化名を探します。
重要なベストプラクティス
「Is（イコール）」ではなく「Greater than（より大きい）」を使用する
手順でこれについて言及しましたが、繰り返す価値があります。「Is（イコール）」演算子は完全一致に使用されますが、Zendeskの1時間ごとの自動化サイクルは、正確なタイミングが信頼できないことを意味します。「Greater than（より大きい）」は、1時間ごとのチェックがいつ実行されるかに関係なく、しきい値を超えたすべてのチケットをキャプチャします。
カスタム自動化の無効化条件を追加する
（標準の自動化に加えて）追加の自動化を構築する場合は、同じチケットで複数回実行されないようにする条件を追加します。
たとえば、クローズする前にリマインダーメールを送信する自動化を作成する場合：
条件：
- チケット：ステータスカテゴリ | Is（イコール） | 解決済み
- チケット：解決済みからの時間 | Greater than（より大きい） | 20
- チケット：タグ | 次のいずれも含まない | closure_reminder_sent
アクション：
- チケット：タグを追加 | closure_reminder_sent
- 通知：ユーザーにメール | （リクエスタ） | リマインダーメッセージ
タグは、自動化がチケットごとに1回だけ実行されるようにします。
出典：Zendesk Creating Automations
CSATワークフローを検討する
チケットをより迅速にクローズすると、顧客満足度アンケートに影響します。Zendeskの標準CSAT自動化は、チケットがクローズされた後にアンケートを送信します。4日ではなく24時間でクローズする場合、顧客はより早くアンケートのリクエストを受け取ります。
自問してください：
- 顧客は、ソリューションが機能することを確認するのに十分な時間がありましたか？
- より迅速なアンケートのリクエストは顧客を煩わせますか？
- CSAT自動化のタイミングを調整する必要がありますか？
チームとコミュニケーションをとる
より迅速なクローズは、エージェントの作業方法を変更します。次のことを確認してください。
- チケットは4日ではなく、24時間後にクローズされます
- 顧客がクローズ済みチケットに返信した場合、フォローアップチケットが作成されます
- エージェントは、解決策が解決する前に完了していることを確認する必要があります
- 「解決済み」と「クローズ済み」のタイミングを参照する内部プロセス
変更を行う前に、内部ドキュメントを更新し、チームに説明します。
一般的な問題とトラブルシューティング
自動化がトリガーされない
24時間後にチケットがクローズされない場合：
- 条件演算子を確認する：「Is（イコール）」ではなく「Greater than（より大きい）」であることを確認します
- 自動化がアクティブであることを確認する：非アクティブな自動化は実行されません
- トリガーの順序を確認する：他の自動化が干渉している可能性があります
- チケットイベントを確認する：チケット履歴を表示して、どのようなアクションが発生したかを確認します
チケットのクローズが速すぎる
24時間が早すぎると感じる場合：
- 48時間または72時間に調整します
- 特定のチケットタイプ（タグまたはグループを使用）の例外を追加します
- 顧客セグメントごとに異なる自動クローズルールを作成します
顧客の混乱
顧客がクローズ済みチケットに返信すると、新しい番号の新しいフォローアップチケットが作成されます。これにより、元のチケットが再オープンされることを期待する一部の顧客が混乱します。
次のことを説明するために、自動返信メッセージの更新を検討してください。
- チケットがクローズされる時期
- フォローアップを再オープンまたは作成する方法
- クローズ済みチケットに返信した場合に予想されること
統合の競合
一部のサードパーティ統合は、解決後にチケットにデータを書き戻します。書き戻しが完了する前にチケットがクローズされると、データを失ったり、エラーが発生したりする可能性があります。
統合を確認し、必要に応じてタイミングを調整します。一部のチームは、統合の遅延に対応するために、特に48〜72時間を使用します。
レポートの不一致
「解決済み」および「クローズ済み」のメトリックが変化します。チケットはより迅速にクローズ済みに移動するため、次の影響があります。
- 解決時間レポート
- CSATタイミング
- チケットボリュームメトリック
- エージェントパフォーマンスダッシュボード
新しいワークフローを反映するように、レポートとダッシュボードを更新します。
さらに進んで：AI搭載のチケットライフサイクル管理
時間ベースの自動化は、単純なワークフローに適しています。しかし、それらは厳格です。チケットの内容、顧客の履歴、または会話のコンテキストを考慮していません。
AI搭載ツールは、より柔軟なアプローチを提供します。
eesel AIでは、チケットライフサイクル管理に異なるアプローチをとっています。時間ベースのルールだけに頼るのではなく、AI Agentは、既存のチケット、マクロ、およびヘルプセンターのコンテンツから学習します。チケットが本当に解決されたかどうか、またはより多くの注意が必要な時期を理解します。
Zendeskでの動作は次のとおりです。
コンテキストを認識した意思決定：24時間後にすべてのチケットをクローズするのではなく、AIは会話を読み取り、問題が実際に解決されたかどうかを判断します。単純なパスワードのリセットですか？すぐにクローズします。複雑な技術的な問題ですか？より多くの時間を与えます。
インテリジェントなフォローアップ処理：顧客が返信すると、AIは元の問題を再オープンしているのか、それとも何か新しいことを尋ねているのかを理解します。フォローアップチケットを盲目的に作成するのではなく、適切にルーティングします。
段階的なロールアウト：すぐに完全に自律的にする必要はありません。チームがレビューするためにAIが返信を下書きすることから始めます。AIがその能力を証明するにつれて、解決後のワークフローを自動的に処理するようにレベルアップします。
本番稼働前のテスト：デプロイする前に、過去の数千のチケットでシミュレーションを実行します。AIが過去の会話をどのように処理したかを正確に確認します。
Zendesk integrationは、インスタンスに直接接続します。AIはチケットを読み取り、プロセスを学習し、既存のワークフローを中断することなくフォローアップを処理します。
自動化の構成、条件のテスト、および通知が送信されない理由のトラブルシューティングに何時間も費やしているチームにとって、AIチームメイトは、厳格なルールよりもニュアンスのある解決後のタスクを処理します。実際のチケットデータでどのように機能するかを確認し、ワークフローに適合するかどうかを判断できます。
