チケットエスカレーションプロセス:機能するプロセスの設計方法

チケットエスカレーションプロセスとは実際には何か

チケットエスカレーションプロセスとは、サポートチケットが現在対応している人(またはシステム)の手を離れ、次にどこへ行くかを規定するルールの集まりです。習慣ではなくプロセスにする要素は3つあります。

• トリガー - 「ここでは解決できない」ことを示す具体的な条件。
• ルート - どのチーム、シニアリティ、またはシステムが受け取るか。
• 引き継ぎ - 次の担当者がゼロから始めなくて済むよう、チケットとともに移動するコンテキスト。

この3つを書き出し、ヘルプデスクに組み込めば、プロセスができあがります。どれか一つでも即興に任せれば、最も難しいチケットが到着したまさにそのとき、つまり最も余裕がないときに詰まるキューができあがります。

多くのチームが行き着く構造はこうです。チケットは、それを解決できる可能性がある最も労力の少ないティアで入り、トリガーが発動したときにのみ上へ上がります。

このはしごの意味は、階層そのものにあるのではありません。各段が高くつくため、実際に解決できる人にたどり着いた瞬間にチケットが上がるのを止めたい、ということです。うまく運営されているプロセスは、解決をできる限りはしごの下へ押し下げ、本当に上の段が必要なものだけをエスカレーションします。

2種類のエスカレーション(そしてなぜ両方が必要か)

「エスカレーション」という言葉は、まったく異なる2つの動きを覆い隠しています。これらを混同するチームは、複雑なバグを修正できないマネージャーに送り、怒っている顧客を落ち着かせられないエンジニアに送ることになります。

機能的エスカレーションは、チケットを横方向に、適切な専門知識やシステムアクセスを持つ人へ動かします。SSOの設定ミスだと判明したパスワードリセットはTier 2へ行きます。「APIが500エラーを返している」というチケットはエンジニアリングへ行きます。組織図上で誰も上位というわけではなく、単にその件に詳しいだけです。

階層的エスカレーションは、チケットを上方向に、より高い権限を持つ人へ動かします。ここでのトリガーは知識であることはめったになく、決定や関係性であることが多いです。ポリシー外の返金、返信にマネージャーの名前が必要な苦情、解約をちらつかせるエンタープライズアカウントなどです。

これらを別々に呼ぶ理由は、それぞれ別のトリガーと別のルートが必要だからです。1つのチケットが両方の経路を同時にたどることさえあります。大口顧客に影響する請求バグは、機能的にはエンジニアリングへ、かつ階層的には修正が届くまで顧客をつなぎ止めるアカウントマネージャーへ行くかもしれません。eeselのあるフィンテック顧客は、月におよそ7,000〜8,000件のエスカレーションされたチケットのキューの上に、サードパーティの支払いパートナーを待つ間、安心させるメッセージでエスカレーションされたチケットを「保温」しておくワークフローを、ほぼこの通りに構築しました。エスカレーションが顧客の不安の時計を止めるわけではないため、彼らはそれを管理する2本目のトラックを構築したのです。

エスカレーションのトリガーとなるもの

トリガーこそが、曖昧なプロセスを本物のプロセスに変える部分です。ルールが「対応できないときはエスカレーションする」であれば、担当者ごとに驚くほど一貫性のない判断になります。代わりに条件を明確に名付けましょう。よくあるものは次の通りです。

• 知識またはアクセスのギャップ - 回答には現在の担当者が持っていないスペシャリスト、システム、または権限が必要。
• SLAリスク - チケットが応答期限または解決期限に近づいている。これは自動化する価値が最も高いトリガーです。しっかりしたSLA設定は、期限違反の後ではなく前にリスクのあるチケットにフラグを立てるべきです。
• 感情/苦情 - 顧客が怒っている、自らエスカレーションしている(「マネージャーと話させてください」)、または解約リスクがある。
• 権限 - 返金、ポリシー例外、契約上の約束など、担当者に権限がない決定。
• 繰り返しの連絡 - 顧客が同じ問題で何度も連絡してきている。再オープンされたチケットは、多くのチームが見逃す静かなエスカレーショントリガーです。

私が使う簡単な直感チェックはこうです。現在の担当者があと5分と正しいドキュメントがあれば解決できるなら、それはエスカレーションすべきチケットではなく、修正すべきナレッジギャップです。エスカレーションは本当にできないことのためにあり、不要なエスカレーションが1件増えるたびに、より高コストな人材が下位のティアでもできた仕事をしていることになります。

その判断を具体的にするため、同じロジックを簡単な意思決定ヘルパーとして示します。直面している状況を選んでください。

エスカレーションプロセスをステップバイステップで構築する

30ページのランブックは必要ありません。必要なのは、明示的に下された4つの決定をヘルプデスクにコード化し、毎回同じように実行されるようにすることです。

1. ティアを定義する

まず、チケットが取りうるレベルに名前を付けることから始めます。典型的な形は、下からセルフサービスとAI、次にTier 1(ジェネラリスト担当者)、Tier 2(スペシャリストまたはシニア担当者)、Tier 3(エンジニアリングまたはプロダクト)で、マネジメントは階層的な行き先として脇に位置します。小規模なチームはこれを2つのティアプラス「創業者に聞く」に圧縮しますが、それで問題ありません。ティアの数よりも、どこに何が属するかについて全員が合意していることの方がはるかに重要です。

2. トリガーを文書化する

上のセクションのトリガーリストを取り上げ、自社製品に合わせて具体化しましょう。「SLAリスク」は「30分以内に確認されていない優先度1のチケットはすべてエスカレーションする」になります。「権限」は「200ドルを超える返金はすべてチームリーダーへ」になります。トリガーが機械でも従えるような分類ルールに近づくほど、エスカレーションはより一貫性が高く(そして自動化しやすく)なります。

