効率的なカスタマーサポートチームにとって、チケットの分類を正しく行うことは不可欠です。それがうまくいけば、より迅速な解決、より明確なレポート、そして最終的には、より満足度の高い顧客が得られます。Zendeskのチケットタイプは、サポートキューに秩序をもたらすように設計されたコア機能です。
デフォルト設定は多くのチームにとって非常に効果的ですが、成長中のチームは、これらの設定を特定のビジネスニーズに合わせてさらに調整する方法を探していることがよくあります。このガイドでは、標準のZendeskチケットタイプとは何か、チームがそれらをカスタマイズする一般的な方法、そしてAIがプロセスをどのように補完し、手動ソートからスマートで自動化されたトリアージに移行できるかをご紹介します。
Zendeskのチケットタイプとは？
では、Zendeskのチケットタイプフィールドとは一体何なのでしょうか？Zendeskに組み込まれた、最初のソートシステムと考えてください。これは、レポートの安定した基盤を提供する4つのプリセットオプションが付属する標準フィールドです。その目標は、エージェントと管理者に、チケットを大まかに分類する迅速な方法を提供することです。新しいチケットがキューに届くと、通常、適切なタイプを選択することが最初のステップとなり、次に何が起こるかを決定するのに役立ちます。
チケットタイプは、チケットステータス（新規、オープン、保留、解決済み、クローズ）および優先度（低、通常、高、緊急）とは異なります。ステータスはチケットのライフサイクルにおける位置を追跡し、優先度は緊急度を示す一方で、チケットタイプはリクエスト自体の性質を分類します。この区別は、チケットのルーティング、レポート、および解決方法に影響するため重要です。
ワークフローをさらに合理化したいチームのために、eesel AIはZendeskと統合して、受信リクエストのコンテンツに基づいてチケットタイプを自動的に提案します。これにより、エージェントの手動ソートの負担が軽減され、チーム全体でより一貫した分類が保証されます。
定義された4つのZendeskチケットタイプ
Zendeskには、4つのデフォルトオプションが用意されています。質問（Question）、問題（Problem）、インシデント（Incident）、タスク（Task）です。それぞれが何を意味し、いつ使用するかを詳しく見ていきましょう。
質問（Question）
質問（Question）チケットタイプは、障害や問題を示さない一般的な問い合わせや情報リクエストに使用されます。これは、単に情報を必要とする顧客のための包括的なカテゴリです。
一般的な例としては、次のものがあります。
- 「パスワードをリセットするにはどうすればよいですか？」
- 「営業時間は何時ですか？」
- 「年間サブスクリプションの割引はありますか？」
質問（Question）チケットは、トラブルシューティングや技術的な調査を必要としないため、通常は最も簡単に解決できます。また、整理されたヘルプセンターを通じて、自己解決を促すのに最適な候補です。
問題（Problem）
問題（Problem）チケットは、複数の顧客に影響を与える、より大きな根本的な問題を表します。これは、問題-インシデントの関係における主要な「親」チケットです。根本原因の分析が必要なシステム上の問題を特定した場合に、問題（Problem）チケットを作成します。
例としては、次のものがあります。
- 「EUのすべてのユーザーでログインページがダウンしています。」
- 「Visaカードの支払い処理が失敗しています。」
- 「ユーザーが写真をアップロードしようとすると、モバイルアプリがiOS 17でクラッシュします。」
覚えておくべき重要なことは、問題（Problem）チケットは、その原因に関する個々の顧客の苦情ではなく、根本原因を追跡することです。問題（Problem）チケットを解決すると、リンクされているすべてのインシデント（Incident）チケットを一度に自動的に解決できます。
インシデント（Incident）
インシデント（Incident）チケットは、より大きな問題に関する単一の顧客からの報告です。これらのチケットは、「子」としてメインの問題（Problem）チケットにリンクされます。複数の顧客が同じ根本的な問題を報告する場合、個々の報告はそれぞれインシデント（Incident）になります。
たとえば：
- 「ドイツにいますが、ログインできません。」（これはEUの停止問題にリンクされます）
- 「Visaカードで支払いができません。」
- 「写真をアップロードしようとするたびにアプリがクラッシュします。」
インシデント（Incident）チケットの力は、問題（Problem）チケットとの関係から生まれます。個々の顧客の苦情を個別に処理する代わりに、親の問題（Problem）にリンクし、根本原因が修正されたときにすべて一度に解決します。
タスク（Task）
タスク（Task）チケットタイプは、特定の日付までに完了する必要がある社内のTo-Do項目に使用されます。他のタイプとは異なり、タスク（Task）チケットには期日フィールドが含まれているため、締め切りがある作業の追跡に最適です。
例としては、次のものがあります。
- 「午後5時までにサーバー停止についてエンジニアリングチームにフォローアップしてください。」
- 「金曜日までに顧客との電話をスケジュールして、アカウント設定を確認してください。」
- 「発売前に新機能に関するナレッジベースの記事を更新してください。」
タスク（Task）チケットは、顧客の問題の解決に直接関係していませんが、追跡および完了する必要があるフォローアップ作業を管理するのに特に役立ちます。
問題-インシデントワークフローの理解
問題（Problem）チケットとインシデント（Incident）チケットの関係は、Zendeskのチケットタイプシステムが真価を発揮する場所です。これが実際にどのように機能するかを見ていきましょう。
一般的なワークフローは次のとおりです。
- 問題の特定: 複数の顧客が同じ問題を報告していることに気付くか、監視を通じてシステム上の問題を発見します。
- 問題（Problem）チケットの作成: これは、根本原因を追跡するための親チケットになります。
- インシデント（Incident）のリンク: 顧客が問題を報告したら、インシデント（Incident）チケットを作成し、問題（Problem）チケットにリンクします。
- 一度に解決: 問題（Problem）チケットで根本原因を解決すると、リンクされているすべてのインシデント（Incident）チケットが自動的に解決済みとしてマークされます。
利点は明らかです。サービス停止が解決されたときに50個の異なるチケットを個別に更新する代わりに、単一の問題（Problem）チケットを更新すると、Zendeskが残りを処理します。問題（Problem）チケットを解決するときに追加するコメントは、未解決のリンクされたすべてのインシデント（Incident）チケットに追加されるため、影響を受けるすべての顧客に通知されます。
実際の例を見てみましょう。あなたの会社がモバイルデバイス向けのゲームを作成しているとします。顧客から、新しいアバターをアップロードしようとするたびにアプリが閉じるとの報告が複数寄せられ始めます。これらのリクエストを個別に管理する（時間がかかり、混乱を招く可能性がある）代わりに、「アバターアップロードの問題」という問題（Problem）チケットを作成します。各顧客の報告は、この問題（Problem）に関連付けられたインシデント（Incident）として記録されます。
これで、この問題がたとえば47人の顧客から報告されていることを簡単に確認できます。チームが進捗状況を更新すると、問題（Problem）チケットが更新され、それらの更新が影響を受けるすべての顧客に反映されます。修正が展開されると、問題（Problem）チケットを解決し、47件のインシデント（Incident）チケットがすべて自動的に解決されます。エージェントは時間を節約し、顧客は全体を通して一貫したコミュニケーションを受け取ります。
各チケットタイプをいつ使用するか：意思決定フレームワーク
適切なチケットタイプの選択は、複雑である必要はありません。チームが一貫した意思決定を行うのに役立つ簡単なフレームワークを次に示します。
次の質問から始めます。
- これは一般的な情報リクエストですか？ → **質問（Question）**を使用
- これは、1人の顧客が自分だけに影響する問題を報告していますか？ → **質問（Question）を使用するか、新しいシステム上の問題の場合は問題（Problem）**を作成
- 複数の顧客が同じ根本原因の影響を受けていますか？ → **問題（Problem）**を作成し、**インシデント（Incident）**をリンク
- これは締め切りがある社内タスクですか？ → **タスク（Task）**を使用
避けるべき一般的な間違い：
- 単一の顧客の問題に問題（Problem）チケットを使用する（不要なオーバーヘッドが発生する）
- 問題（Problem）にリンクせずにインシデント（Incident）を作成する（目的を損なう）
- 問題（Problem）であるはずの問題に質問（Question）を使用する（効率的な解決の機会を逃す）
- タスク（Task）チケットに期日を設定するのを忘れる（タスク（Task）を使用する目的を損なう）
一貫性を維持するためのヒント：
- 簡単な決定木を作成し、チームと共有する
- エージェントのトレーニングにチケットタイプの選択を含める
- Zendeskの必須フィールド設定を使用して、チケットタイプが常に選択されていることを確認する
- レポートでチケットタイプの使用状況を確認して、矛盾を検出する
AIによるチケットタイプの分類の自動化
手動によるチケットのソートには時間がかかります。経験豊富なエージェントでも、解釈に基づいて同じチケットを異なる方法で分類することがあります。ここで、AI搭載のトリアージが役立ちます。
eesel AIのAIトリアージは、Zendeskと連携して、顧客の意図をより深く理解します。新しいチケットが到着すると、eesel AIはコンテンツを分析し、顧客が実際に質問している内容に基づいて、適切なチケットタイプを自動的に提案します。
これが単純なキーワードマッチングと異なる点は何ですか？eesel AIは、チームの過去のデータから学習します。接続した瞬間から、独自のビジネスコンテキストを理解し始めます。チームがさまざまな問題をどのように分類するか、顧客がどのような言語を使用するか、通常どのような種類のリクエストが問題（Problem）になるか、質問（Question）になるかを理解します。
セットアップは簡単です。ワンクリックZendesk統合を使用すると、eesel AIを接続し、過去のチケットで数分でシミュレーションを実行できます。これにより、ライブワークフローに変更を加える前に、期待できる効率の向上をデータに基づいて確認できます。
大量のチケットを処理するチームにとって、この自動化により、分類の一貫性を向上させながら、大幅な時間を節約できます。エージェントは手動によるソートに費やす時間を減らし、顧客の問題を実際に解決することに多くの時間を費やします。
Zendeskのチケットタイプを最大限に活用する
チケットタイプは、チームが実際には一貫して使用している場合にのみ役立ちます。それらを日々のワークフローの一部にするための実用的なヒントを次に示します。
チームトレーニング：
- オンボーディングプロセスにチケットタイプの選択を含める
- 各タイプの明確な例を含む内部ドキュメントを作成する
- 問題-インシデントワークフローが時間を節約できたときの成功事例を共有する
カスタムフィールド： 多くのチームは、より詳細な分類のために、ネイティブの「タイプ」フィールドをカスタムドロップダウンフィールドで補完しています。ネイティブの問題-インシデントのリンクは組み込みの「タイプ」フィールドでのみ機能することを覚えておいてください。カスタムフィールドを追加した場合でも、アクティブにしておいてください。
ビューと自動化： チケットタイプでフィルタリングされたZendeskビューを設定して、エージェントが特定のカテゴリに集中できるようにします。タイプに基づいて異なるワークフローをトリガーするために自動化を使用します。問題（Problem）と質問（Question）で異なるSLA、自動割り当てルール、またはエスカレーションパスなどです。
レポート： レポートでチケットタイプの分布を追跡して、チームが最も処理する問題の種類を理解します。このデータは、人員配置の決定、トレーニングの優先順位、および製品の改善に役立ちます。
カスタマーサポートの自動化をさらに進めたいチームにとって、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.
