Zendesk自動化レシピ:複数段階のリマインダーで停滞チケットをクローズする方法

Stevia Putri

Stanley Nicholas
Last edited 2026 2月 24
Expert Verified
停滞チケットは、すべてのサポートチームが抱える悩みの種です。顧客に返信し、チケットを保留にして待ちます。数日が経ち、数週間が経ちます。そのチケットはそこに座り込み、バックログを膨らませ、解決の指標を歪めます。手動で探し出すこともできますが、それは誰にとっても時間の有効活用とは言えません。
より良いアプローチは?最初のプッシュから最終的なクローズまで、停滞チケットを処理するZendeskの自動化レシピを作成することです。このガイドでは、フレンドリーなリマインダー、最終警告、自動解決の3段階のワークフローを作成する方法を説明します。最終的には、よりクリーンなキュー、より正確なレポート、そして顧客が自分の状況を正確に把握できるようになります。
その方法をご紹介します。
このZendesk自動化レシピの停滞クローズワークフローでできること
設定に入る前に、構築するものを説明します。この自動化レシピは、手動での介入なしに、非アクティブなチケットを管理する丁寧で確固たるシーケンスを作成します。
フローの仕組みは次のとおりです。
-
**最初のリマインダー(48時間):**2日間応答がない場合、顧客はフレンドリーなチェックインメールを受け取ります。チケットにはタグが付けられ、システムは最初のリマインダーが完了したことを認識します。
-
**最終警告(5日間):**それでも応答がない場合は、チケットが間もなくクローズされることを警告する2通目のメールが送信されます。別のタグがこの段階を追跡します。
-
**自動解決(7日間):**1週間応答がない場合は?チケットは自動的に解決されます。Zendeskに組み込まれている自動化機能により、4日後に最終的なクローズが処理されます。
その結果、サポートキューはアクティブな会話に集中したままになります。エージェントは、実際に注意が必要なチケットに時間を費やします。指標は、数か月前のゴーストチケットではなく、現実を反映します。そして、顧客は自分のリクエストで何が起こっているかについて明確なコミュニケーションを受け取ります。
さらに進みたいチームのために、AIレイヤーがこのワークフローにコンテキスト認識をどのように追加できるかについても見ていきます。しかし、まず、理解する必要がある基本事項について説明します。
開始する前に:Zendeskの自動化について
Zendeskには、チケットを自動的に処理するための2つの主要なツールがあります。トリガーと自動化です。これらは似ているように聞こえますが、動作は大きく異なります。
**トリガーはイベントベースです。**何かが起こった瞬間に作動します。新しいチケットが届きましたか?トリガーはすぐに割り当てることができます。顧客が返信しましたか?トリガーはすぐに優先度を上げることができます。トリガーは、アクションが発生するとすぐに応答します。
**自動化は時間ベースです。**スケジュールに従って(1時間に1回程度)実行され、時間ベースの条件を満たすチケットを確認します。これにより、フォローアップや停滞チケットの管理に最適です。行動する前に特定の期間待つ必要があるためです。

