チケットトリアージは、チケットがコンテキストなしで届くから存在する

チケットトリアージは、必要不可欠なサポートワークフローのように見えます。リクエストが届き、誰かがそれを読み、分類し、優先度を設定し、キューに割り当て、エスカレーションが必要かどうかを判断します。そして作業が始まる前に、別の担当者がもう一度それを読みます。

チームはトリアージを効率の問題として扱いがちです。ルーティングルール、キュー、タグ、ダッシュボード、AIチケットトリアージツールを追加して、届いた作業をより速く仕分けしようとします。しかし、仕分けを速くしても根本的な問題は解決しません。それは単に、同じ手作業による解釈をより高速に行えるようにするだけです。

より深い問題は、コンテキストの欠如です。チケットは切り離されたメッセージとして届く一方で、それらを解決するために必要な情報は、顧客レコード、製品データ、インシデント履歴、ドキュメント、会話、社内システムにまたがって存在しています。チケットトリアージは、そのコンテキストを再構築するために必要な人的労働になってしまうのです。

AIがどのように証拠を収集し、承認されたプロセスに従い、安全なアクションを実行してサポートトリアージを改善するのかをご覧ください。

そもそもなぜチケットトリアージは存在するのか？

チケットトリアージが存在するのは、ほとんどのサポートシステムが、リクエストと、それを理解するために必要な情報とを切り離しているからです。

顧客が支払いに失敗したと報告するとします。そのチケットには、短い一文とアカウントのメールアドレスしか含まれていないかもしれません。この問題を理解するために、サポートスペシャリストは、顧客のプラン、最近の支払い試行、アカウントステータス、製品の利用状況、過去の会話、未解決のインシデント、関連するトラブルシューティングガイダンスを確認する必要があるかもしれません。

そうした調査は、多くの場合、そのチケットがどこに属するのかを誰かが判断できるようになる前に行われます。

目に見えるワークフローは単純に見えます。

1. リクエストを読む。
2. 問題の種類を特定する。
3. 緊急度と顧客への影響を評価する。
4. サービスレベルアグリーメントを確認する。
5. 優先度を割り当てる。
6. チケットをルーティングする。
7. 不足しているコンテキストを追加する。
8. 必要に応じてエスカレーションする。

隠れたワークフローは、はるかに大きなものです。

1. 顧客レコードを見つける。
2. リクエスト元がアカウントと一致することを確認する。
3. 過去のやり取りを検索する。
4. その問題が新規のものか、再発しているものかを判断する。
5. 関連するインシデントを探す。
6. 影響を受けている製品または機能を特定する。
7. 関連するポリシーまたは記事を見つける。
8. 別のチームがどのような情報を必要とするかを判断する。

この隠れた作業は、理解のための労働です。これは、あいまいなメッセージを実行可能なケースに変えるために必要な労力です。

多くの組織は、この活動をサポートトリアージやヘルプデスクトリアージと呼びます。このラベルは、それを安定した運用上の段階のように聞こえさせます。しかし実際には、それは顧客のリクエストとチームのシステムとの間の、コンテキスト再構築のギャップを表していることが多いのです。

なぜルーティングルールではこの作業を取り除けないのか？

ルーティングルールはパターンを識別できます。ルールは、返金を含むチケットを請求部門に送ったり、特定のドメインからのメッセージを戦略的アカウント用のキューにルーティングしたりできます。

それは予測可能なカテゴリには役立ちます。しかし、あいまいなリクエスト、複数システムにまたがる問題、あるいは優先度が顧客履歴に依存するケースは解決できません。

ルールは、チケットに「outage（障害）」という単語が含まれていることは認識できます。しかし、その顧客が現在のインシデントの影響を受けているのか、そのインシデントがすでに対処されているのか、その顧客に契約上のエスカレーション経路があるのか、あるいはそのメッセージが別個の製品不具合について述べているのかは分からないかもしれません。

ルールはまた、時間の経過とともに増殖します。チームは新しい製品、地域、顧客ティア、言語、チャネル、エスカレーション経路のために例外を追加していきます。やがて、ルーティングシステムの保守そのものが、独立した運用業務になってしまいます。

その結果は、必ずしもインテリジェントなチケット自動化とは限りません。それは手作業による仕分けの、より高速なバージョンにすぎないかもしれません。

コンテキストの欠如はサポートチームにどのような影響を与えるのか？

コンテキストの欠如は、いくつかの形の無駄を生み出します。

