AIチケットスウォーミング：その概念とAIが実際に役立つ場面

チケットスウォーミングとは何ですか？

チケットスウォーミング（ケーススウォーミング、サポートスウォーミング、または協働サポートモデルとも呼ばれます）は、チケットを段階的にエスカレートする代わりに、複数の人がそれに協力して取り組むアプローチです。1人が責任を持ち、必要な専門家を招集します。チケットを引き渡して立ち去るのではありません。

正式なバージョンは、Knowledge-Centered Service（KCS）を生み出した同じ団体であるConsortium for Service Innovationから来ています。彼らは「Intelligent Swarming」という言葉を生み出し、それを「リソースを作業に合わせるためのよりスマートな方法…サポートの段階を取り除き、適切な場合には『スウォーム』のアナリストの集合的な専門知識を活用すること」と定義しています。Zendesk は顧客サポートに関して同じアイデアを「複雑な顧客の問題を解決するために、エスカレーションではなくコラボレーションを活用する顧客サービスチームのアプローチ」として説明しています。

BMCのJon Stevens-Hallがコアな原則を説明するように、スウォーミングは段階的サポートの正反対です：

• 段階的なサポートグループは存在しない。
• グループ間のエスカレーションは存在しない。
• ケースはそれを解決する可能性が最も高い人に直接届く。
• ケースを引き受けた人が解決まで責任を持つ（他の人を呼び込む間も所有権を保持する）。

このアイデアは新しいものではありません。大きな先駆者はCiscoで、2008年のホワイトペーパーで「Digital Swarming」モデルを発表しました。その後、ConsortiumがIntelligent Swarmingとして発展させ、HDIはCisco、BMC、Red Hat、Allscriptsを劇的な改善を報告した初期の採用者として挙げています。新しいのは前に付く「AI」であり、それが数学を変える方法については後で触れます。

スウォーミング vs. 段階的サポート

段階は悪くありません。作業に合えば、良いフィルターです。Consortiumも、段階的サポートはほとんどの問題が単純で既知の場合（95%以上）、最初の接触で解決され、各レベルが受け取ったものの70〜80%を解決するときに機能すると述べています。問題はその混合が変化し始めるときです。

2つのモデルの実際の違いはこうです：

（Consortiumの「How Does It Work」とZendesk のケーススウォーミングガイドを参考に作成。）

Consortiumには違いを説明する素晴らしいメタファーがあります：段階的サポートは「インシデントルーティング、再ルーティング、エスカレーション、拒否によって問題をやり取りする複数のチーム（卓球をする）」を意味し、スウォーミングはそれを「コラボレーションする一つのチーム（キャッチボールをする）」に凝縮します。Zendesk の実践的な言葉：「段階的サポートは繰り返し発生する問題に最適…ケーススウォーミングは異なるスキルが必要なより複雑な問題に理想的。」どのチケットがどちらに向かうかという決定は、根本的にチケットトリアージの問題です。

なぜ突然みんな「AIチケットスウォーミング」と言い始めたのか

これが全てをつなぐ部分です。スウォーミングの元々の議論は人口統計的なものでした：顧客がセルフサービスで既知の問題をより多く解決するにつれて、人間に届くチケットはより難しくなります。これは現代のすべてのAIヘルプデスクの背後にある同じ論理です。Consortiumは「一部の企業の顧客は現在、問題の80%をセルフサービスで解決している」と指摘しており、キューに残るものは新しく、複雑で、エスカレーションしやすいものが不均衡に多く、まさに段階的サポートが崩壊するところです。

AIはその変化を強力に加速させます。AIエージェントと優れたセルフサービスが繰り返し可能なボリュームを吸収すると、人間に残るものはさらに本当に難しいケースに偏ります。したがって、「AIチケットスウォーミング」は本当にAIがSlackのハドルに参加することではありません。2つの異なる仕事です：

1. AIが95%をクリアする： 既知の繰り返しチケットを、チケット自動化と分類によって処理し、スウォームが必要にならないようにする。
2. AIが5%を支援する： 実際のスウォームが発動したとき、コンテキスト収集、ナレッジベースの検索、返信の下書きを行い、人間が狩りではなく考えることに時間を使えるようにする。

