Zendeskでチケットタイプ（インシデント、問題、タスク）を自動化する方法：ガイド

大量のサポートキューを管理するということは、チケットをどのように分類し、ルーティングするかについて迅速な意思決定を行うことを意味します。チームが毎日何百ものチケットのタイプを手動で設定していると、間違いが発生します。質問がインシデントとしてマークされます。タスクが間違ったキューに置かれます。問題は、数十件の関連チケットが発生するまで気付かれません。

そこでZendeskの自動化が登場します。特定の条件に基づいてチケットタイプを自動的に割り当てるルールを設定することで、手作業を減らし、分類の精度を向上させ、チケットが作成された瞬間から適切なワークフローに従うようにすることができます。

このガイドでは、Zendeskでチケットタイプを割り当てる自動化を設定する方法を正確に説明します。停止レポートをインシデントとしてルーティングする必要がある場合でも、繰り返し発生する問題を問題としてフラグを立てる必要がある場合でも、フォローアップアイテムをタスクに変換する必要がある場合でも、それを実現するための具体的な手順を学びます。

開始するために必要なもの

自動化の構築を開始する前に、次のものが揃っていることを確認してください。

• Teamプラン以上のZendesk Supportアカウント（自動化はEssentialプランでは利用できません）
• 管理者権限、またはビジネスルール管理アクセス権を持つカスタムロール
• 現在のチケットワークフロー、および質問、インシデント、問題、またはタスクとして分類する必要があるリクエストのタイプの明確な理解
• オプション：インシデントを問題にリンクするための高度なWebhookベースの自動化を設定する場合は、APIトークン

Zendeskのビジネスルールを初めて使用する場合は、トリガーと自動化の違いを理解しておくと役立ちます。トリガーは、チケットが作成または更新されたときにすぐに発動します。自動化はスケジュール（通常は1時間ごと）で実行され、条件を確認します。「2時間後にチケットタイプを設定する」などの時間ベースのワークフローには、自動化を使用します。即時アクションには、トリガーを使用します。

Zendeskのチケットタイプについて

Zendeskは4つのチケットタイプを提供しており、それぞれが特定の種類のサポートインタラクション向けに設計されています。これらのタイプを正しく理解することが重要です。なぜなら、各タイプは異なる動作をし、異なるワークフローをトリガーするからです。

質問（Question）

ほとんどのチケットのデフォルトタイプ。システム全体の問題を示さない、情報が必要な場合や何かのヘルプが必要な一般的な問い合わせに使用します。「パスワードをリセットするにはどうすればよいですか？」または「払い戻しポリシーは何ですか？」は、典型的な質問です。

インシデント（Incident）

複数の顧客が同じ根本的な問題を報告する場合に使用します。インシデントは、より大きな問題に対する1人の顧客の経験を表します。重要な機能：インシデントは問題チケットにリンクでき、その問題が解決されると、リンクされたすべてのインシデントが自動的に解決されます。

問題（Problem）

複数のインシデントの背後にある根本原因を表します。認証システムがダウンし、50人の顧客がログインできない場合、根本的な問題を追跡するために1つの問題チケットを作成します。個々の顧客レポートをインシデントとしてその問題にリンクすると、問題を解決することでそれらすべてが解決されます。

タスク（Task）

特定の日付までに完了する必要がある追跡可能な作業項目に使用します。他のチケットタイプとは異なり、タスクには期日フィールドがあります。内部フォローアップ、定期メンテナンス、または期限までに実行する必要がある作業に役立ちます。

問題とインシデントの関係は特に強力です。50件のチケットを個別に解決する代わりに、1つの問題を解決すると、Zendeskが残りを処理します。ただし、これはチケットが正しくタイプされ、リンクされている場合にのみ機能します。そこで自動化が登場します。

チケットタイプを割り当てる自動化の設定

基準に基づいてチケットタイプを設定する自動化の作成について説明しましょう。実用的な例として、顧客が停止を報告したときにチケットを自動的にインシデントとしてマークします。