• キューの遅延：チケットは、それを分類する権限やナレッジベースを持つ担当者を待つことになります。
• 重複した読み込み：トリアージスペシャリストが最初にチケットを読みます。割り当てられたエージェントがもう一度読みます。エスカレーション後には、エンジニアやアカウントマネージャーが3度目に読むこともあります。
• 避けられるやり取りの往復：割り当てられたチームが、すでに別のシステムに存在する情報や、顧客がすでに他の場所で提供した情報を求めます。
• 一貫性のない優先度付け：2人の担当者が顧客履歴の異なる部分を見ているために、異なる緊急度を割り当てることがあります。
• 認知的な切り替え：サポートスペシャリストは、顧客の問題を解決するために時間を費やすのではなく、アプリケーションの間を行き来することになります。

組織は、こうした問題をトリアージ担当者の増員によって解決しようとすることがよくあります。それは一時的にスループットを高められるかもしれませんが、コンテキストのギャップは取り除けません。チケット量が増えるにつれて、組織は同じ情報を再構築するためにさらに多くの人員を追加することになります。

重要なポイント： チケットトリアージは、ワークフローの一段階に見せかけた理解のための労働であることが多いのです。根本的な問題は、仕分けが遅いことではありません。解決に必要なコンテキストを伴わずにチケットが届くことなのです。

もしチケットがコンテキストとともに届いたら？

サポートリクエストが、関連する顧客・製品・ワークフローの情報をすでに添付した状態で届く様子を想像してみてください。

割り当てられたチームは、顧客のプラン、最近のアクティビティ、影響を受けている機能、関連するインシデント、過去の解決策、適用されるポリシー、推奨される次のアクションを見ることができます。チケットには依然として判断が必要な場合もありますが、チームは真っ白な画面から始める必要はなくなります。

これがコンテキスト・アット・アライバル（到着時点でのコンテキスト）です。

コンテキスト・アット・アライバルは、あらゆるチケットにあらゆるデータポイントを添付することを意味するわけではありません。過剰な情報は、かえって作業を難しくすることがあります。目的は、リクエストを説明し、次のアクションを裏付ける証拠を提供することです。

• 支払いの問題については、最近の取引ステータス、アカウントの適格性、過去の支払い失敗、関連する請求ポリシーなどが含まれるでしょう。
• 製品バグについては、影響を受けているワークスペース、バージョン、最近のエラーイベント、関連するレポート、既知のインシデント、対応するエンジニアリングの課題（issue）などが含まれるでしょう。
• アクセスリクエストについては、リクエスト元の役割、組織、承認ポリシー、現在の権限、適切なワークフローなどが含まれるでしょう。

この違いは重要です。従来のチケットトリアージは「これはどこに送るべきか？」と問います。コンテキスト・アット・アライバルは「これは今すぐ解決できるか、できないとしたらどのような判断が具体的に必要か？」と問います。

コンテキスト・アット・アライバルはチケットトリアージをどう変えるのか？

システムがリクエストを、関連するアカウント、製品、ポリシー、インシデントのコンテキストと結び付けられるようになると、チケットトリアージは独立した仕分けの段階という性格が薄れます。分類、優先度付け、ルーティング、エスカレーションは、解決プロセスから導かれる、十分な情報に基づくアウトプットになります。

• 分類は、メッセージだけを見て誰かが貼るラベルではなく、証拠に基づく判断になります。
• 優先度付けは、キーワードだけに頼るのではなく、顧客への影響、緊急度、契約上のコミットメント、ポリシーを考慮できます。
• ルーティングは、関連するコンテキストをすでに添付した状態で、次のアクションを取るのに最も適したチームまたはワークフローにリクエストを送れます。
• エスカレーションには、調査内容、証拠、推奨される次のステップ、そして人が関与すべき理由を含めることができます。

チケットは、運用上の可視性のために依然としてキューを通過するかもしれません。しかし、キューはもはや理解が始まる場所ではありません。すでに理解された作業をモニタリングする場になるのです。

このモデルは、システムが重要な少数の事実、すなわちアカウント、製品領域、未解決のインシデント、適用されるポリシー、過去の履歴を、担当者に手作業で組み立てさせることなく、確実に取得し結び付けられる場合にのみ機能します。

それには、優れた分類器（クラシファイア）以上のものが必要です。システムは、周辺データの量が増えても、チケットを関連する顧客、製品領域、関連するエンジニアリング作業、ポリシー、過去の履歴に結び付けなければなりません。

DevRevのEnterprise-Benchは、チケットと課題（issue）の相関付けやSLA分析を含め、この種のクロスシステムのサポート作業を本番相当のスケールで評価します。その中心的な発見は、信頼できる成果が、背後にあるモデルだけでなく、エージェントがエンタープライズデータにどのようにアクセスし、それらをどう結び付けるかに大きく依存する、ということです。

