Zendeskでチケットのステータスを一括更新する方法：完全ガイド

何百ものチケットを1つずつ更新するという困難な作業に直面したことがあるなら、その苦痛はご存知でしょう。製品の発売がうまくいかず、チケットを再割り当てする必要があるかもしれません。あるいは、ポリシーが変更され、カテゴリ全体に新しいタグを追加する必要があるかもしれません。または、単にチケットのバッチで間違ったステータスを選択してしまい、それを迅速に修正する必要があるのかもしれません。

理由が何であれ、チケットを手動で個別に更新することは、サポートチームが費やす余裕のない時間の浪費です。良い知らせは？ Zendeskは、一括更新を処理するためのいくつかの方法を提供しています。あまり良くない知らせは？ 各アプローチには制限があり、ネイティブツールでは1回のアクションあたり100件のチケットに制限されています。

このガイドでは、Zendeskでチケットのステータスを一括更新する方法、直面する制限、およびネイティブなアプローチが不十分な場合の代替手段について説明します。

Zendeskのネイティブな一括更新機能について

手順に入る前に、Zendeskの組み込みの一括更新で実際に何ができるかを明確にしましょう。

この機能は、チケットビューの中にあります。1つ以上のチケットを選択すると、リストの下部にツールバーが表示され、編集、削除、結合、またはスパムとしてマークするオプションが表示されます。編集オプションは、ステータスの一括変更に使用するものです。

以下は、一括で更新できるものです。

• チケットステータス（新規、オープン、保留中、解決済み、保留）
• 担当者（エージェントまたはグループ）
• タグ（追加または削除）
• 優先度（低、普通、高、緊急）
• カスタムフィールド
• 複数のチケットにコメントを追加

ただし、重要な制約があります。一度に更新できるチケットの最大数は100件です。クローズされたチケットを一括更新することはできません（完全にロックされています）。また、チケットが「新規」から別のステータスに移行すると、UIを通じて「新規」に戻すことはできません（ただし、APIには回避策があります）。

また、一括更新はチケット履歴に「Webサービス（API）」イベントとして記録されることにも注意してください。「チケット：経由で更新」条件に基づくトリガーがある場合は、予期していなかった自動化が起動する可能性があるため、これを考慮してください。

チケットのステータスを一括更新する方法（ステップバイステップ）

実際にこれを行う準備はできましたか？ 完全なプロセスは次のとおりです。

ステップ1：チケットビューを作成または開く

まず、更新するチケットを1つのビューに入れる必要があります。既存のビューを使用するか、変更する必要があるチケットを正確にキャプチャするフィルターを使用して新しいビューを作成できます。

ビューリストに移動し、既存のビューを選択するか、「ビューを追加」をクリックして新しいビューを作成します。新しく作成する場合は、「ステータスが保留中」または「タグにXが含まれている」などの条件を設定して、更新するチケットを分離します。

ステップ2：一括更新するチケットを選択する

ビューがロードされると、各チケットの横にチェックボックスが表示されます。選択には2つのオプションがあります。

• チェックボックスをオンにして個々のチケットを選択する
• リストの左上にあるチェックボックスをクリックして、表示されているすべてのチケットを選択する

ここで、100件のチケット制限が適用されます。ビューに100件を超えるチケットがある場合は、バッチで処理する必要があります。良い知らせ：別のページに移動しても、選択はチェックされたままなので、大量のチケットを体系的に処理できます。

チケットを選択すると、画面の下部にツールバーが表示され、選択されているチケットの数と使用可能なアクションが表示されます。

ステップ3：ステータスの一括変更を適用する

ツールバーの「編集」をクリックして、一括更新ダイアログを開きます。これは、単一のチケット編集画面に似ていますが、選択したすべてのチケットに適用されます。

ステータスを変更するには：

1. ダイアログでステータスフィールドを見つけます
2. ドロップダウンから新しいステータスを選択します
3. これらのチケットが更新された理由を文書化する場合は、コメントを追加します（オプションですが、監査証跡には推奨されます）
4. ここで更新する他のフィールドを確認します

注意すべき点の1つ：件名行で動的コンテンツまたはプレースホルダーを使用するマクロを適用すると、更新されたチケットは、レンダリングされた値の代わりに角かっこで囲まれたプレースホルダーとともに保存される場合があります。たとえば、実際の日付の代わりに{{ticket.created_at}}が表示される場合があります。

ステップ4：更新を確認する