理解すべき重要な概念
**条件とアクション:**すべての自動化には2つの部分があります。条件は、いつ実行されるかを定義します(「チケットが48時間以上保留になっている」)。アクションは、何が起こるかを定義します(「メールを送信してタグを追加する」)。
**無効化条件:**重要な部分はここです。自動化は1時間ごとに実行されます。無効化アクションがないと、同じチケットで無期限に作動し続けます。そのため、アクションとしてタグを追加し、条件でそのタグを除外します。タグが追加されると、チケットは条件を満たさなくなります。問題は解決しました。
**65kbルール:**アクティブな自動化の合計サイズは65キロバイト未満である必要があります。これはめったに問題になりませんが、多数の複雑なルールを作成する場合は知っておく価値があります。
**一意性の要件:**アクティブな自動化が2つとも同一であることはできません。一部の条件を共有できますが、それらの間には意味のある違いが必要です。
**「より大きい」と「等しい」:**Zendeskは自動化を1時間ごとにチェックします。「保留になってからの時間|等しい| 48」を使用すると、47.5時間後と48.5時間後にチェックが行われ、正確なウィンドウが見逃される可能性があります。時間条件には常に「より大きい」を使用してください。しきい値を超えたすべてのチケットをキャッチします。
メカニズムを理解したので、最初の自動化を作成します。
ステップ1:最初のリマインダー自動化を作成する
この自動化は、顧客からの応答を48時間待っているチケットを特定し、穏やかなプッシュを送信します。また、ワークフローの進行状況を追跡するためのタグも追加します。
まず、管理センター>オブジェクトとルール>ビジネスルール>自動化に移動します。自動化を追加をクリックして、新しいルールを作成します。
「停滞チケット-最初のリマインダー(48時間)」のように、明確でわかりやすいタイトルを付けます。将来のあなたは、具体的であることに感謝するでしょう。
条件を設定する
「次のすべての条件を満たす」で、次の3つのルールを追加します。
| 条件 | 演算子 | 値 |
|---|---|---|
| チケット:ステータス | より小さい | 解決済み |
| チケット:保留になってからの時間 | より大きい | 48 |
| チケット:タグ | 次のいずれも含まない | stale_reminder_1 |
「解決済みより小さい」条件は、アクティブなチケットのみに触れるようにします。「48より大きい」は、2日間以上保留になっているものをキャッチします。タグの除外は、この自動化が同じチケットで2回実行されるのを防ぎます。
アクションを設定する
「次のアクションを実行する」で、次を追加します。
| アクション | 値 |
|---|---|
| 通知:ユーザーにメールを送信する | (リクエスター) |
| チケット:タグを追加する | stale_reminder_1 |
メールについては、フレンドリーでありながら明確なものを書いてください。件名の例:「サポートリクエストの確認」。本文の例:「こんにちは、最近のサポートリクエストについてフォローアップしたかったのです。必要な場合は、いつでもお手伝いします。このメールに返信していただければ、中断したところから再開します。」

自動化を作成をクリックして保存します。これで、ワークフローの最初の部分が整いました。
ステップ2:最終リマインダー自動化を作成する
この自動化は、最初のリマインダーを受け取ったが、顧客のアクティビティがまだ見られていないチケットをキャッチします。クローズする前に最終警告を送信します。
別の自動化を作成します。「停滞チケット-最終リマインダー(5d)」というタイトルを付けます。
条件を設定する
| 条件 | 演算子 | 値 |
|---|---|---|
| チケット:ステータス | より小さい | 解決済み |
| チケット:保留になってからの時間 | より大きい | 120 |
| チケット:タグ | 次のいずれかを少なくとも1つ含む | stale_reminder_1 |
| チケット:タグ | 次のいずれも含まない | stale_reminder_2 |
120時間は合計5日間に相当します。「少なくとも1つを含む」条件は、これが最初のリマインダーをすでに受け取ったチケットでのみ実行されるようにします。2番目のタグの除外は、最終リマインダーの重複を防ぎます。
アクションを設定する
| アクション | 値 |
|---|---|
| 通知:ユーザーにメールを送信する | (リクエスター) |
| チケット:タグを追加する | stale_reminder_2 |
このメールでは、差し迫ったクローズについてより明確にしてください。件名の例:「チケットは48時間以内にクローズされます」。本文の例:「こんにちは、サポートリクエストに関してご連絡がありませんでした。アクティブな問題にキューを集中させるために、このチケットは48時間後に自動的にクローズされます。まだサポートが必要な場合は、このメールに返信するだけで、リクエストをすぐに再開します。」
タグの連鎖は、このワークフローを信頼できるものにするものです。各自動化は、前のタグを確認し、独自のタグを追加します。チケットは順番にシーケンスを流れ、スキップや繰り返しはありません。
ステップ3:自動解決自動化を作成する
これが最後のステップです。合計7日間非アクティブ状態が続くと、チケットは自動的に解決されます。
3番目の自動化を作成します。「停滞チケット-自動解決(7d)」というタイトルを付けます。
条件を設定する
| 条件 | 演算子 | 値 |
|---|---|---|
| チケット:ステータス | より小さい | 解決済み |
| チケット:保留になってからの時間 | より大きい | 168 |
| チケット:タグ | 次のいずれかを少なくとも1つ含む | stale_reminder_2 |
168時間は7日間に相当します。この自動化は、両方のリマインダーステージを通過したチケットでのみ実行されます。
アクションを設定する
| アクション | 値 |
|---|---|
| チケット:ステータス | 解決済み |
オプションで、クローズを説明する公開コメントを追加できます。「このチケットは、非アクティブ状態が続いたため、自動的に解決されました。まだサポートが必要な場合は、返信してください。すぐに再開します。」

