サポートチームを管理するということは、何百(時には何千)もの顧客との会話を追跡することを意味します。明確なシステムがなければ、チケットは抜け落ち、エージェントは次のタスクを探すのに時間を浪費し、マネージャーはチームのパフォーマンスを把握できなくなります。
ここでZendeskチケットビューが登場します。ビューをサポートキューのスマートプレイリストと考えてください。終わりのないチケットのリストをスクロールする代わりに、チームは定義した条件に基づいて整理されたリストを表示します。割り当てを待っている新しいチケット。SLA違反が迫っている優先度の高い問題。フォローアップが必要な保留中のチケット。
マネージャーにとって、適切に設計されたビューは、受動的な火消しと積極的なチーム監督の違いになります。このガイドでは、チームに合わせて拡張できるビューシステムを構築するために必要なすべてを説明します。

Zendeskチケットビューとは何ですか?また、マネージャーにとってなぜ重要ですか?
Zendeskチケットビューは、設定した条件に基づいてチケットをリストに整理する保存されたフィルターです。(一度限りの手動操作である)検索とは異なり、ビューは自動的に更新されます。チケットが条件を満たすと、ビューに表示されます。一致しなくなると、消えます。
これがマネージャーにとって重要な理由を以下に示します。
- 可視性(かしかせい): ステータスの更新を依頼しなくても、チームが何に取り組んでいるかを正確に把握できます。
- 説明責任(せつめいせきにん): すべてのチケットに担当者がいて、誰も触れていないものがないようにします。
- 優先順位付け(ゆうせんじゅんいづけ): 問題になる前に、緊急の問題を表面化させます。
- 拡張性(かくちょうせい): 明確に整理されたキューを使用して、新しいエージェントをより迅速にオンボードします。
ビューは既存のワークフローと連携して動作します。また、トリアージプロセスにインテリジェンスを追加する準備ができたら、eesel AIのようなツールを使用して、チケットの内容を分析し、感情、緊急度、意図によって自動的に分類できます(ビューを置き換えるのではなく、ビューと連携します)。
すべてのマネージャーが設定すべきエッセンシャルなZendeskチケットビュー
すべてのビューが同じように作成されているわけではありません。すべてのマネージャーに必要なカテゴリを以下に示します。
フェイルセーフビュー:未解決のチケットすべて
これはあなたの安全網です。「未解決のチケットすべて」ビューは、他のビューの隙間から抜け落ちたものをキャッチします。
構成(こうせい):
- 条件(じょうけん): ステータスが解決済み未満
- 並べ替え(ならべかえ): ID(昇順)またはリクエスト日(古い順)
- グループ化(ぐるーぷか): (グループなし)
なぜ古い順ですか?ビューアーキテクチャにギャップがある場合(そして最終的には発生します)、このビューは一番上に最も古い未処理のチケットを表示します。一目見ただけで、チケットがブラックホールに落ち込んでいるかどうかを判断できます。

チームのワークロードビュー
これらのビューは、チーム全体の作業のバランスを取るのに役立ちます。
- 未割り当てのチケット: 担当者を待っている新しいチケット。条件: 担当者が( )
- チームのオープンチケット: 現在作業中のチケット。条件: ステータスがオープン、グループが[あなたのチーム]
- 保留中のチケット: 顧客の応答を待っています。条件: ステータスが保留中
優先度とリスクのビュー
すぐに注意が必要なチケットを表面化させます。
- 高優先度/緊急: 条件: 優先度が「高」または「緊急」
- SLAリスクあり: 条件: 次のSLA違反までの時間が4時間未満
- エスカレートされたチケット: 条件: タグに「エスカレート」が含まれているか、グループがTier 2/Tier 3
Zendeskでビューを作成および整理する方法
ビュー管理ページへのアクセス
ビューを作成または編集するには、管理センター > ワークスペース > エージェントツール > ビューに移動します。
次の2種類のビューが表示されます。
- 共有ビュー: すべてのエージェントまたは特定のグループが利用できます。最初の100個の共有ビューがビューリストに表示されます。
- 個人ビュー: 個々のエージェントが自分のために作成します。最初の10個の個人ビューがリストに表示されます。