DevRevは、Computer対Claudeで、実際のビジネスクエリを実行しました。それは4項目にわたるリレーショナルな質問でした。すなわち、「同じ製品領域で未解決のサポートチケットを持つ顧客アカウントに影響を与えている、未解決かつ優先度の高いエンジニアリングの課題（issue）はどれか？」というものです。ComputerとClaudeは、同じ基盤となるJiraおよびSalesforceのデータをもとに、7回のランで作業しました。

• Claudeが使用したもの：1ランあたり約320万トークン、約8分50秒。
• DevRevによるComputerが使用したもの：1ランあたり約157,000トークン、約1分36秒。
• これは95%少ないトークンで、5.5倍高速であり、しかも一度きりではなく、毎回一貫してそうなのです。

その効率がどのようにビジネスケースに結び付くかについては、AI ROIをご覧ください。

これは実際にはどのように見えるのか？

プラン変更後に機能が動作しなくなったと報告する顧客を考えてみましょう。

従来のワークフローは、次のようになるかもしれません。

1. チケットが一般サポートキューに入る。
2. スペシャリストが製品領域を特定する。
3. スペシャリストが顧客のプランを確認する。
4. スペシャリストが最近の変更を検索する。
5. スペシャリストがその挙動が想定通りかどうかを確認する。
6. スペシャリストがそのケースを請求、サポート、またはエンジニアリングにルーティングする。
7. 割り当てられた担当者が調査の一部を繰り返す。

コンテキスト・アット・アライバルのワークフローは、これと異なる形になり得ます。

1. リクエストがアカウントおよび製品のコンテキストに結び付けられる。
2. システムがプラン変更と影響を受けた機能を特定する。
3. ポリシー、最近のイベント、既知の問題を確認する。
4. その変更が挙動を説明するかどうかを判断する。
5. リクエストを解決するか、証拠とともにエスカレーションする。
6. 担当者は、生のメッセージではなく、判断できる状態のケースを受け取る。

2つ目のワークフローでも、依然として担当者が必要になる場合があります。担当者は、判断が重要になる時点で関与するだけです。

これは初回解決（ファーストコンタクトでの解決）にとって何を意味するのか？

初回解決は、リクエストを処理する最初の担当者またはシステムが、行動を起こすのに十分な情報を持っているときに向上します。

コンテキストの欠如は、初回対応を情報収集の段階にせざるを得なくします。顧客が問題を説明し、サポートスペシャリストが追加の質問をし、そのケースはいくつものキューを通過していきます。

コンテキスト・アット・アライバルは、その遅延を減らすことができます。システムは、最初の人間とのやり取りの前に、関連する顧客履歴を特定し、推奨されるアクションを提示できるかもしれません。

それは初回解決を保証するものではありません。問題によっては、調査、承認、エンジニアリング作業、あるいは顧客の確認が必要です。しかし、組織が共通の理解を欠いているという理由だけで遅延するケースの数を減らすことはできます。

AIチケット処理を評価するチームにとって、これは有用な区別です。そのプラットフォームが解決の成功を測定しているのか、それとも正確な分類だけを測定しているのかを問いましょう。ルーティング後に必要となる作業を減らすのかどうかを問いましょう。最初に割り当てられた担当者が、完全なケースを受け取るのか、それとも別の調査タスクを受け取るのかを問いましょう。

AIはどこで止まり、どこから人間が引き継ぐべきか？

AIチケットトリアージは、あらゆるサポートの意思決定から人を排除すべきではありません。人にしかできない意思決定を遅らせている、反復的な調査やルーティング作業を取り除くべきなのです。

有用なルールはシンプルです。リクエストが十分に理解され、アクションが承認済みで、結果が可逆的である場合は自動化する。状況が高リスク、あいまい、または裁量を要する場合は人を関与させる。これは、判断を要する意思決定について人に説明責任を持たせ続ける、ヒューマン・イン・ザ・ループのモデルです。

高リスクの意思決定については人に説明責任を持たせ続ける

リクエストの中には、財務、セキュリティ、法務、または関係性に関わる結果を伴うものがあります。AIは関連するコンテキストを収集し、次のステップを推奨できますが、意思決定については人が説明責任を持ち続けるべきです。

これには一般的に次のものが含まれます。

• 財務上のアクション： 返金、クレジット、支払い変更、または請求ポリシーの例外。
• セキュリティおよびプライバシーのリクエスト： アカウント復旧、本人確認、アクセス変更、またはデータ漏洩の疑い。
• 契約上のコミットメント： サービスレベルアグリーメント、商業条件、または戦略的顧客へのコミットメントに関わるリクエスト。
• 規制または法務に関わる事項： 法的解釈、コンプライアンスレビュー、または承認された開示を必要とするリクエスト。
• 顧客リスクの局面： 重大インシデント、エグゼクティブによるエスカレーション、チャーンの兆候、または共感と関係性の判断を要する会話。