「送信」をクリックして変更を適用します。Zendeskが更新を処理し、確認メッセージを表示します。システムは、プロセス中に各チケットの最終更新タイムスタンプを比較します。一括アクションを開始した後にチケットが変更された場合（つまり、他の誰かが編集した場合）、その特定のチケットはエラーでスキップされ、残りのチケットは処理を続行します。

送信後、いくつかのチケットをスポットチェックして、ステータスの変更が正しく適用されていることを確認します。タグまたはカスタムフィールドも期待どおりに更新されていることを確認します。

ネイティブな一括更新の制限と回避策

100件のチケット制限は、サポートチームが直面する最大の制約です。1,000件のチケットを更新する必要がある場合は、10回の一括アクションが必要になります。これは退屈で時間がかかります。

知っておくべきその他の制限：

100件を超えるチケットの一括更新が定期的に必要なチームにとって、ネイティブなアプローチは単にスケールしません。そこで代替手段が登場します。

チケットを一括更新するための代替方法

ネイティブな100件のチケット制限がボトルネックになる場合は、主に3つの代替手段があります。

Zendesk APIの使用

技術リソースを持つチームの場合、Zendesk APIはupdate_manyエンドポイントを提供します。これにより、プログラムでAPI呼び出しごとに最大100件のチケットを更新できます。これは同じ制限のように聞こえますが、違いは自動化です。手動でクリックすることなく、数千件のチケットを処理するために、連続したAPI呼び出しをスクリプト化できます。

APIアプローチには以下が必要です。

• 開発者または技術に精通したチームメンバー
• ZendeskのAPI認証の理解
• スクリプトの知識（Python、Rubyなど）
• 失敗した更新のエラー処理

一回限りの一括更新の場合、これはおそらくやりすぎです。ただし、チームが大規模なチケット変更を定期的に必要とする場合は、簡単なスクリプトを作成するとすぐに効果を発揮します。

自動化とトリガー

場合によっては、最適な一括更新は自動的に行われるものです。Zendeskの自動化は時間ベースの条件で実行され、トリガーはチケットイベントで起動します。

たとえば、72時間後に「保留中」から「解決済み」にチケットを手動で一括更新する代わりに、これを自動的に行う自動化を作成できます。または、チケットが特定の基準を満たした場合にタグを追加するトリガーを使用します。

このアプローチは、一回限りの状況ではなく、予測可能で反復的な一括変更に最適です。

サードパーティ製アプリ

Zendesk Marketplaceは、一括更新機能を拡張するアプリを提供しています。SwifteqのAdvanced Search Plusは、Zendeskのネイティブ制限を超える一括更新を提供する一般的なオプションの1つであり、無料です。

これらのアプリは通常、以下を提供します。

• 一括アクションのチケット制限の引き上げ
• より柔軟な検索とフィルタリング
• CSVエクスポート機能
• 追加の一括操作

トレードオフは、ツールをスタックに追加し、チケットデータへのアクセスを許可する可能性があることです。

一括更新のベストプラクティス

何百ものチケットで「送信」ボタンをクリックする前に、次の推奨事項を検討してください。

• 最初に小さなバッチでテストします。 5〜10件のチケットを選択して、更新を実行します。大量のチケットを処理する前に、結果を確認してください。

• ビューフィルターを再確認します。 ビューが更新するチケットを正確にキャプチャしていることを確認してください。フィルターの間違いは、間違ったチケットを更新することを意味する可能性があります。

• プロセスを文書化します。 チームの手順を書き留めます。誰かが6か月後にこれを再度行う必要がある場合、最初からやり直す必要はありません。

• トリガーの影響を検討します。 一括更新はAPIイベントとして起動します。「チケット：API経由で更新」で実行されるトリガーがある場合、それらが実行されます。大規模な一括操作の前にトリガーを確認してください。

• 顧客とコミュニケーションをとります。 一括更新に顧客が見るステータスの変更（「解決済み」への移行など）が含まれる場合は、最初に通知する必要があるかどうかを検討してください。

• 営業時間外に作業します。 非常に大規模な一括更新の場合は、チケットの量が少ないときに実行することを検討してください。これにより、一括アクションの処理中にチケットが変更されるタイムスタンプの競合の可能性が低減されます。

よりスマートなアプローチ：eesel AIによるインテリジェントなチケット自動化

一括更新は症状（チケットの変更が必要）を解決しますが、原因（なぜ同じ更新が必要なチケットがこんなに多いのか）は解決しません。ここで、問題について異なる考え方をします。