重要なことがあります。Zendeskは、解決済みのチケットを4日後に自動的にクローズします。その部分を自分で構築する必要はありません。自動化はチケットを解決済みとしてマークします。Zendeskに組み込まれている「ステータスが解決済みに設定されてから4日後にチケットをクローズする」自動化が残りを処理します。
ステップ4:自動クローズを監視するためのビューを作成する
自動化が何をしているかを把握する必要があります。専用のビューを使用すると、ワークフローが機能していることを確認し、問題を特定できます。
管理センター>ワークスペース>エージェントツール>ビューに移動します。ビューを追加をクリックします。
「停滞チケット-自動クローズ」のような名前を付けます。
ビューの条件を設定する
| 条件 | 演算子 | 値 |
|---|---|---|
| タグ | 次のいずれかを少なくとも1つ含む | stale_reminder_2 |
| ステータスカテゴリ | 等しくない | 新規 |
これにより、ワークフローの最終段階に達したすべてのチケットが表示されます。パターンをスキャンしたり、クローズが適切に見えることを確認したり、人間のレビューが必要なエッジケースをキャッチしたりできます。

一部のチームは、各ステージ(最初のリマインダー送信、最終警告送信、自動解決)に対して個別のビューを作成します。ワークフローに合うようにしてください。重要なのは、盲目的に飛行するのではなく、可視性を持つことです。
自動化を安全にテストする
テストせずに自動化を本番環境にデプロイしないでください。ワークフローが正しく機能することを確認する方法を次に示します。
**テストチケットから開始します。**Zendeskインスタンスでチケットを作成し、保留に設定し、「stale_test」のようなテストタグを適用して、実際のトラフィックから分離します。
**条件を一時的に変更します。**自動化を複製し、「タグに次のいずれかを少なくとも1つ含む:stale_test」を追加条件として追加します。これにより、テストチケットのみが処理されるようになります。
より迅速なフィードバックのためにタイミングを調整します。「48より大きい」を一時的に「1より大きい」に変更します。自動化が機能するかどうかを確認するために2日間待つ必要はありません。
**自動化の実行を監視します。**1時間ごとの自動化サイクルが実行された後、テストチケットを確認します。タグは追加されましたか?メールは送信されましたか?ステータスは正しく変更されますか?
**顧客体験を確認します。**実際の通知メールを自分に送信します。見た目は正しいですか?リンクは機能していますか?トーンは適切ですか?
避けるべき一般的なテストの間違い:
- 自動化が即座にではなく、1時間ごとに実行されることを忘れる
- 解決済みまたはクローズされたチケットでテストする(自動化はこれらを無視します)
- 無効化タグが実際に再実行を防ぐことを確認しない
- メール配信の問題を見逃す(スパムフォルダーを確認する)
テストが完了したら、テストバージョンを非アクティブ化し、実際のバージョンをアクティブ化します。心配な場合は、チケットの小さなサブセットから開始します。一貫した正しい動作が見られたら、スケールアップします。
自動化が機能しない場合のトラブルシューティング
適切に構築された自動化でも、誤動作することがあります。一般的な問題を診断する方法を次に示します。
自動化がまったく作動しない:
- チケットのステータスが実際に「保留中」(「オープン」または「保留」ではない)であることを確認します
- 時間条件が「等しい」ではなく「より大きい」を使用していることを確認します
- 他の条件がターゲットチケットを除外していないことを確認します
- 自動化はすぐにではなく、1時間ごとに実行されることを覚えておいてください
顧客が複数のリマインダーを受け取る:
- 無効化タグが正しく追加されていることを確認します
- 「次のいずれも含まない」条件が存在することを確認します
- 同様の条件を持つ重複した自動化を探します
間違ったチケットが影響を受けている:
- タグの条件を注意深く確認します
- 干渉する可能性のある重複した自動化を確認します
- ビューが期待どおりに表示されていることを確認します
タイミングがずれているように見える:
- Zendeskは最後のステータス変更からの時間をカウントすることを覚えておいてください
- 顧客の返信は保留タイマーをリセットします
- 1時間ごとのチェックサイクルは、アクションが条件が満たされてから1時間以内に発生することを意味します。しきい値で正確に発生するわけではありません
自動化アクティビティの確認場所:
Zendeskは直接的な「自動化ログ」を提供していませんが、チケットイベントからアクティビティを推測できます。影響を受けるチケットを開き、イベントログを確認します。タグの追加、ステータスの変更、メール通知を探します。これらが予想される間隔で表示される場合、自動化は機能しています。
eesel AIで停滞チケットの管理をさらに進める
ネイティブのZendesk自動化は、時間ベースのルールを確実に処理します。しかし、それらは基本的にステータスとタイムスタンプに限定されています。会話を読んだり、緊急度を理解したり、顧客が実際に言ったことに基づいて適応したりすることはできません。
そこで、AIレイヤーが価値を発揮します。eesel AIでは、Zendeskと直接統合し、ワークフローにコンテキスト認識を追加するAIチームメイトを構築しました。
実際には次のようになります。
意図ベースの処理:「48時間経過したか?」を確認するだけでなく、AIは「顧客は実際に何を求めているのか?」を尋ねることができます。単純なパスワードのリセットは、より迅速に自動クローズされる可能性があります。複雑な請求紛争は、経過時間に関係なく、人間のレビューのためにフラグが立てられます。
デプロイ前のシミュレーション:シミュレーションモードを使用すると、ライブになる前に、数千の過去のチケットに対してAI処理をテストできます。実際の顧客にリスクを与えることなく、どのように実行されたかを正確に確認できます。
**段階的なロールアウト:**まず、エージェントレビューのために返信を下書きするAI Copilotから始めます。その精度に自信がついたら、応答を直接送信させます。最終的には、AI Agentを使用して、適切なチケットタイプの完全な解決を処理できます。
**自然言語制御:**プレーンな英語でエスカレーションルールを定義します。「「法的」または「弁護士」に言及するチケットは常にコンプライアンスチームにエスカレートします。」複雑な条件ビルダーは必要ありません。
このアプローチは、代替ではなく補完的です。Zendeskの自動化は、時間ベースの基盤を処理します。AIレイヤーは、その上にインテリジェンスを追加します。一緒に、それらは信頼性と適応性の両方を備えたシステムを作成します。
チームが停滞チケットに溺れている場合、または手動トリアージに時間を費やしすぎている場合は、AIがワークフローに追加できるものを検討する価値があります。
今すぐ停滞チケットのクリーンアップを自動化しましょう
これで、デプロイする準備ができた完全なZendesk自動化レシピの停滞クローズワークフローができました。シーケンスで動作する3つの自動化。結果を追跡するための監視ビュー。すべてが機能することを確認するためのテスト手順。物事がうまくいかない場合のトラブルシューティング手順。
構築したワークフローは、キューをクリーンに保ち、指標を正確にし、顧客に情報を伝えます。停滞チケットを手動で探す必要はもうありません。レポートを歪める膨張したバックログはもうありません。チームが実際に人間の注意を必要とするチケットに集中している間、ルーチンのクリーンアップを処理する信頼できるシステムだけです。
本番環境でこれらの自動化をアクティブ化する前に、テストチェックリストをもう一度実行してください。メールのコピーがブランドの声と一致することを確認します。タイミングがサービス基準と一致することを確認します。チームがワークフローがライブになることを知っていることを確認します。
自信がついたら、オンにします。最初の数日間、監視ビューを見てください。表示される内容に基づいて、タイミングまたはメッセージングを調整します。他の自動化と同様に、反復によって改善されます。
また、時間ベースのルールが提供できる以上のものを求めている場合は、eesel AIのようなAI搭載ツールがそのコンテキスト認識レイヤーを追加できることを覚えておいてください。Zendeskの信頼性の高い自動化基盤とインテリジェントな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.