ステップ1：自動化ページへのアクセス

Zendeskサイドバーの歯車アイコンをクリックして、管理センターに移動します。「オブジェクトとルール」を選択し、次に「ビジネスルール」、次に「自動化」を選択します。

既存の自動化のリストが表示されます。これには、Zendeskがアカウント用に作成したデフォルトの自動化も含まれます。順序に注意してください。自動化は上から下に実行され、必要に応じて並べ替えることができます。

ステップ2：新しい自動化の作成

右上の「自動化を追加」をクリックします。自動化が何をするかを正確に説明するわかりやすい名前を付けます。6か月後にトラブルシューティングを行う場合は、適切な名前が重要です。

良い名前：「停止レポートの場合、1時間後にインシデントタイプを自動設定」

悪い名前：「インシデント自動化」

目的と特別な条件を説明する説明を追加します。これにより、他の管理者は条件をリバースエンジニアリングしなくても、ロジックを理解できます。

ステップ3：条件の定義

ここで、この自動化をいつ実行するかをZendeskに指示します。自動化には、少なくとも1つの時間ベースの条件が必要であり、同じチケットで継続的に実行されないようにするロジックを含める必要があります。

停止の例では、「次のすべての条件を満たす」の下に次の条件を追加します。

• 作成からの時間 ＞ 次の値より大きい ＞ 1
• チケット：タイプ ＞ 次と等しい ＞ 質問
• チケット：件名テキスト ＞ 次のいずれかの単語を含む ＞ 停止 ダウン 利用不可 ログインできない
• タグ ＞ 次のいずれも含まない ＞ タイプ処理済み

最初の条件は、これを時間ベースにします。これは、すべての自動化に必要です。2番目の条件は、まだタイプされていないチケットのみを処理するようにします。3番目の条件は、停止関連のチケットを識別します。4番目の条件は無効化条件です。再処理を防ぐために、「タイプ処理済み」タグをアクションとして追加します。

重要な制限事項：時間ベースの条件は、「次のいずれかの条件を満たす」セクションでは使用できません。すべての時間条件は、「すべて満たす」セクションにある必要があります。時間条件にORロジックが必要な場合は、複数の自動化が必要になります。

ステップ4：チケットタイプのアクションの設定

「次のアクションを実行」の下に、次を追加します。

• チケット：タイプ ＞ インシデント

これは、チケットタイプを変更するコアアクションです。ワークフローのニーズに応じて、質問、インシデント、問題、またはタスクに設定できます。

チケットをインシデントに設定し、既存の問題チケットにリンクする場合は、代わりにWebhookアクションを使用する必要があります。ネイティブの自動化アクションはタイプのみを変更します。リンクに必要なproblem_idフィールドは処理しません。高度なセクションでWebhookアプローチについて説明します。

ステップ5：無効化条件の追加

自動化が繰り返し実行されるのを防ぐために、このアクションを追加します。

• チケット：タグを追加 ＞ タイプ処理済み

これは、ステップ3で追加した「次のいずれも含まない」条件と連携します。自動化が実行されると、チケットにタグが付けられます。次に自動化が実行されるとき（毎時）、そのチケットにはタグが付いているため、条件に一致しなくなります。

無効化条件がないと、自動化は同じチケットで毎時間実行され、重複した通知が作成され、顧客に通知スパムが発生する可能性があります。

ステップ6：テストとアクティブ化

アクティブ化する前に、「プレビュー」機能を使用して、どの既存のチケットが条件に一致するかを確認します。これは、ロジックエラーを検出するのに役立ちます。

条件に一致するテストチケットを作成します（例では、件名に「停止」が含まれています）。自動化が実行されるまで待ち（通常は毎時間処理されます）、次のことを確認します。

• チケットタイプがインシデントに変更された
• 「タイプ処理済み」タグが追加された
• チケットが自動化の「影響を受けるチケット」数に表示される