証拠が不完全、または矛盾する場合はエスカレーションする

AIはまた、信頼できる答えを確立できない場合には作業を人に引き渡すべきです。これには、矛盾する顧客レコード、不完全なリクエスト、意図が不明確なもの、新規の製品挙動、あるいは既知の解決策がない潜在的な不具合が含まれます。

この引き継ぎは、調査をやり直すべきではありません。システムが何を発見したか、何を確認できなかったか、関連するポリシーやインシデントのコンテキスト、そして依然として人の判断を要する意思決定を説明すべきです。

これがコンテキスト・アット・アライバルの役割です。あらゆるチケットを自動化することではなく、専門知識が最も重要になるときに、判断できる状態のケースを人に提供することです。

チケットトリアージが消えた後には何が起きるのか？

不要なチケットトリアージが消えると、サポートキューの意味が変わります。

それはもはや、誰かが解釈するのを待っている未読リクエストの集まりを表すものではなくなります。それは、すでに解決済み、進行中、承認待ち、またはコンテキストとともにエスカレーションされた作業のビューになります。

これは、いくつかの改善の可能性を生み出します。

• 顧客は、社内での割り当てを待つことなく回答を受け取る。
• サポートスペシャリストは、システムをまたいで検索する時間が減る。
• エンジニアは、より優れたエスカレーションパッケージを受け取る。
• マネージャーは、生の作業量ではなく例外を見る。
• ナレッジのギャップを特定しやすくなる。
• 繰り返される問題を製品側の作業に結び付けられる。
• サービスレベルのレポーティングが、キューの移動ではなく解決の進捗を反映する。

同じ原則がエンタープライズサーチにも当てはまります。従業員が質問をしたとき、システムはその質問を一連のキューに通すのではなく、答えを見つけたりタスクを実行したりする手助けをすべきです。顧客が助けを求めたとき、システムは割り当てを進捗とみなす前に、まず解決を試みるべきです。

Computerは、このより広範な運用モデルのために設計されています。組織のコンテキストを、検索・サポート・製品・ワークフローのアクションと結び付けつつ、判断が重要になるところでは人を関与させ続けることができます。

重要なポイント： トリアージが消えると、キューはすべてのリクエストが始まる場所ではなく、例外と可視性のレイヤーになります。作業は、届いたメッセージを仕分けることから、理解されたリクエストを解決することへとシフトします。

チームはどのようにチケットトリアージの排除を始められるのか？

現在のワークフローが反復的で、コンテキストを多く要し、測定可能なカテゴリを一つ選んで始めましょう。

チケットの到着から解決まで、担当者が現在何をしているかを文書化しましょう。開くタブ、確認するレコード、投げかける質問、適用するポリシー、そしてエスカレーションする理由を含めます。

次に、どの部分が判断を要し、どの部分が反復的な情報作業なのかを特定します。

反復的な情報作業は、解決スキル（resolution skill）にとって最初の機会です。解決スキルは、Co-pilotではなくガバナンスされたエージェントです。単に提案するだけでなく、委任された権限の範囲内で行動します（その境界がどこにあるかについては、AI Co-pilot対AIエージェントをご覧ください）。

このスキルは、関連するコンテキストへのアクセス、明確な境界、安全なアクション、そして明示的なエスカレーション経路を備えているべきです。そして、人がレビューできる証拠を生成すべきです。

チームはこれらのスキルをAgent Studioで定義します。デプロイの前に、指示、ツール、境界、エスカレーションルールを設定します。

テストには実際の過去のチケットを使いましょう。定型的なケース、不完全なリクエスト、エッジケース、矛盾するレコード、そして自動化すべきでないリクエストを含めます。

速度だけでなく、それ以上のものを測定しましょう。Forbesの報道によると、調査対象者の58.3%が、企業のサポートチームに連絡した後に何の返答も受け取っていませんでした。システムが適切なケースを解決し、適切なケースをエスカレーションし、繰り返しの読み込みを減らし、人により良い情報を提供しているかどうかを追跡しましょう。

結果が信頼できるものであれば、段階的に拡大しましょう。最初のスキルが安定した運用パターンを確立したときにのみ、隣接するワークフローを追加します。

Computer は、コンテキストをアクションに結び付けることで、この導入の道筋を支援できます。

デモを予約して、解決スキルが手作業の仕分けを置き換えられるチケットワークフローについてご相談ください。