3. 引き継ぎを標準化する

これはチームが飛ばしがちなステップであり、エスカレーションが実際に時間を節約するかどうかを決めるステップでもあります。コンテキストなしでTier 2に届いたチケットは、スペシャリストにスレッド全体を読み直させ、顧客に再度質問させることになります。まさにここで「エスカレーション」が「リセット」のように感じられ始めるのです。最低限の引き継ぎ内容を定義しましょう。何を試したか、関連するアカウントの詳細、そして実際の要望の1行要約です。優れたチケットトリアージとルーティングは、人間がチケットに触れる前にこの大部分を済ませてくれます。

4. エスカレーション率を測定する

どれくらいの割合のチケットがエスカレーションされ、その理由が何かを追跡していなければ、プロセスを改善することはできず、ただそれを回しているだけです。エスカレーション率は、操作しにくいという点で、より正直なサポート指標の一つです。上昇する率は通常ナレッジギャップや製品の後退を意味し、(初回接触解決率の低下を伴わない)下降する率は現場の対応力が高まっていることを意味します。毎月理由を見直し、上位のものをドキュメントやマクロにフィードバックしましょう。

エスカレーションを静かに壊すよくある失敗

実際のキューで何度も目にするパターンをいくつか紹介します。

• プロセスが人々の頭の中に存在する。 新しい担当者は「請求は誰が担当だっけ?」と同僚に聞くことでエスカレーションを学びます。これは最も一般的な失敗であり、チームが成長するにつれてまさにエスカレーションが遅くなる理由です。ルールをヘルプデスクにコード化しましょう。
• すべてが優先度1になる。 すべてのチケットを緊急とフラグ付けできるなら、どれも緊急ではなく、エスカレーションキューは2番目の受信トレイになってしまいます。優先度を具体的な基準に結びつけましょう。
• エスカレーションが押し付け先になる。 担当者は、本当に上位のティアが必要だからではなく、難しいチケットを他人の問題にするためにエスカレーションします。これはコストを膨らませ、本当に重要なエスカレーションを埋もれさせます。
• 戻る経路がない。 設定の問題だと判明したエンジニアリングへのエスカレーションチケットは、1週間エンジニアリングのキューに座っているのではなく、回答とともにTier 1へ戻すべきです。エスカレーションは双方向であるべきです。
• コンテキストなしの引き継ぎ。 上で述べましたが、繰り返す価値があります。引き継ぎのないエスカレーションはエスカレーションではなく、やり直しです。

AIがエスカレーションプロセスを変える場所

ここが実際に重要だった転換点です。長年、エスカレーションを減らす唯一の方法は、担当者をより厳しく訓練し、より多くのドキュメントを書くことでした。今では、キューの前に座り、すべてのチケットを読み、自ら最初のエスカレーション判断を下すレイヤーが存在します。

その動きは「AIがすべてを解決する」ことではありません。本番環境でボットを運用したことがある人なら誰でも、それが自信満々に間違った回答をする早道だと知っています。これをうまくやっているチームは確信度ベースのルーティングを使っています。AIは本当に確信が持てるチケットを解決し、残りは下書きの返信とすでに添付されたコンテキストとともに人間へエスカレーションします。私が出会ったあるCXリーダーは、この考え方全体を一言に凝縮しました。「対応する確信があるチケットだけを扱い、それ以外はすべて放っておくAI」が欲しかった、と。その抑制こそが機能であり、制約ではありません。

これがプロセスに与える影響は、微妙ですが大きいものです。かつて現場の1日を食いつぶしていた反復的なチケットが担当者に届かなくなるため、Tier 1のボリュームが減少します。そして、人に届くエスカレーションは、事前にトリアージされ、分類・タグ付けされた状態で到着し、多くの場合、内部メモに提案された返信がすでに添えられています。月に200〜250件のチケットを処理するZendesk上のバス追跡サービスであるeeselのある顧客は、目標をまさにこう表現しました。「受信したZendeskチケットの60%を処理し、いつ本物の担当者を呼び込むべきかを知る」ものを構築すること、と。「いつ人を呼び込むべきかを知る」部分こそが、ソフトウェアによって実行されるエスカレーションプロセスそのものです。

これは、自動化によって機能的対階層的の区別が効果を発揮する場所でもあります。AIレイヤーは、バグレポートをエンジニアリングへ送ると同時に、怒っている顧客のスレッドにマネージャー向けのフラグを立てることができます。トリガーが、その場の担当者の判断ではなく、明示的なルールだからです。

エスカレーションプロセスにeesel AIを試す

目標がより少なく、より速く、より準備の整った状態で届くエスカレーションであるなら、eesel AIはまさにそのために作られています。既存のZendesk、Freshdesk、Jira Service Management、Front、Gorgiasのセットアップの上に乗り、過去のチケットやヘルプドキュメントから学習し、確信度ベースのルーティングでTier 1のボリュームを処理します。これにより、確信度の低いチケットは顧客への誤った回答ではなく、人間向けの下書き返信になります。

導入前に試す価値がある部分は、過去のチケットに対してAIを実行し、実際の顧客に触れる前にどれだけ解決できたか、何をエスカレーションしていたかを確認できるeeselのシミュレーションモードです。ある顧客であるGridwiseは、導入初月に eesel がTier 1リクエストの73%を解決するのを目にし、7日間のトライアル中に成果が現れました。エスカレーションルールは平易な言葉で設定でき(「返金に関することはすべて、送信せず下書きにする」など)、無料で始められ、使用量ベースの価格設定で、席数課金はありません。