すべてが正常に機能することを確認したら、自動化をアクティブ化します。新しい自動化はデフォルトでアクティブですが、最初にテストする場合は非アクティブな自動化を作成できます。

各チケットタイプの実用的な自動化の例

メカニズムを理解したので、ワークフローに合わせて調整できる具体的な自動化レシピを次に示します。

インシデントチケットの自動設定

シナリオ：顧客がサービスの停止に関するチケットを送信した場合、マスター問題チケットにリンクできるように、タイプを自動的にインシデントに設定します。

条件：

• 作成からの時間 ＞ 次の値より大きい ＞ 1
• チケット：タイプ ＞ 次と等しい ＞ 質問
• チケット：件名テキスト ＞ 次のいずれかの単語を含む ＞ 停止 ダウン 利用不可 サービス中断
• タグ ＞ 次のいずれも含まない ＞ 自動インシデント

アクション：

• チケット：タイプ ＞ インシデント
• チケット：タグを追加 ＞ 自動インシデント
• 通知：メールグループ ＞ サポートマネージャー（オプションのアラート）

パターンからの問題チケットの作成

シナリオ：短い時間枠内に同じタグが付いた複数のチケットが到着した場合、根本原因分析のために問題チケットにエスカレートします。

これには、2部構成のアプローチが必要です。まず、トリガーはコンテンツに基づいてチケットにタグを付けます。次に、自動化はボリュームを確認します。

自動化の条件：

• 作成からの時間 ＞ 次の値より大きい ＞ 2
• チケット：タイプ ＞ 次と等しい ＞ 質問
• チケット：タグ ＞ 次のいずれかを含む ＞ 潜在的な停止
• タグ ＞ 次のいずれも含まない ＞ 問題確認済み

アクション：

• 通知：メールユーザー ＞ サポートマネージャーにメッセージ：「過去2時間に「潜在的な停止」というタグが付いた複数のチケットが作成されました。問題チケットの作成を検討してください。」
• チケット：タグを追加 ＞ 問題確認済み

注：Zendeskの自動化では、実際に新しいチケットを作成することはできません。真の自動化された問題チケットの作成には、Webhookまたは外部ツールを介してZendesk APIを使用する必要があります。

内部ワークフローのタスク自動化

シナリオ：特定の日付以降にフォローアップが必要なチケットを、期日付きのタスクに変換します。

条件：

• 作成からの時間 ＞ 次の値より大きい ＞ 24
• チケット：タイプ ＞ 次と等しい ＞ 質問
• チケット：タグ ＞ 次のいずれかを含む ＞ フォローアップが必要
• タグ ＞ 次のいずれも含まない ＞ タスク作成済み

アクション：

• チケット：タイプ ＞ タスク
• チケット：タグを追加 ＞ タスク作成済み

残念ながら、Zendeskの自動化では期日を直接設定できません。期日フィールドは、手動またはAPIで設定する必要があります。タイプがタスクに変更されると、エージェントは期日フィールドを表示し、適切に設定できます。

高度：リアルタイムのタイプ割り当てにトリガーを使用する

1時間後ではなく、すぐにチケットタイプを設定する必要がある場合があります。その場合は、自動化ではなくトリガーを使用します。

主な違い：

• トリガーは、チケットが作成または更新されたときにすぐに発動します
• 自動化は、スケジュール（毎時）で実行され、時間ベースの条件を確認します

即時のタイプ割り当ての場合は、代わりにトリガーを作成します。

トリガーの条件：

• チケット ＞ 次と等しい ＞ 作成済み
• チケット：件名テキスト ＞ 次のいずれかの単語を含む ＞ 払い戻し 請求 請求

トリガーのアクション：

• チケット：タイプ ＞ タスク
• チケット：グループ ＞ 請求チーム
• チケット：タグを追加 ＞ 請求タスク

このアプローチは、即時の分類が必要な場合に適しています。欠点：トリガーは、「作成からの時間」などの時間ベースの条件を使用できません。トリガーの設定の詳細については、チケットが作成されたときのZendeskトリガーの作成に関するガイドを参照してください。