5%という数字は私のものではありません。見た中で最も的確な表現は、Redditのr/salesforceにいたSalesforceプラクティショナーから来ました。スウォーミングの意味を理解していない人に反論していました：

「スウォーミングの主な問題提起は次のとおりです：症例の5%が、複雑さ、関与する多くのチームなどにより、解決するための全体的な労力の30%…を占めます…スウォーミングはボリュームゲームではありません。正しく解決するのに多くの時間を要する非常に小さな割合のケースに取り組みます。」

u/nebben123, r/salesforce

それがゲームの全てです。AIを間違ったスライスに向ければ（すべてでスウォームしようとするか、ボリュームを処理しようとする人間のスウォームを使おうとするか）、両方の最悪の結果が得られます。分割を正しくすれば、モデルはついに設計通りに機能します。

AIがスウォーム内で実際に役立つ場所

では、具体的にAIがこの中で何をするのでしょうか？私が一緒に働くチームでは、うまくいっているパターンはこうです：AIはキューの先頭に最初の対応者として座り、信頼度チェックが次に何が起こるかを決定します。

AIが自信を持っているとき、チケットを解決するか、エージェントが送る返信を下書きします。自信がないとき、推測しません；人間のためにチケットを静かに残しますが、空手ではありません：チケットにタグを付けてルーティングし、関連する過去のチケットとドキュメントを引き出し、内部ノートとして提案された返信を残します。引き受けた人間はコンテキストの中に入り、ゼロからのスタートではありません。

その信頼度ゲートは最も重要な設計上の決定であり、バイヤーが最も気にするものです。私はかつて毎月7,000件のチケットを処理するブランドのCXリードとの電話にいて、彼女はどんな製品ブリーフよりもうまく要件を表現しました。彼女の言葉はおおよそ：「AIは質問の100%を答えられることは決してないでしょう…自信を持って対処できるチケットだけを扱い、それ以外はすべて、そのままにしておくAIが必要です。」

それがeeselが構築されている原則です。信頼度の閾値を設定し、自動化する準備ができていないチケットタイプを除外し、AIは不確かなものすべてを静かに引き渡します。そして自信満々に聞こえるボットが間違った回答をするのを見てきたので、すべてのロールアウトは過去のチケットに対してシミュレーションされます。これにより、本番環境で発見するのではなく、何かが稼働する前にチケットタイプ別のカバレッジとエラー率を確認できます。ライブトラフィックでの実際のトライアルでは、シミュレーションファーストのアプローチにより、チームが自動返信に切り替える前にトリアージ精度93%とスパム検出率100%が得られました。これは自動化を信頼する前に必要なサポートチケット分析の種類です。

プラクティショナーがすでに想像している未来志向のバージョンもあります。あるITリーダーがLinkedInに書いたように：

「AIと機械学習によって動く『インテリジェントスウォーム』を想像してください。問題を予測し、解決策を提案し、一部の修復タスクを自動化さえします。」

Ajit Dsouza, LinkedIn

スウォーミングのAIが解決しない部分

さて、正直な部分です。これはほとんどのベンダーの投稿が静かになるところです。スウォーミングには実際の、文書化された失敗のモードがあり、AIはいくつかを修正しますが、他は完全に手つかずのままにします。これをやるなら、目を開けて入ってください。

「伝言ゲーム」の引き渡し。 担当者が伝えている問題を実際に理解していないと、スウォーミングは伝言ゲームに劣化する可能性があります。Redditのシスアドミンは、エンドユーザーとしてそれを経験することを説明しました：

「最初の技術者がスクリプトを終えて、より技術的なチームからのサポートを引き込み始めると、24時間のターンアラウンドで伝言ゲームになりました…彼らに説明しようとすると、L1の技術者を通じて行わなければならず、私たちの説明は彼の理解を通してフィルタリングされます。」

u/beritknight, r/sysadmin

AIは本当にここで役立ちます。チケットの全コンテキストを1か所に取得することで、専門家がパラフレーズのパラフレーズではなく元の詳細を読むことができます。