eesel AIでは、これをビジネスを学習し、単に一括でだけでなく、インテリジェントにチケットを処理するAIチームメイトとしてアプローチします。「保留中」から「解決済み」に500件のチケットを手動で更新する代わりに、AIエージェントがそれらのチケットを確認し、実際に解決されたチケットを判断し、自動的に処理したらどうでしょうか？

仕組みは次のとおりです。eesel AIをZendeskアカウントに接続します。過去のチケット、ヘルプセンターの記事、マクロからすぐに学習します。最初にeeselがレビュー用の返信を作成することから始めます。それが証明されるにつれて、完全な自動化にレベルアップします。

重要な違い：eeselは、単純なルールに基づいて一括更新するだけではありません。各チケットを読み、コンテキストを理解し、適切なアクションを実行します。エスカレーションが必要なチケットは人に送られます。ルーチンなチケットは自動的に解決されます。

特に一括操作の場合、eeselは次のことができます。

• 無制限のチケットを処理する（100件のチケット制限なし）
• ステータス変更についてコンテキストを認識した決定を下す
• プレーンな英語でビジネスルールを適用する（「払い戻し要求が30日を超える場合は、丁寧に拒否する」）
• 修正から学習して、時間の経過とともに改善する

ライブになる前に過去のチケットでシミュレーションを実行できるため、eeselがそれらをどのように処理するかを正確に確認できます。実際の顧客との会話に触れるときに驚きはありません。

特定のステータスでチケットが積み重なっているために定期的に一括更新を行っている場合は、インテリジェントな自動化がそれらのチケットを個別に到着時に処理し、一括修正の必要性をなくすことができるかどうかを検討する価値があるかもしれません。

ニーズに合った一括更新方法の選択

各アプローチがいつ理にかなっているかを分析してみましょう。

ほとんどのチームにとって、ネイティブな一括更新は状況の80％を処理します。その100件のチケット制限に定期的に達する場合は、APIスクリプト、サードパーティ製アプリ、またはAI自動化によるワークフローの再考など、別のアプローチが必要になる可能性があるというシグナルです。

結論は？ 一括更新は絆創膏です。問題の修正には役立ちますが、毎週使用している場合は、同じ変更が必要なチケットが非常に多い理由と、自動化で問題を最初に防ぐことができるかどうかを検討する価値があります。

よくある質問

Q1：Zendeskで一度に100件以上のチケットを一括更新できますか？ A1：ネイティブインターフェースではできません。Zendeskの組み込みの一括更新は、1回のアクションにつき100件のチケットに制限されています。より大量のチケットを処理するには、Zendesk API、SwifteqのAdvanced Search Plusのようなサードパーティ製アプリを使用するか、チケットを複数のバッチで処理する必要があります。

Q2：一括更新でチケットを「新規」ステータスに戻せないのはなぜですか？ A2：チケットが「新規」から他のステータスに移行すると、ZendeskのUIでは「新規」に戻すことができなくなります。これは、チケットのワークフローの整合性を維持するための仕様です。ただし、どうしても必要な場合は、Zendesk APIを使用してチケットを「新規」に戻すことができます。

Q3：一括更新はZendeskの自動化とトリガーを起動しますか？ A3：はい。一括更新は「Webサービス（API）」イベントとして記録されます。「チケット：API経由で更新」条件で実行されるトリガーまたは自動化がある場合、一括更新を実行するとそれらが起動します。意図しない副作用を避けるために、大規模な一括操作の前にトリガーを確認してください。

Q4：Zendeskでクローズされたチケットを一括更新できますか？ A4：いいえ。クローズされたチケットは、一括更新または標準UIを通じて変更することはできません。クローズされたチケットはアーカイブされ、ロックされていると見なされます。チケットがクローズされる前に更新する必要がある場合は、「解決済み」ステータスウィンドウ中に変更を行うように自動化を設定します。

Q5：Zendeskの一括更新と自動化の違いは何ですか？ A5：一括更新は、選択したチケットに対して今すぐ実行する手動アクションです。自動化は、時間ベースの条件（「72時間以上保留中」など）が満たされたときに自動的に実行されるルールです。一回限りの変更には一括更新を使用し、反復的で予測可能な更新には自動化を使用します。

Q6：一括更新を実行する際にリスクはありますか？ A6：主なリスクは、（誤ったビューフィルターのために）間違ったチケットを更新してしまうことと、意図しない自動化を起動してしまうことです。常に最初に小さなバッチでテストし、ビューフィルターを再確認し、大規模な一括更新を実行する前にトリガーを確認してください。一括更新は元に戻せないことを覚えておいてください。