はい、AIはティア2サポートに役立ちます。ただし、少し賢くなったFAQボットとしてではありません。ティア2で役立つAIは回答者ではなく調査役です。注文、請求、アカウントの照会を実行し、チームが同じ問題を解決した過去のチケットを見つけ、明らかな原因を除外し、そのすべてを社内メモに残します。担当者は、生のチケットではなくケースファイルを開くことになります。
大きな効果は、たいていもっと上流にあります。ティア2のキューには3種類のチケットがあります。そもそもエスカレーションすべきでなかったもの(AIがティア1で回答します)、答えが別のシステムにあるだけで難しそうに見える照会の多いもの(AIが調査し、人が判断します)、そして本当に新しい問題(人が主導し、AIがメモを書きます)です。ネイティブのツールは一部を助けてくれます。Zendesk Copilotは類似チケット、担当者の提案、auto assistアクションを1エージェントあたり月額$50で追加し、Freddy AI Copilotは類似チケットとそれを解決したエージェントを1エージェントあたり月額$29で表示します。
eeselのようなAIチームメイトは、すでに使っているヘルプデスクの中で調査を行います。ITアドミンからの証明書、Outlookアドイン、メールフローの問題がチケットの中心であるTimengoでは、月に約300件のFreshdeskチケットを準備し、5,300件の過去チケットと製品ドキュメントをもとに、デンマーク語の下書きとエンジニア向けメモを作成しています。プランは500クレジットで月額$299から。1チケットは、照会が何回必要でも1クレジットです。
AIはティア1だけでなく、ティア2サポートにも本当に役立ちますか?
役立ちます。ただし、ティア1の仕事を難しいチケットにも求めるのをやめることが条件です。ティア1のAIは主に検索役で、質問に合うヘルプ記事やマクロを見つけて送信します。ティア2は別の種類の仕事です。注文が支払い済みなのに出荷されていない理由、他の全員は使えているのに特定の顧客のSSOログインだけが失敗する理由、火曜日に連携の同期が止まった理由を、誰かが突き止めなければなりません。これは調査です。そして調査の時間の大半は、考えることよりも証拠集めに使われます。
私はeeselで連携機能、つまりAIエージェントがShopifyの注文を開いたり、Stripeのサブスクリプションを読んだり、顧客自身のAPIを呼び出したりするための部分を作っています。どの導入でも同じ光景を目にします。ティア2の担当者がチケットに取り組む様子を見ていると、最初の10分から15分はタブを開くことに費やされています。注文システム、請求ツール、管理画面、そして「これを前に見た人はいるか」という検索です。最後の判断には1分ほどしかかかりません。AIはタブを開く作業を得意とし、それはシニアのメンバーが最もやるべきでない部分でもあります。
つまり、正直な答えは3つに分かれます。ティア2のキューにある3種類のチケットごとに1つずつです。
- そもそもエスカレーションすべきでなかったチケット。 ティア1のエージェントやボットが、ナレッジベースが薄かったから、あるいは回答にティア1ができない照会が必要だったためにエスカレーションしたものです。より良いナレッジと、注文やアカウントのシステムへの読み取りアクセスを持つAIならティア1で回答でき、専門担当者には届きません。
- 照会の多いチケット。 解決策は分かっていても、見つけるのに2〜3のシステムのデータが必要なものです。AIが照会と先例の検索を行い、返信を下書きし、人が事実を確認して送信します。
- 本当に新しい問題。 誰も見たことのないバグや、顧客の環境特有のエッジケースです。人が主導し、場合によっては他の専門担当者とチケットを集団で対応します。それでもAIは、試したことの要約、証拠の添付、解決後の修正内容の記録によって役割を果たし、次回は2番目のカテゴリのチケットになります。
なぜティア2のキューはこんなにいっぱいなのですか?
上流のあらゆる穴が行き着く先がエスカレーションだからです。ティア1が請求システムを見られなければ、「二重に請求されたのはなぜ?」という問い合わせはすべてティア2のチケットになります。支払い紛争が多くのティア2キューを詰まらせるのはそのためです。新機能がまだナレッジベースにカバーされていなければ、それに関する質問もすべて1段上がります。これらは本来ティア2の仕事ではないのに、結局ティア2がこなしています。
2つ目の原因は、2〜3人の頭の中にある知識です。Freshdeskを使う公共セクターのIDサービス企業のサポートリーダーは、月に約3,000件の複雑なERPトラブルシューティングを扱っており、その年にシニアエージェント2人を失う予定なので、2人が退職する前に彼らの知識を記録したいと話してくれました。ティア2の問題をよく表しています。答えは存在していますが、何年分もの解決済みチケットと数人の記憶に散らばっていて、誰も素早く見つけられません。
同じ会社は、20分以上かかりそうなチケットをAIにフラグ付けさせ、標準のサポートとは別にルーティングしたいと考えていました。その直感は正しいと思います。ティア2の1週間を食いつぶしてチケットの滞留を生むのは、最も難しいチケットであることはまれで、たいていは答えがすでにあり、そこにたどり着くのに20分の掘り下げが必要なだけです。
サポート担当者がエスカレーションについて語るとき、この両方の原因が聞こえてきます。ティア1に他の行き先がなければ、すべてが上に上がります。
"We tried something like that, and almost everything outside of a password reset was escalated... I'm the only "tier 2" person, the other one they call "Tier 2" would often times just pass things on to me..."
そして、メモのないチケットが届けば、ティア2は誰かがすでにやった作業を繰り返すことになります。このITマネージャーのルールは、多くのチームが文書化しながら、実際に徹底しているところは少ないものです。
"As a rule, any ticket that is escalated must have complete notes on every troubleshooting step you've already tried so the next team doesn't repeat processes."
正直なところ、このルールはそのままティア2のAIの仕様書として機能します。すべての手順を完全にメモするのは人にとっては面倒ですが、すでにスレッドを読み照会を実行したソフトウェアにとってはほぼコストゼロです。
懐疑派の主張にも一理あり、何かを購入する前に真剣に受け止めるべきだと思います。
"Tier-2/3 support isn't just about picking an answer from a knowledge base; it requires deduction, empathy, and finding solutions that don't exist yet."
前半には同意します。ナレッジベースから答えを選ぶだけのAIはティア2には向きません。後半では区分が重要になります。「まだ存在しない解決策」は3種類目のチケットのことで、ほとんどのティア2キューでは少数派だからです。残りのチケットでは、解決策はすでにどこかに存在し、過去のチケットや請求記録に埋もれています。
ティア2のAIは、ティア1とどう違いますか?
ティア1では、AIの仕事は答えることです。ティア2では、AIの仕事は確信のある答えに至る道のりを短縮することであり、多くの場合その答えを出すのは依然として人です。スキルは大きく重なります。変わるのは、何を測定するか、そして何に触れさせるかです。
| ティア1のAI | ティア2のAI | |
|---|---|---|
| 主な仕事 | 既知の質問に答える | 証拠を集め、先例を探す |
| 参照元 | ヘルプセンター、マクロ、ポリシー | 過去の解決済みチケット、注文・請求・アカウントのシステム、社内ドキュメント、ランブック |
| 典型的な出力 | 公開の返信 | 社内メモ、返信の下書き、ルーティングの判断 |
| アクション | 主に読み取り専用の照会 | まず読み取りの照会、書き込みアクションは承認の後ろ |
| 誰が送信するか | 多くの場合AI | 通常は人、最初は常に人 |
| 成功指標 | 解決率または問い合わせ削減率 | 最初の有用な発見までの時間、ティア2の処理時間、エスカレーションの減少 |
| 止まるべきとき | 答えが見つからないとき | 証拠が見つからない、または修正が金銭やデータを変更するとき |
「参照元」の行は見落とされがちです。ヘルプセンターだけで学習したティア1のボットはティア2では役に立ちません。ヘルプセンターはまさにティア1がすでに試したものだからです。ティア2の答えは、解決済みチケットや社内のランブック、そしてライブデータの中にあります。それらを読めないAIは調査できず、上で引用した人たちの懐疑はもっともなものになります。
事前調査されたエスカレーションはどんな形であるべきですか?
優秀なシニアエージェントが同僚のために書くケースファイルを思い浮かべてください。AIが自らチケットをエスカレーションする場合でも、ティア1がエスカレーションしたチケットを引き継ぐ場合でも、そのメモは担当者が判断にすぐ進めるものであるべきです。
含めるべきものは5つです。
- 顧客の要望。スレッド全体の要約ではなく、1文で。
- データが示すこと。 注文状況、サブスクリプションの状態、プラン、最終ログイン、照会が返したものを、レコードへのリンク付きで。
- 類似する過去のチケット。それぞれの解決方法と解決した人とともに。
- すでに除外したこと。 ティア1が試した手順と、データから除外される原因。
- 推奨される次のステップ。加えて、AIが確認できなかったことについての正直な一行。
請求のエスカレーションで私が欲しいメモの形はこうです。
Customer wants: refund for a second charge on 14 Oct.
Data: Stripe shows two successful charges of $49 on 14 Oct, 3 minutes apart,
same card. One subscription active. No refund issued yet.
Similar tickets: 3 in the last 60 days, all double charges after a failed
card update retry. All refunded in full by the billing team.
Ruled out: not a plan change (plan unchanged since June), not a currency
conversion charge.
Next step: refund the second charge (needs approval). Could not check
whether the retry bug ticket in engineering is still open.
eeselのドキュメントは、まさにこれをエスカレーションについて説明しています。メモは"should give the human everything they need: what the customer wants, what you found, and what you'd have said"であるべきで、エージェントが答えを見つけられない場合は"say what you searched for in your note"とされています(eeselの指示に関するドキュメント)。ティア2では最後の部分が非常に重要です。「直近1,000件のチケットと請求ドキュメントを検索したが、このエラーに関する情報は見つからなかった」というメモがあれば、担当者が同じ検索を繰り返さずに済みます。
現時点でAIが引き受けられるティア2の仕事は何ですか?
調査の大半は引き受けられますが、判断はあまり任せられません。最初に私が採用する分担は次のとおりで、ヘルプデスクベンダー自身のドキュメントとも一致しています。
| ティア2の仕事 | AIがすること | 人に残ること |
|---|---|---|
| チケットの情報補完 | 注文、アカウント、プラン、最近のアクティビティをチケットに取り込む | 特殊なケースでどのデータが重要かを判断する |
| 先例の検索 | 表現が違っても、同じ問題の解決済みチケットを見つける | 過去の修正がまだ通用するかを判断する |
| トリアージとルーティング | タグ付け、優先度付けをして適切な専門グループに割り当てる | 例外、VIP、政治的にデリケートなもの |
| 返信の下書き | チームのトーンで修正内容を書き、出典を示す | 事実の確認、送信 |
| 書き込みアクション | 返金、キャンセル、住所変更を準備する | 承認する |
| ナレッジの蓄積 | 解決したエスカレーションをヘルプ記事やランブックの下書きにする | 公開する |
この中の2つの行は少し補足が必要です。先例の検索はティア2に最も多くを返してくれます。シニアエージェントは記憶から行い、新しいエージェントにはまったくできないからです。ナレッジの蓄積は、次のエスカレーションを不要にする方法です。記事になったティア2の修正は、翌月にはティア1の回答になるからです。たとえばeeselのナレッジギャップレポートは、回答できなかった直近30日間の質問を一覧にし、不足している上位3ページを下書きします(eeselのスキルに関するドキュメント)。
Zendesk、Freshdesk、Jira Service Management、Gorgiasはすでに何をしていますか?
大手ヘルプデスクはどれも、ティア2向けの支援をすでに提供しており、その多くはエスカレーションに取り組む人間のエージェントを対象としたAIコパイロットです。何かを購入する前に、現在のプランにすでに何が含まれているかを確認する価値があります。
| ヘルプデスク | 類似チケット | 要約 | AIアクションと照会 | AI層の価格 |
|---|---|---|---|---|
| Zendesk | あり。解決済みチケットを"even when it's described in different words"照合 | 公開コメントのみ | Auto assist:Shopifyの注文アクション、カスタムAPIアクション | Copilot 1エージェントあたり月額$50(年払い) |
| Freshdesk | あり。信頼度、エージェント、グループ、CSATを表示 | Issue、Steps Taken、Outcome。プライベートノートを含む | AI AgentのAPIアクション | Freddy AI Copilot 1エージェントあたり月額$29 |
| Jira Service Management | タイトルベースのパネル。Rovo Service Request Helperが類似の作業項目を検索 | PremiumとEnterprise、自分にのみ表示 | 接続ツールを使うRequest Resolver | Rovoクレジットはプランに含まれる |
| Gorgias | 人間のエージェント向けには記載なし | 長い会話のチケット要約 | HTTPリクエストを含むAI Agentアクション | 上限を超えた自動対応1件あたり$1.50 |
Zendesk Copilot
Zendeskのティア2向け機能はCopilotアドオンにあり、年払いで1エージェントあたり月額$50、Professionalプラン以上で利用できます(Zendeskの料金)。アドオンがなくても、Suite Professionalには要約、類似チケット、統合の提案がありますが、1エージェントあたり月5回までの制限があります。最もティア2に合った機能は担当者の提案で、類似チケットを誰が解決したかに基づいて"a ticket that needs to be reassigned or escalated"の割り当て先を見つけるのに役立ちます(About Zendesk Copilot)。
Auto assistは調査に最も近い部分です。返信とアクションを提案します。Shopifyの注文を照会、キャンセル、返金でき、カスタムアクションを通じて独自のAPIも呼び出せます。ルーティング用のインテリジェントトリアージと組み合わせれば、エスカレーションの経路の大部分をカバーします。
照会は事前承認できますが、"actions that update data, such as refunding an order, still require your approval"です(Using auto assist)。知っておくべき制限が2つあります。提案できるのは"up to four actions at a time"で(About actions)、チャットや音声チャネルでは設定できません。
FreshdeskのFreddy AI Copilot
Freshdeskの類似チケット機能は、私が見つけた中で最も役立つネイティブのティア2ツールです。各一致に、信頼度スコア、解決したエージェントとグループ、CSATスコアが表示されるからです(Similar tickets in Freshdesk)。新しいエージェントは何が効いたかを学べるだけでなく、誰に聞けばよいかも分かります。最大6か月分、または120,000件の解決済みチケットから学習し、取り込みに2〜5日かかり、Freshdeskは高い精度のために少なくとも5,000件のチケットを推奨しています。
Freddyのチケット要約は、プライベートノートも"Steps Taken"セクションに取り込みます。ティア1が試したことを書き留めるのはプライベートノートなので、ティア2にはまさにこれが必要です(Freddy Summarize)。どちらもFreddy AI Copilot(1エージェントあたり月額$29)に含まれ、Pro($55)とEnterprise($89)のみで販売されています(Freshdeskの料金)。
Jira Service ManagementとGorgias
Atlassianはこれを直接こう表現しています。"when a request does reach a human, agents burn time reading long threads"。そしてService Request Helperエージェントは、アクティビティを要約し、次のステップを提案し、返信を下書きし、専門家を推薦し、過去のチケットを提示します(Atlassian AI guide)。その"Generate case summary"は"for effective resolution and handover"書かれます(Service Request Helper)。AIを使わない組み込みの類似リクエストパネルはタイトルのみで照合するため、本当の先例検索にはRovo版が必要です。
Gorgiasは、AI活用の努力の大半をフロントラインに注いできました。AI Agentは、怒り、人間への要求、法務や金融に関するトピックでは必ず引き継ぎを行い、管理者はこれをオフにできません(Gorgiasの引き継ぎに関するドキュメント)。引き継ぎを受ける人のために、Gaiaは"what's already been tried"を要約しチケットを割り当てられますが、"doesn't draft messages"です(Gaia explained)。
これらに共通しているのは、ネイティブのツールはヘルプデスクの中であれば、要約も先例の検索もうまくこなすことです。しかし、その外にあるデータ(注文システム、請求ツール、自社製品の管理画面)で止まります。ティア2の答えの大半があるのは、その外側のデータです。
実際の運用ではどうなっていますか?
以下はeeselの顧客4社で、それぞれ上記の3種類のチケットに対応する設定です。どの会社もヘルプデスクを置き換えてはいません。eeselは、各チームがすでに使っていた既存のヘルプデスク向けAIとして動作します。
長年の解決済みチケットから行う技術サポート。 Timengoは、デンマークの自治体、学校、会計事務所が使う安全なメールとDigital Postのソフトウェア、DPG Sikker Postをサポートしています。問い合わせてくるのは、証明書の更新、インストールできないOutlookアドイン、止まったメールフローを抱えるITアドミンです。eeselは製品ドキュメントと約5,300件の過去のチケットや記事から同じ問題を検索し、デンマーク語の下書きを書き、見つけた内容を載せたエンジニア向けの社内メモを残します。ある月には、約300件のFreshdeskチケットを準備し、約180件の下書きと260件の社内メモを作成しました。すべての返信はエンジニアが送信します。
オンデマンドの先例検索。 OroSoftは地金のトレーダーと精錬業者向けのERPソフトウェアを開発しているため、Freshdeskの質問は具体的で技術的です。サポートエージェントがチケットでeeselにメンションすると、約6,100件の解決済みチケットをもとに、類似チケットへの回答を踏襲しつつ、使ったチケットや記事を明示して下書きします。返信を裏付けるものがなければ、でっち上げずにその旨の社内メモを残して人を求めます。
既知の修正をティア2から遠ざける。 Cactus Club Cafeは、社内のIT技術サポートデスクをZendeskで運営しています。ティア1のエージェントはチケット全体を読み、緊急時のポリシーとルーティングマトリクスを確認し、該当するランブックから手順どおりに修正を下書きします。ある月には約750件のチケットを処理し、約790件の下書きを書き、ランブックやポリシーを約1,650回、つまりチケット1件あたり約2ドキュメント参照しました。下書きできる既知の問題が1件増えるごとに、専門担当者に届くチケットが1件減ります。
一言も書く前の照会。 GorgiasとShopifyを使うプランナー・文具ブランドのSTIL Classicsでは、注文番号のあるチケットはすべて、最初に注文、フルフィルメント状況、商品、配送先住所が取得されます。ある月には320件のチケットにわたって約230件のShopify注文が照会され、下書きが示す返金は人が行います。eeselはそこで注文を変更することはありません。
AIはティア2の時間をどれだけ取り戻せますか?
ここにご自身の数字を入力してください。デフォルト値は仮の数値であり、ベンチマークではありません。ご自身のキューに合うまで変更してください。計算ツールは、エスカレーションを3種類のチケットに分け、それぞれの施策で解放される専門担当者の時間を見積もります。
最初のカードに注目してください。私が話すチームの多くは、ティア2を速くすることが成果の源だと考えていますが、より大きな施策は、そもそもティア2を必要としなかったチケットの割合であることのほうが多いです。それを1件止めるごとに、数分ではなく処理時間の全体が節約されます。
ティア2のチケットでAIが絶対にしてはいけないことは何ですか?
これらのチケットは金銭、アカウント、データに関わるため、ティア2の制限はティア1より厳しくなります。私が守りたいのは次のことです。
- 見えない原因を推測すること。 AIがログ、管理画面、注文システムを読めないなら、それらを調査することはできません。良い設定では、もっともらしい話で穴を埋めるのではなく、確認できなかったことを正直に伝えます。
- 金銭やデータを独断で変更すること。 返金、キャンセル、プラン変更、アカウントの編集は承認の後ろに置きます。eeselのドキュメントは"refunds, cancellations and anything that costs money behind an approval"を推奨しており(eeselのアクションに関するドキュメント)、Zendeskもauto assistで同じ方針をとっています。
- まったく新しいバグを抱え込むこと。 誰も見たことのない不具合には人が必要で、たいていはエンジニアリングです。そこでのAIの仕事は、きれいな要約とバグ報告の作成で、これはバグ報告のトリアージのためのAIの記事で扱っています。
- 怒っている顧客や重要な顧客に、レビューなしで返信すること。 GorgiasはAI Agentにこの引き継ぎを固定で組み込んでおり、あらゆるティア2の設定で妥当な既定値です。
ティア2の書き込みアクションについて、上のスクリーンショットは私の好きなパターンを示しています。エージェントは調査を済ませ(支払いインテントを見つけ、注文と照合し、課金を確認し)、そして金銭を動かす手順の直前で止まり、人がApproveをクリックします。承認の選択肢はApprove、Always allow、Denyのいずれかで、承認がタイムアウト後に自動で実行されることはありません。
不適切な回答のリスクを負わずに、ティア2へAIを導入するにはどうすればよいですか?
人が最も長くコントロールを保てる順番で、ゆっくり進めます。私が勧める導入は4ステップで、下のステップが退屈に感じられるようになってから次に進みます。
ステップ1:解決済みのチケットでシミュレーションする
AIが実際のエスカレーションに触れる前に、チームがすでにクローズしたエスカレーションで再現し、その回答を専門担当者が送った内容と比較します。eeselのヘルプデスクシミュレーションは、最近解決した20件のチケットを取り上げ、それぞれに自前の返信を下書きし、テーマ別に採点し、"sends nothing to customers"です(eeselのスキルに関するドキュメント)。スコアが難しいチケットを反映するよう、キュー全体ではなくティア2のグループに絞って実行してください。
ミスを丁寧に読んでください。eeselのドキュメントにある実行例では、20件中17件が一致し、レポートの指摘は、本当のギャップは文面ではなくアクションにあるというものでした。人がまだ必要なチケットは、何も接続されていないバックエンドの変更を要していたのです。これはティア2の発見であり、次にどの照会やアクションを接続すべきかが分かる、有用なものです。
ステップ2:社内メモのみ
ティア2のグループに対して、出力を1つだけにして有効化します。エスカレーションされたすべてのチケットに、上記のケースファイル形式で書かれた社内メモです。顧客への返信はなし。担当者はメモを読み、普段どおりチケットに対応し、メモが間違っていたらフラグを立てます。このステップで、AIの照会が正しいレコードを返すかどうかが分かります。
ステップ3:人が送信する下書き
担当者がメモを信頼するようになったら、編集して送信できる返信の下書きを加えます。下書きがそのまま送られる頻度をトピック別に追跡してください。どのトピックがステップ4の準備ができているかが分かります。eeselでは、チャットで行った修正が指示またはメモリとして保存されるので、同じミスが翌週に繰り返されることはありません(eeselの指示に関するドキュメント)。
ステップ4:範囲を絞った実績のあるトピックで送信する
下書きが数週間そのまま送られているトピックに限って、AIに直接返信させ、その場合でも書き込みアクションは承認制のままにします。ほとんどのチームでは、照会の多い数トピックがここまで到達し、本当に新しい問題は決して到達しませんが、それで問題ありません。返信を1通も送らなくても、すべてのエスカレーションを事前調査するティア2のAIは、専門担当者に時間を返してくれます。
うまくいっているかどうかはどうやって分かりますか?
問い合わせ削減率では測れません。ティア2ではAIは主に人を助けるので、人の作業を測るほうが理にかなっています。
- ティア1からのエスカレーション率。 CSATを保ったまま下がっているなら、AIはティア2を必要としないチケットを止めています。
- 最初の有用な発見までの時間。 エスカレーションから、担当者が行動に移す最初の証拠までの時間です。事前調査はこれを最も大きく短縮するはずです。
- ティア2の処理時間。 照会の多いトピックでは短くなり、本当に新しい問題では変わらないはずです。
- メモの採用率。 担当者がAIの照会をやり直さずにメモに基づいて行動する頻度です。
- 再オープン率。 速くなっても戻ってくる修正は、修正とは言えません。
これらの大半をヘルプデスクから取得する方法はサポートレポートのためのAIの記事で、また総時間が減っても残りのチケットの処理時間が増えうる理由は処理時間の短縮のためのAIで解説しています。
ティア2サポートでeeselを試す
専門担当者がエスカレーションのたびに最初の15分を同じ4つのタブを開くことに費やしているなら、eeselが先に開けます。eeselは、新しいチームメイトのようにZendesk、Freshdesk、Gorgiasのキューに参加し、過去のチケットやランブックから学び、注文、サブスクリプション、独自のAPIを照会し、誰かがチケットを開く前にケースファイルのメモを残します。どのアクションを単独で実行でき、どれがクリックを待つかは、あなたが決めます。
最初の一歩として、先月のティア2のチケットでシミュレーションを行い、どれだけ解決できたかを確認するのがおすすめです。無料で試せ、有料プランは500クレジットで月額$299から、eeselの料金ページで確認できます。eeselを試す。