招待の拒否。 これはAIだけでは解決できません。あるオペレーターがLinkedInで述べたように、「Intelligent Swarmingの背後にある理論は完璧です…[しかし]実際には、重大な摩擦点が見られます：『招待の拒否』問題です。専門家をSlackスウォームに招待するとき、彼らに自分のフォーカスを断ち切って他の人のパズルを解くよう求めています。」専門家が純粋に自分のチケットを閉じることで測定されているなら、AIはスウォームに参加したいと思わせることはできません。それはメトリクスとインセンティブの問題です。

調整コスト。 Consortiumは「コラボレーションは時間がかかる。なぜなら協力者間でより多くのやり取り…が必要だから」と明確に述べており、それがすべてのチケットがスウォームされるべきではない理由です。AIはスウォームを必要とするチケットの数を減らしますが、発動したスウォームはまだ実際の人間の時間を費やします。

所有権がゲームになる。 「チームが解決する」が「引き受けた技術者が解決する」になると、人々は適応します。あるシスアドミンは、ユーザーがシステムをゲームし始めると警告し、チケットツールを迂回して特定の技術者を要求しようとし、静かにルーティングとメトリクスを台無しにします。これはAIが支援できる（一貫したルーティングとタグ付けで）プロセス設計の問題ですが、単独では解決できません。

正直なまとめ：AIはボリュームとコンテキストの問題への素晴らしい答えであり、文化とインセンティブの問題への答えではまったくありません。「AIチケットスウォーミング」を2番目のカテゴリの修正として売っている人は誇張しています。

AIチケットスウォーミングを実際に機能させる方法

混乱なくこれを実践したいなら、私が従うシーケンスはこうです：

1. スウォームを狭く絞る。 どのチケットタイプがコラボレーションを正当化するほど本当に複雑かを決定し、保護します。それ以外はすべて自動化またはセルフサービスに向かうべきで、ハドルではありません。
2. まずAIに既知のボリュームをクリアさせる。 AIヘルプデスクエージェントを既存のチケットシステムに接続し、繰り返しチケットを処理させます。キューに簡単なチケットが少ないほど、困難なものに対するチームの注意がより自由になります。
3. すべてを信頼度でゲーティングする。 AIが自信があるときだけ自動返信し、残りを静かにルーティングするように閾値を設定します。これが助けるAIと静かに新しい問題を作るAIの違いです。
4. AIをスウォームのメモ係にする。 人間が呼ばれる前に、AIはすでにコンテキストを収集し、関連するドキュメントを表示し、内部ノートとして出発点を下書きしているべきです。
5. リリース前にシミュレーションする。 まずすべてを過去数千枚のチケットに対して実行し、チケットタイプ別のカバレッジと精度を知ります。推測することが、誰もが恐れる自信満々だが間違っているボットを生む方法です。
6. インセンティブは自分で直す。 専門家がスウォームの手伝いに対して認められていることを確認します。自分のキューを閉じることだけでなく。ツールはこれをやってくれません。

このほとんどは、分割を正しく行うことについてです。各チケットがどちらの方向に流れるべきかを決定し、その線の両側でAIが安全にできる限り多くの負荷を担わせます。

AIチケットスウォーミングにeeselを試す

上記のモデルが正しいと思えるなら、eesel AIはスウォームの常時稼働する最初のメンバーとして構築されています。既存のヘルプデスク（Zendesk、Freshdesk、Gorgias、HubSpot、Frontなど）に接続し、初日から過去のチケットとヘルプドキュメントから学習し、既知のチケットを解決または下書きして、チームの注意が本当に人間を必要とする複雑なものに向けられるようにします。

スウォーミングに特化した差別化要因はシミュレーションファーストのロールアウトです：AIを数千の過去のチケットに対して実行し、安全に処理できるタイプと引き渡すべき場所を正確に確認し、ライブカスタマーに触れる前に信頼度の閾値を設定します。あるチーム、Gridwiseは、最初の月にeeselがTier-1リクエストの73%を解決したのを確認しました。7日間のトライアル中に現れた結果です。価格は使用量ベースでユーザーごとの料金なしです。解放しようとしている人員に対して支払うことはありません。

クレジットカード不要で無料で試せ、シミュレーションは自社のデータで実行されるため、コミットする前に自分で分割を確認できます。