ビューの条件の構築
ビューは条件を使用して、どのチケットを表示するかを決定します。次の2つの条件グループがあります。
- 次のすべての条件を満たす: チケットはすべての条件を満たす必要があります
- 次のいずれかの条件を満たす: チケットはいずれか1つの条件を満たすことができます
すべてのビューには、「すべてを満たす」セクションに、次のプロパティの少なくとも1つを含める必要があります。
- ステータス
- ステータスカテゴリ
- タイプ
- グループ
- 担当者
- リクエスタ
マネージャー向けの一般的な条件タイプ:
| 条件 | ユースケース |
|---|---|
| チケット: ステータス | 新規、オープン、保留中、解決済みでフィルター |
| チケット: 優先度 | 高/緊急チケットを表面化 |
| チケット: グループ | 特定のチームにルーティング |
| チケット: 担当者 | 未割り当てまたは特定のエージェントのチケットを検索 |
| チケット: タグ | カスタムカテゴリ化 |
| 作成からの時間 | 古いチケットを検索 |
| 次のSLA違反までの時間 | リスクのあるチケットを特定 |

ビューのフォーマットと整理
条件を設定したら、チケットの表示方法をカスタマイズします。
- 列(れつ): 最大15列を選択します(件名、リクエスタ、優先度など)。
- グループ化(ぐるーぷか): フィールドでチケットを整理します(例:優先度でグループ化)。
- 並べ替え(ならべかえ): グループ内でソートします(例:リクエスト日、昇順で並べ替え)。
プロのヒント: エージェントがより速くスキャンできるように、ビュー名に絵文字を使用します。たとえば、「🔥 緊急チケット」または「⏳ 保留中の顧客の応答」。
拡張可能なZendeskチケットビューの整理戦略
ビュー設計のMECE原則
ZendeskコンサルタントのJude Kriwaldは、MECE原則(Mutually Exclusive, Collectively Exhaustive:相互に排他的、網羅的)を推奨しています。
- 相互に排他的(そうごに はいたてき): 各チケットは、1つの主要な作業ビューにのみ表示される必要があります。同じチケットが「未割り当て」と「新しいチケット」の両方に表示される場合、エージェントは誰が処理すべきかについて混乱します。
- 網羅的(もうらてき): すべてのチケットは、少なくとも1つのビューに表示される必要があります。チケットがどのビュー条件にも一致しない場合、「チケットブラックホール」に入ります。
これが、「未解決のチケットすべて」フェイルセーフビューが不可欠な理由です。MECEビューが正しく機能している場合、すべての作業ビューのチケットの合計は、「未解決のチケットすべて」の数と等しくなるはずです。
組織的アプローチ
ビューの整理方法は、チームの構成によって異なります。
ステータス別(べつ): 最も簡単なアプローチ。新規、オープン、保留中、解決済みのビュー。ボリュームの少ない小規模チームに適しています。
チーム別(べつ): カスタマーサービス、テクニカルサポート、請求のビュー。成長している組織に最適です。新しいチャネルを、エージェントが表示するビュー構造を変更せずに、既存のチームビューに追加できます。
チャネル別(べつ): メール、チャット、ソーシャル、電話のビュー。異なるチームが異なるチャネルを処理する場合に機能します。
ハイブリッド: アプローチを組み合わせます。チームベースのビューと、二重コロン構文を使用したステータスサブビュー(例:「サポート :: オープンチケット」)。
ビューの制限の管理
Zendeskはビューの制限を適用します。
- 最初の100個の共有ビューにアクセス可能
- 最初の10個の個人ビューにアクセス可能
制限に達すると、エージェントに「その他」ドロップダウンが表示されます。重要なビューを表示したままにするには:
- シーズンまたは一時的なビューを非アクティブ化します(削除しないでください)。
- ビューを四半期ごとに監査し、未使用のビューを削除します。
- 命名規則を使用して、関連するビューをグループ化します。
Zendeskチケットビューの一般的な間違いとその回避方法
チケットブラックホール
問題(もんだい): ビューが具体的すぎるため、特定のチケットがどのビュー条件にも一致しません。顧客が苦情を言うまで、視界から消えます。
解決策(かいけつさく): 常に「未解決のチケットすべて」フェイルセーフビューを維持します。毎日確認してください。
ビューの重複(ちょうふく)
問題(もんだい): 同じチケットが複数のビューに表示されます。2人のエージェントが同時に作業を開始したり、エージェントがどのビューから作業するかを決定するのに時間を浪費したりする可能性があります。
解決策(かいけつさく): MECE原則を適用します。チケットが正確に1つの主要なビューにルーティングされるように、条件を確認してください。
パフォーマンスの問題(もんだい)
問題(もんだい): 複雑な条件(複数のテキストフィールドチェック、「NOT」ステートメント、null値チェック)を持つビューの読み込みが遅くなります。
解決策(かいけつさく): Zendeskは以下を避けることを推奨しています。
- 複数のテキストフィールドのチェック
- null値のチェック(例:「担当者が( )」)
- 広範囲に除外する「NOT」ステートメントの使用
代わりに、包括的で具体的な条件を使用します。説明の単語ではなく、タグを確認します。
権限の問題(もんだい)
問題(もんだい): エージェントは不要なビューを表示し、ワークスペースが乱雑になります。
解決策(かいけつさく): ビューを作成するときに、「誰がアクセスできるか」設定を使用します。
- すべてのエージェント
- 特定のグループのエージェント
- 自分のみ(個人ビューの場合)
メンテナンスの負債(ふさい)
問題(もんだい): ビューは時間の経過とともに蓄積されます。完了したプロジェクト、以前のチーム構造、および放棄された実験からの古いビューがリストを乱雑にします。
解決策(かいけつさく): 四半期ごとのビュー監査をスケジュールします。未使用のビューを非アクティブ化します。6か月以上非アクティブなビューを削除します。
自動化とAIによるZendeskチケットビューの強化
ビューはそれ自体で強力ですが、自動化と組み合わせるとさらに効果的になります。
トリガーとマクロ
Zendeskトリガーを使用して、チケットを自動的にタグ付けし、適切なビューにルーティングします。
- トリガーが件名に「払い戻し」を検出します
- トリガーが「refund_request」タグを追加します
- 「払い戻しリクエスト」ビューに、そのタグが付いたチケットが表示されます
マクロは、チケットをビュー間で効率的に移動できます。エージェントがタグを更新するマクロを実行すると、チケットは自動的に次のチームのビューに表示されます。
AIを追加するタイミング
ビューは固定ルールで動作します。構造と一貫性には優れています。しかし、コンテキスト、感情、または意図を理解することはできません。
そこでAIが登場します。eesel AIは、Zendeskチケットビューと連携して、次のことを行います。
- チケットの言語で緊急度を検出し、優先度を自動的に更新します
- 顧客の不満を理解し、すぐに注意を引くようにフラグを立てます
- 手動でタグ付けしなくても、トピック(請求、機能リクエスト、バグレポート)で分類します
- キーワードだけでなく、感情と意図に基づいてルーティングします

重要なのは、AIがビューを置き換えることなく強化することです。ビューは整理された構造を提供します。AIは、適切なチケットがより速く適切なビューに到達するようにします。
今すぐZendeskチケットビューの最適化を開始してください
このガイドを読んだ後、1つだけ行うことがあるとすれば、「未解決のチケットすべて」フェイルセーフビューを設定してください。これは、チケットブラックホールに対する保険です。
次に、MECE原則に照らして現在のビューを監査します。チケットが不必要に複数のビューに表示されていますか?どのビューにも表示されないチケットはありますか?
チームが成長するにつれて、自動化が手動によるビュー管理をどのように削減できるかを検討してください。トリガーはルーチンルーティングを処理できます。また、トリアージプロセスにインテリジェンスを追加する準備ができている場合は、eesel AIが数分でZendeskと統合し、チケットの内容を分析して感情、緊急度、意図で分類します。
適切に設計されたビューは、チケットの混乱を整理されたワークフローに変えます。エージェントは、何に取り組むべきかを知っています。あなたは、チームが何を処理しているかを知っています。そして、何も抜け落ちることはありません。
よくある質問
この記事を共有

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.



