繰り返しのサポートチケットとは何を指すのか？
私はeeselでサポートについて書いていて、その前の2年間はSEOをやっていたので、検索クエリを読むのが仕事でした。「繰り返しのサポートチケット」というフレーズが興味深いのは、入力する人が定義を知りたいわけではないことが多いからです。見覚えのある名前ばかりが並ぶキューを見つめて、なぜ同じ顧客が何度も連絡してくるのかと考えているサポートリーダーです。この記事はその疑問に答えようとしています。
eeselでは数年にわたって実際のヘルプデスクのキューでAIを動かしてきました。営業の通話で見る限り、パターンはかなり一貫しています。リピートが高くつくことはチームも知っているのに、その半分を見逃す指標で測っているのです。
「繰り返しのチケット」と言うとき、たいてい次の4つのどれかを指しています。
| 用語 | 内容 | 現れる場所 |
|---|---|---|
| 再オープン | 顧客が解決済みチケットに返信し、同じチケットがオープンに戻る | ヘルプデスクの再オープン指標 |
| フォローアップチケット | チケットがクローズまたはアーカイブされた後に顧客が返信し、ヘルプデスクが関連付けた新しいチケットを作る | 別のチケットで、見逃されやすい |
| 重複チケット | 顧客が同じ問題で2回書く。しばしば2つのチャネルから | オープンのチケットが2つ、担当者も2人 |
| リピート問い合わせ | 上記のいずれか：同じ顧客、同じ問題、一定期間内 | 自分で仕組みを作った場合のみ |
ここで本当に重要なのは最後の行です。リピート問い合わせ率は3つの経路すべてを数えるのに対し、再オープン率は最初の1つしか数えません。
再オープン率がリピート問い合わせを過小評価する理由
どのヘルプデスクにも切り替わりの境目があります。その前なら顧客の返信は古いチケットを再オープンし、その後は返信が新しいチケットになって、再オープン指標からは見えなくなります。境目はツールごとに違い、ほとんどのチームは調べたことがありません。
各ヘルプデスクの公式ドキュメントによる挙動は次のとおりです。
- Zendesk。 標準の自動化が、解決から4日後にチケットをクローズします。28日まで延ばせますが、なくすことはできません。クローズ後は、Zendeskのフォローアップのドキュメントによると「any response to a closed ticket from any channel automatically creates a follow-up ticket」とのことです。
- Gorgias。 クローズ済みチケットへの返信は再オープンしますが、メールでは「more than 10 days after the last message」の返信は新しいチケットに分割されます。チャット、SMS、音声、SNSのDMでは3日後に分割されます。Gorgiasの課金ドキュメントに記載されています。
- HubSpot。 ここは自分で選べます。チケット再オープンの設定には、Always reopen、Set a time frame、Never reopenがあり、Service Hub ProfessionalとEnterpriseで使えます。
- Freshdesk。 「Tickets reopened」指標は、解決済みまたはクローズ済みでOpenに戻ったチケットを数えます。クローズ済みチケットが120日放置されるとアーカイブされ、その後の返信は「creates a new ticket instead of reopening the archived one」となります。
- Help ScoutとFront。 Help Scoutは、Conversation Lockを設定しない限り、クローズ済みの会話を再オープンします。Frontはメールの会話をデフォルトで30日後にクローズし、その後の返信を新しい会話に分割します。
HubSpotの方式は判断をすべて任せてくれるので、トレードオフが最もわかりやすく見えます。
つまり、Zendeskがまだデフォルトの4日のままなら、5日目に戻ってきた顧客は再オープン率からは見えません。Redditのサポートリーダーの一人が、行動面をうまく言い表していました。
"Reopen rate helps too but people learn to just open a new ticket instead of reopening, so you really need the repeat contact window to catch it"
Zendesk側をもっと詳しく知りたい場合は、自動化で設定できるチケット再オープンの条件をまとめています。
初回contact解決率が上がっても、リピートも上がり得る理由
もう1つ触れておきたい落とし穴が初回contact解決率です。ほとんどのヘルプデスクは問題単位ではなくチケット単位で計算するため、顧客が新しいチケットを作ると実質的に時計がリセットされ、新たな成功としてカウントされます。
ネイティブの定義を見ると、どれだけ狭いかがわかります。
- Zendeskに最も近い指標はone-touch ticketsで、担当者の返信が1回またはゼロで解決したものです。新しい質問を含む再オープンはone-touchから外れますが、フォローアップチケットは元のチケットに影響しません。
- Freshdeskの「Tickets resolved within FCR (%)」は、指標の用語集によると、最初の連絡の後に顧客の返信がゼロであることを条件とします。そして新しいチケットは返信ではありません。
- Help Scoutはメールレポートで「Resolved on First Reply」を報告しますが、これも会話単位です。
その結果、こんな話になります。
"We hit 78% FCR last quarter. Leadership celebrated. Bought donuts and everything. Then I pulled the data on customers who contacted us 3+ times in 30 days. The number went up. Turns out we were "resolving" tickets by closing them, not by actually fixing the underlying issue."
FCRをやめるべきだと言っているわけではありません（初回contact解決のためのAIのガイドも丸ごと書きました）。one-touch解決も同じです。どちらも有用です。ただ、リピートの数字を隣に置かずに報告しないでください。CSATなしで解決率を報告しないのと同じです。
リピート問い合わせ率の測り方
私が使う式はこうです。
リピート問い合わせ率 = 同じ顧客が7日以内に同じ問題で再び連絡してきた解決済みチケット数 ÷ 期間内の解決済みチケット全体
最初に決めておくことがいくつかあります。
- 期間を決めて、変えない。 メールとチャットなら7日が妥当な初期値で、コールセンターでは14日や30日もよく使われます。あるReddit投稿者は、統計のためにチケットを閉じる担当者を見つけるために72時間以内の再オープンを確認することを提案していました。どれを選んでも、四半期の途中で変えないでください。
- 顧客だけでなく、顧客と問題の両方で照合する。 返金について書き、2週間後にログインの問題で書いてきた顧客はリピートではありません。担当者はそれで責められるのを嫌がりますし、その気持ちは正しいです。
- チャネルをまたいで数える。 同じ顧客がメールを送り、その後チャットを開いても、1つの問題です。ヘルプデスクがそれらを関連付けていない場合があります。
次に、ヘルプデスクがすでに提供しているものから数字を取ります。
| ヘルプデスク | 再オープン | 新しいチケットになるリピート | 初回contact型の指標 |
|---|---|---|---|
| Zendesk | Exploreの「Reopened tickets」と「Reopens」 | 更新チャネル「Closed Ticket」で絞り込んだフォローアップ | One-touch tickets |
| Freshdesk | 「Tickets reopened」 | アーカイブ後の新しいチケット。連絡先のアーカイブ済みチケットから探す | Tickets resolved within FCR (%) |
| Gorgias | 新しいHelpdesk performanceレポートのReopenedバケット | 10日後（メール）または3日後（チャット、SMS、音声）に分割されたチケット | ネイティブのFCR指標は見つからず |
| HubSpot | 「Ticket reopen date」プロパティ | 元のチケットにリンクされた新しいチケット | ネイティブのFCRレポートなし |
| Help Scout | Activeに戻された会話 | 新しい会話（Conversation Lockがオンの場合） | Resolved on First Reply |
| Front | Workloadレポートの「Reopened conversations」 | クローズ後にリンクされた新しい会話 | ネイティブのFCR指標なし |
これらのどれも「同じ問題」を最初から出してはくれません。そこに最も安く到達する方法はタグです。担当者が明らかに2回目の連絡だと分かるチケットを受け取ったら、repeatタグと理由タグを付けます。Redditのある返信が、私よりうまく言い表していました。
"You're right that three cheap contacts on one issue is not three wins. It is one unresolved problem with a growing cost and a customer who now expects the next reply to fail. Tag the second contact as a repeat of the first before anyone closes it again."
手作業のタグ付けは定着しないと感じるなら、その通りで、3週目を過ぎると続かないことがほとんどです。AIによるチケットタグ付けなら、リピートタグと理由タグを自動で付けられ、数字は他のフィールドと同じようにヘルプデスク自身のレポートに載ります。
そこから先は普通のレポートです。Zendeskなら、チームがすでに見ている同じ分析ダッシュボードにリピート率のウィジェットを追加しますし、Gorgiasではタグが標準のGorgias analyticsのビューに表示されます。
繰り返しのチケットはいくらかかるのか
繰り返しのチケットは、最初の連絡よりコストがかかります。顧客はよりいらだっていて、担当者は返信の前に履歴を読む必要があり、その上、1つの問題に2回支払っています。チケット単価にはこれが現れません。1件ずつ見れば普通のチケットだからです。
下に自分の数字を入れてください。初期値は例にすぎません。
月間の解決チケット数、リピート率、対応時間、担当者のコストを入力すると、繰り返しのサポートチケットのコストと、半分にした場合の価値がわかります。
ただし、ドル換算の金額は話の半分にすぎません。3回も追いかけなければならなかった顧客は、星1つのレビューを書く人であり、そのコストは解決あたりのコストの計算には現れません。
顧客が再び連絡してくる理由：4つの根本原因
リピートのチケットを50〜100件取り出して実際に読むと、理由はほぼいつも4つのグループに分かれます。eeselの通話でサポートチームから聞く話とも一致します。
1. チケットは閉じられたが、問題は直っていなかった
これが最大の原因で、たいてい人の問題である前に指標の問題です。担当者がクローズしたチケット数で評価されるなら、クローズすること自体が目的になります。
"Resolution looks good because the ticket gets closed, but customers sometimes come back a few days later with basically the same problem."
リピートが減れば全体のチケットも減り、それがチケット量の削減の最も安い形です。
ここでの対策は、チケットが閉じられたかどうかだけでなく、「メッセージ内のすべての問題が解決した」をQAスコアカードの項目にすることです。誰が採点しても同じになるよう、レビュアー間で調整してください。これはQAキャリブレーションで解説しました。
2. 顧客が待っている間に更新連絡がなかった
返金や配送遅延はリピートを生み、バグのエスカレーションも同様です。顧客側から見ると、何日も何も起きないからです。次の更新がいつ来るか誰も伝えていないので、「any update?」と書いてきます。
これが、ECのキューで「注文はどこ？」が多くを占める理由です。eeselの営業通話で、1日500件以上のチケットを扱う複数ブランドのEC事業者が、返金依頼、配信停止、注文追跡が自社の件数の大半を占めると話していました。これはまさにリピートの典型的なカテゴリです。
対策はプロアクティブサポートです。すべての返信を、次の更新がいつ届くかで締めくくり、実際にそれを送る自動化を設定します。Gorgiasは返信がない場合にフォローアップでき、Zendeskは時間ベースの自動化で同じことができます。
特に注文状況については、ライブの追跡情報を読むボットがマクロに勝ちます。両者は注文状況チャットボットのガイドで比較しました。プロアクティブ対リアクティブのサービスの記事には、トレードオフについてもっと書いています。
3. 半分だけの回答、または間違った回答
文字どおりの質問には答えても、次に来るはずの質問に答えていない返信は、2つ目のチケットをほぼ確実に生みます。「返金を処理中です」は「いつ受け取れますか？」を呼び込みます。マクロは、一般的なケース向けに書かれたものが例外的なケースに貼られると、これをさらに悪化させます。
"The responses are a push of a button by Customerservice representative and so patronizing because most the time they get it wrong."
対策は2つあります。マクロを実際のチケットと照らして点検し（私ならAIマクロのガイドから始めます）、ナレッジギャップ分析でヘルプセンターがカバーしていない質問を探します。より広いナレッジベース監査では、単に古くなった記事が見つかります。ドキュメントが読者を取り違えて書かれていることもあります。私たちが話したあるサポートマネージャーのナレッジベースは管理者向けに書かれていたのに、チケットはエンドユーザーから来ていて、わかりにくい返信につながっていました。
4. 顧客が最初から説明し直さなければならなかった
シフト間やティア間、チーム間の引き継ぎでは文脈が失われ、中でもボットから人への引き継ぎは最大の原因です。顧客は同じことを繰り返し、少し違う回答を受け取り、3回目の連絡をしてきます。チャネルをまたぐ重複も同じ問題を反対側から見たものです。
"Same customer would email twice about one issue, once from their phone, once from a laptop an hour later when they got worried nobody saw the first one, and we'd end up with two agents responding separately without realizing it was the same problem."
まず、ヘルプデスクにすでにある機能をオンにしましょう。Zendeskの統合の提案は、同じ依頼者の前後2週間のチケットを表示し、Gorgiasの自動統合は同じ顧客のオープンなチケットを1つにまとめます。どちらの統合も元に戻せないので、慎重に設定してください。
引き継ぎについては、シフトの引き継ぎとチーム間エスカレーションの記事で、最初からやり直しになるのを防ぐメモを解説しています。
繰り返しのサポートチケットを減らす方法：2週間プラン
始めるのに新しいツールは必要ありません。私ならこのプランで進めます。
1週目：上位2つの原因を見つける
- 先月、同じ顧客が7日以内に戻ってきたチケットを50〜100件取り出します。再オープンだけでなく、フォローアップや分割されたチケットも含めてください。
- 1件ずつ読み、上の4つの原因のどれかでタグ付けします。5つ目に「その他」を設けて、小さく保ちます。
- 最初の連絡を誰が、あるいは何が対応したかを記録します。つまり、どの担当グループか、どのマクロか、ボットだったか、です。
- 数えます。ほとんどのチームでは、2つの原因がリピートの大半を占めます。
2週目：その2つを直して、測り直す
- 「待っている間の更新がない」には、主要なマクロに次の更新の一文を追加し、それを送る自動化を設定します。
- 「本当は直っていない」には、QAに解決確認を加え、クローズ件数だけを評価するのをやめます。
- 「回答が半分だけ」には、リピートが最も多い3つのマクロを書き直し、ヘルプセンターの穴を埋めてから、トーンガイドで文面を確認します。
- 「説明し直した」には、統合の提案か自動統合をオンにし、エスカレーション時に引き継ぎメモを必須にします。
- 自動クローズと再オープンの期間を確認します。Zendeskがまだデフォルトの4日のままなら、本当にそれでよいのかを意識的に決めてください。
- リピート問い合わせ率をベースラインと比較し、CSATやカスタマーエフォートスコアも併せて見ます。リピートが減ったのが、問題が直ったからで、顧客があきらめたからではないと確認するためです。
手作業で読みきれないほど量が多い場合は、完全なサポートチケット分析がステップ1をさらに深く扱っています。
AIが役立つ場面と、リピートを悪化させる場面
AIは繰り返しのチケットを減らせますが、大規模に生み出すこともできます。違いはすべて、推測を許すかどうかにかかっています。
失敗のパターンはこんな感じです。チャットボットがすべての質問にもっともらしい答えを返してチャットが終わり、ダッシュボードはデフレクションとして数え、その後で顧客が戻ってきます。
"How many customers finished a chat and come back 20 minutes later because the bot gave them a generic answer that didn't solve their issue? We're optimizing to close the ticket instead of solving the damn problem."
同じセッションではなく、1週間後に現れることもあります。Hacker Newsのある開発者は、モデルの選択と再オープンを突き合わせて初めて気づきました。
"our dashboard only tracked immediate task completion, and had no idea a cheaper model had quietly produced a worse answer that the customer reopened a week later."
そのため、キューにAIを任せる前に、私は3つのことを求めます。
- 自信があるときだけ答える。 自信満々の間違った返信は、返信しないより悪いです。リピートと怒った顧客の両方を生むからです。本物の信頼度スコアか同等のルールを探してください。月7,000件のチケットを扱うCXリーダーが通話でこう話していました。「I need an AI who is only handling the tickets that it's confident to handle and all the other ones, leave them alone.」これが正しい基準であり、AIのハルシネーションがほかのどれよりリピートで重要になる理由です。
- 本番前に過去のチケットでテストされている。 デモ用のシナリオではなく、すでに解決した実際のチケットで、自分のチームが実際に送った返信と照らして採点されていること。
- 対応者別にリピート率を分けられる。 AIが対応したチケットの方が担当者のものより戻ってくる頻度が高いなら、それが見える必要があります。AIが対応したチケットにはすべてタグを付けてください。
これが、私がeeselで挙げたい部分です。Simulationのスキルは、実際の過去チケットに対してエージェントを再生し、各回答をチームの返信と照らして採点し、指示の変更を提案します。解決済みのZendeskチケット20件で実行した例では、17件でチームと一致し、人の対応が必要な2件にフラグを立てました。
同じスキル一覧には、繰り返し出るトピックを調べる「Analyze ticket trends」と、ヘルプセンターが答えていない質問を見つけて足りない記事を下書きする「Update knowledge base」があります。これで根本原因の2と3は、ほぼ自動でカバーできます。間違えたときはチャットで直せば、その修正が恒常的な指示になり、同じ間違いが来週また同じリピートを生むことはありません。この流れはエラー分析の記事で説明しています。
ここでは料金の細かい点も重要です。eeselの料金ページでは、チケット1件は1クレジットで、「however many replies go back and forth」とされています。顧客がチケットを再オープンしても2つ目のクレジットはかかりませんが、まったく新しいリピートチケットはかかります。つまり、リピートを減らすと担当者の負担だけでなく、eeselの請求も下がります。
ただし、壊れた返金プロセスや荷物を紛失する配送パートナーの代わりにはなりません。根本原因がサポートの外にあるなら、AIはリピートに速く答えるだけです。
eeselで繰り返しのチケットを減らす
キューが同じ問題で再び連絡してくる顧客でいっぱいなら、eeselのAIヘルプデスクのチームメイトは、すでに使っているZendesk、Freshdesk、Gorgias、HubSpotの環境に加わり、過去のチケット、マクロ、ヘルプセンターから学びます。解決できるものにだけ答え、残りはチームに引き継ぎます。先月のチケットで再生すれば、顧客が返信を見る前に、どこでリピートを生んだかがわかります。Gridwiseのサポートリーダーは、1か月後の結果をこう語っています。
"In the first month, eesel is resolving 73% of our tier 1 requests ... Responses are simple to fix and adjust."
Kim Simpson, Gridwise
100クレジットで無料で始められ、有料プランは月$299から（500クレジット）です。