よくある間違いとその回避方法

経験豊富な管理者でも、これらの問題に遭遇します。

無効化条件の欠落。すべての自動化には、同じチケットでの実行を停止する方法が必要です。これがないと、同じチケットで毎時間通知が無限に届きます。常にタグベースの条件と対応する「タグを追加」アクションを含めます。

自動化の競合。自動化Aがタイプをインシデントに設定し、自動化Bがタイプをタスクに設定する場合、最後に実行された方が優先されます。自動化の順序と条件を確認して、競合を防ぎます。チケットが1つの自動化にのみ一致するように、特定のタグを使用します。

トリガーの方が適している場合に自動化を使用する。即時アクションが必要な場合は、トリガーを使用します。自動化には、スケジュールで実行されるため、組み込みの遅延（最大1時間）があります。「作成からの時間 ＞ 次の値より大きい ＞ 0」を回避策として使用しないでください。それはトリガーの目的です。

条件が広すぎる。「件名に「the」が含まれている」という条件は、ほぼすべてのチケットに一致します。アクティブ化する前に、プレビュー機能で条件をテストします。キーワードを絞り込み、可能な場合は「次のいずれかを含む」ではなく「次のすべてを含む」を使用します。

更新を忘れる。自動化が件名のキーワードに基づいてタイプを設定する場合、エージェントが件名を編集するとどうなりますか？チケットの更新に個別のロジックが必要かどうか、または「作成からの時間 ＜ 24」などの条件を追加して、新しいチケットのみを処理することを検討してください。

eesel AIで自動化をさらに進める

Zendeskのネイティブ自動化は、明確で予測可能なパターンに適しています。件名に「停止」が含まれている場合は、タイプをインシデントに設定します。リクエスターがVIP組織にいる場合は、優先度を「高」に設定します。これらは決定論的なルールです。機能するか、機能しないかです。

しかし、実際のサポートは必ずしもそれほどクリーンではありません。顧客はさまざまな方法で問題を説明します。緊急度は、キーワードでは捉えられないコンテキストに依存します。そして、新しいタイプのリクエストが常に発生します。

そこで、AI搭載のトリアージが登場します。すべてのシナリオのルールを作成する代わりに、過去のチケットでAIをトレーニングします。AIは、存在することに気付いていないパターンを学習します。「ログインできず、上司が今日このレポートを必要としている」と言う顧客は、「緊急」という言葉を使用していなくても、正しくルーティングされます。

私たちはまさにこれを処理するためにeesel AIを構築しました。Zendeskに接続し、トリガーと自動化と連携して動作します。ルールから始めて、役立つ場所にAIを追加し、手動構成からインテリジェントな自動化に徐々に移行できます。

当社のAIトリアージ製品は、チケットの分類を専門的に処理します。コンテンツ分析に基づいて、チケットタイプ、優先度、割り当てを自動的に提案します。エージェントの修正から学習するため、時間の経過とともに改善されます。また、ルールが見逃すエッジケースを処理します。

違いは何ですか？ルールは指示に従います。AIは結果から学習します。

今すぐZendeskチケットタイプの自動化を開始しましょう

チケットの分類という反復的な作業を処理する自動化を構築するために必要なものがすべて揃いました。単純なことから始めましょう。特定タイプのリクエストをルーティングするか、特定のチケットタイプを設定する1つの自動化です。条件とアクションがどのように相互作用するかを理解します。次に、そこから拡張します。

最適な自動化設定は、有機的に成長します。新しいシナリオが発生したらルールを追加します。完全に機能しない場合は、ルールを調整します。時間の経過とともに、人間の介入なしにほとんどのチケットを正しく分類するシステムを構築します。

エッジケースを処理するためにますます複雑なルールを作成している場合は、AIが役立つかどうかを検討する時期かもしれません。eesel AIを無料でお試しくださいまたはデモを予約するして、インテリジェントなトリアージが既存の自動化とどのように連携するかを確認してください。