要点
サポートの例外対応管理は3つの仕事です。誰がどのポリシーを曲げてよいかを決めること、すべての例外を同じ方法で記録すること、そして記録を見直して繰り返される例外をルールにすることです。ほとんどのチームは1つ目をゆるく行い、残りの2つを飛ばしています。だから同じ顧客が、ある担当者からは「はい」、次の担当者からは「いいえ」と言われてしまいます。
私が推したい考え方はこうです。ほとんどの場合に許可している例外は、すでにあなたのポリシーであり、ただ書かれていないだけです。それを見つける場所は社内メモではなく、ヘルプデスクで集計できる必須のドロップダウン項目です。ただし落とし穴もあります。Zendeskの「解決に必須」はトリガー、自動化、チケットの統合で回避でき、Gorgiasのチケット項目レポートはドロップダウン項目しか集計しません。
私は毎日eeselのサポートキューに向き合っていますが、例外こそ、担当者にもAIにも最も明確なルールが必要な領域です。ECサイトのZendeskの受信箱で行った実トラフィックの試験では、保証に関する問い合わせへのeeselの下書きの96.4%が担当者にとって有用でした。これこそeeselのAIチームメイトが担う役割です。書き出された例外を適用し、お金がかかるものは適切な担当者に回し、残りはメモを添えてチームに引き継ぎます。
サポートの例外とは何か
例外とは、担当者が書面のポリシーにないものを顧客に与えるあらゆる場面です。ごく小さなものもあれば、実際にお金がかかるものもありますが、共通点が1つあります。判断に依存するため、同じチケットでも担当者2人が違う結論を出しうることです。
キューで私が最もよく見る例外を、曲げられるポリシーとあわせて挙げます。
| 例外の種類 | 例 | 曲げられるポリシー | 一般的な責任者 |
|---|---|---|---|
| 期限後の返金・返品 | 30日の期限の41日目に返金 | 返品期限 | チームリード |
| 手数料の免除 | 再入庫手数料や延滞料を1回免除 | 手数料表 | 担当者(予算の範囲内) |
| お詫びのクレジット | 配送遅延後に10ドルのクレジット | なし(裁量による) | 担当者(予算の範囲内) |
| 保証の例外 | 保証が切れたばかりの商品を交換 | 保証条件 | チームリードまたはプロダクトオーナー |
| 返品不可商品の例外 | クリアランス品の返品を受け付ける | 返品不可ルール | マネージャー |
| サービスまたはSLAのクレジット | B2Bプランでの停止に対するクレジット | 契約条件 | アカウントマネージャーまたは経理 |
最後の列は見た目以上に重要です。多くのチームには返金承認マトリクスか、少なくとも返金の金額上限があります。しかし表のそれ以外の項目では同じ明確さを持つチームはごくわずかで、手数料の免除やお詫びのクレジットが気分で決まってしまいます。
管理されていない例外が、例外そのものより高くつく理由
例外のコストは10ドルのクレジットだけではありません。例外が一貫性を欠き、見えず、見直せないことで起きる損失です。
顧客は別の担当者を探すことを覚えます。 答えが誰に当たるかで変わるなら、賢い行動はもう一度聞くことです。実際にこう語る人がいます。
"I've learned to play customer service roulette.
Don't get the answer I'm looking for?
Hang up and call back."
例外は別のカテゴリーの中に隠れます。 担当者が公認の方法で何かを許可できないと、非公認の方法を見つけます。あるコメント投稿者は、銀行やカード会社でのやり方をこう説明しました。
"If you're not yelling at them, you can often get what you want via some other method (which only they know) - like them reclassifying the problem to something else they have leeway for."
その再分類されたチケットは、レポート上では本来とは違うものとして現れます。チケットのタグ付けは誤ったものになり、例外は見えなくなります。
約束された例外は消えます。 最悪なのは、合意されたのに記録されなかった例外です。r/Comcast_Xfinityのある顧客は、電話でサポートと解決策をまとめたと書いています。"they said they would note this on my account. I reached back out after a week to confirm the notes on the account an there is no record of the solution offered"(cali1302, Reddit)。次の担当者は、見えない約束を守るか、顧客を嘘つき扱いするかの二択を迫られます。
小さな拒否が大きな前例になります。 最もよく知られた例はAir Canadaのチャットボットの件で、拒否された忌引き返金が審判所にまで持ち込まれました。Hacker Newsのコメント投稿者はこうまとめています。これは "should've been well within some second-tier customer service manager's discretionary refund budget. Instead they've got a precedent-setting ruling that makes the chatbot a huge liability"(ceejayoz, Hacker News)。
サポートの例外対応管理のサイクル
すべての例外は、同じ5つのステップを通るべきです。ほとんどのチームが飛ばすのは最後の矢印、つまり月次レビューから書面のポリシーに戻る部分です。これがないと、同じ例外を毎月40回許可し続けても、それがルールになるべきだと気づけません。
このガイドの残りは、このサイクルを順に説明します。誰が決めるか、どう記録するか、単発の例外にすでに対応しているツールは何か、どう見直すか、そしてAIエージェントに人と同じルールをどう与えるかです。
ステップ1:誰が何を許可できるかを決める
まず例外を2つの問いで分類します。誰の責任か、そしていくらかかるかです。この2つの答えは、単一の金額上限よりもはるかによく、誰が決めるべきかを教えてくれます。
左下の枠を、多くの人が間違えます。自社の都合で配送が遅れ、対処のコストが承認にかかる時間より安いなら、それは例外ですらないはずです。小売店の従業員が人件費の観点でうまく言い表しています。
"Especially on clothes that have a ridiculously high margin, it's costs more money in payroll wasting that time than just giving them a BOGO."
それ以外については、各ロールに書面の裁量予算を与えます。銀行はすでにそう運用しています。あるコメント投稿者の言葉では、"most banks/credit cards let the first-level hit the 'refund one fee' button, and the higher up you get, the more discretion they have"(bombcar, Hacker News)。予算には3つのことを書きます。
- そのロールが単独で許可できること。 例:顧客1人につき年1回の手数料免除、15ドルまでのお詫びクレジット、期限から7日以内の返品。
- まったく許可できないこと。 返品不可商品の例外、契約上のクレジット、未解決のチャージバックが絡むもの。
- 残りは誰に聞くか。 「リーダー用チャンネル」ではなく、指名された1人と代理の1人。ルーティングをおさらいしたい場合は、私のチケットエスカレーションプロセスのガイドが役立ちます。
もう1つ書き残したいのは、その例外が何のためにあるかです。それがないと、裁量は最も強く押す人に流れていきます。r/talesfromcallcenters のある担当者は、"pick to be nice to rude people and give hard stops to really nice people" という上司たちについて書いています(Asha990, Reddit)。「お詫びのクレジットは当社側のサービス不備に対するもので、粘り強さへの対価ではない」という一文があれば、揉め事の多くは始まる前に収まります。
ステップ2:例外はメモではなく項目に記録する
ここが、ほとんどの例外ガイドが飛ばす部分です。チケットのメモ(「1回限りのお詫び返金を実施」)は何もないよりましですが、メモは数えられません。例外を見直すには構造化されたデータが必要で、ヘルプデスクではそれがカスタムチケット項目を意味します。
私が設定する形は4つの項目で、そのうち3つは最初の項目が「はい」のときだけ表示します。
- 例外を許可: 「いいえ」と「はい」のドロップダウン。チケットをクローズするときに必須にします。
- 例外の種類: 上の表の種類を選択肢にしたドロップダウン。
- 例外の理由: 理由(配送業者の遅延、商品の破損、自社のミス、顧客の事情)に「その他」を加えたドロップダウン。
- 金額と承認者: コスト用の数値項目と、承認者名のドロップダウン。
ドロップダウンが自由記述に勝つ理由は単純です。Zendesk自身のドキュメントによれば、テキスト項目の値は「一貫性を欠いたり、スペルミスを含んだりする可能性があり」、そのため「レポート用途にはあまり役立たない」とされています(Zendesk)。Freshdeskの助言も同じで、"favor dropdowns over text fields where possible" と述べています(Freshdesk)。
各ヘルプデスクが対応していること
主要なヘルプデスクはどれも何らかの形でこれを実現できますが、プランによる制限や上限は大きく異なります。現時点でドキュメントに書かれている内容は次のとおりです。
| ヘルプデスク | カスタムのドロップダウン項目 | 「はい」のときだけ項目を表示 | クローズ時に必須 | 項目のレポート |
|---|---|---|---|---|
| Zendesk | 全プラン、最大2,000値 | Suite Growth以上 | 「Required to solve」、全プラン | Explore、Suite Professional以上 |
| Freshdesk | Growth以上(Freeは不可) | 依存項目はGrowth以上、動的セクションはPro以上 | 「Required when closing」、Growth以上 | カスタムレポート、Pro以上 |
| Gorgias | 全プラン、有効な項目25個まで | 全プラン、条件は最大70 | 全プラン | チケット項目レポート、全プラン、ドロップダウンのみ |
| HubSpot Service Hub | 全プラン、最大5,000選択肢 | Professional以上 | パイプラインのステージ必須プロパティ | カスタムレポート、Professional以上 |
| Help Scout | PlusとPro、受信箱ごとに10項目 | 記載なし | 返信時に必須、クローズ時は不可 | PlusとPro |
Zendeskでは、「はい」のときだけ表示する部分は条件付き項目です。条件エディタでは依存項目をステータスごとに必須にもできるため、チケットが解決されたときに初めて「例外の種類」を必須にすることができます。
Gorgiasも、Helpdeskの全プランで項目の条件によって同じことができます。
細則にある4つの落とし穴
設定から6週間後に、例外ログをいつの間にか壊してしまう細部です。
- Zendeskの必須項目には抜け穴があります。 設定はすべての項目にありますが、Zendeskのドキュメントによれば、必須項目は「トリガーや自動化で回避でき」、「エージェントがチケットを統合した場合も回避されます」(Zendesk)。推奨される回避策は、クローズ用の自動化が待機する
okay_to_closeタグです。 - Gorgiasはドロップダウンしかレポートしません。 チケット項目レポートは「ドロップダウン型のカスタムチケット項目のみを追跡する」ため、数値、テキスト、はい/いいえの項目は表示されません(Gorgias)。「例外を許可」ははい/いいえ項目ではなくドロップダウンにしましょう。またGorgiasは、そのAI Agentが「必須のチケット項目が未入力でもチケットをクローズできる」と注記しています(Gorgias)。
- Help Scoutはクローズ時ではなく返信時にチェックします。 必須のカスタム項目は「返信を送信するとき」に入力する必要があり、会話を別の受信箱に移すと項目のデータは引き継がれません(Help Scout)。
- 項目を削除すると履歴も消えます。 Freshdeskによれば、項目を削除すると「Analyticsで非表示になり」、Help Scoutによれば、削除するとそのデータが「永久に」消えます。古い例外の種類は削除せず、アーカイブしましょう。
Suite Professional以上のZendeskチームへのおまけです。ExploreのUpdates historyデータセットは、項目値の変更を時系列で追跡でき(Zendesk)、「誰がいつこれをはいに変えたか」に答えられます。Exploreのカスタム項目レシピで、このレポートの作り方を説明しています。
ステップ3:単発の例外にすでに対応しているツールを使う
例外はヘルプデスクに記録されます。しかし実際の操作は、返品アプリ、ストアの管理画面、請求システムなど別のツールで行われることがよくあります。これらの多くには例外のための仕組みが組み込まれており、担当者がルールを回避するより、それを使うほうが望ましいです。
| ツール | 単発の例外の仕組み | 記録されるもの |
|---|---|---|
| Loop Returns | 注文やメールを許可リストに入れて、返品期限、返品不可、ブロックリストを上書き | リストの項目、CSVでエクスポート可能 |
| Redo | 拒否された返品をPolicy WindowまたはFinal Sale Checkの段階でリセット | 返品の処理履歴 |
| Shopify | スタッフが管理画面で返品を作成し、返品ごとに手数料を編集 | 拒否の理由は社内のみ |
| AfterShip Returns | 注文、商品タイプ、メール、タグ単位の許可リスト | 最大20個のあらかじめ設定した拒否理由 |
| Stripe Billing | 社内メモ付きのクレジット残高の調整 | 「変更不可のリスト」としての取引 |
Loopが最も分かりやすいモデルです。 そのListings機能は「返品の例外と制限を管理する」ために存在し、注文を許可リストに入れると「既存のブロックリストの項目、Final Saleのタグが付いた商品、注文の返品期限のいずれも上書きされます」(Loop)。さらに私が気に入っているのはLoop自身のベストプラクティスです。注文を許可リストに入れ、顧客に代わって返品を申請し、すぐに許可リストの項目を削除します。自分で後片付けをする一時的な例外は、まさに望ましい形です。Loopは期限切れの購入者にも "contact your support team directly for any exceptions" と案内しているため(Loop)、想定していてもいなくても、そうしたチケットはあなたのキューに届きます。
Loop Workflowsは繰り返される例外をルールに変えます。 ステップ4のレビューで例外をポリシーにすべきだと分かったら、Workflowsで自動適用できます。Bypass final sale、Set return window、Set handling feeといったアクションで、既存の手数料を「上書き、追加、または免除」できます(Loop Workflows)。詳しくは返品の自動化のガイドで触れています。
Shopifyのルールは、すでに分かっている例外を載せられます。 返品期限の上書きで、クリアランス品は14日、家具は90日にでき、返品不可商品は「デフォルトの返品ルールの例外」と説明されています(Shopify)。Shopifyのドキュメントで見つけられなかったのは、ルールが不可と言う場合に特定の注文だけを対象にするスイッチです。文書化されている方法は、スタッフが管理画面で返品を作成することで、そこでは返品ごとに手数料を編集できます。
Stripeのクレジット残高は、監査証跡が組み込まれたお詫びのクレジットです。 顧客の残高はすべて「借方と貸方の取引の変更不可のリストである台帳から計算」されます(Stripe)。各調整には顧客に見えない社内メモを付けられ、項目は削除できず取り消しのみ可能です。あなたのSaaS製品のお詫びのクレジットがほかの場所にあるなら、必要以上に監査しにくくなっています。
ステップ4:ログを見直し、繰り返される例外を昇格させる
ここで例外対応管理は元が取れます。月に1回、「例外を許可」が「はい」のチケットをすべて抽出し、種類と理由でグループ化します。グループごとに問うのは1つだけです。これは本当の例外か、それとも書かれていないルールか。
顧客の側から見ると、見直されていない例外は無作為に見えます。あるコメント投稿者は、上司から救済を受けたあとでこう書きました。"There's no particular rhyme or reason for why extraordinary relief is sometimes granted though, it seems completely random!"(gnicholas, Hacker News)。チームの側から見ればもっと悪く、毎回同じ結論を出す判断に承認者の時間を使っています。
先月の例外を1つ選び、その数字をここに入力してみてください。
ウィジェットのしきい値(月10件の依頼、80%の許可)は私の出発点であり、業界標準ではありません。ご自身のボリュームに合わせて調整してください。重要なのは、レビューが次の4つの判断のどれかで終わり、その判断が何かを変えることです。
- ポリシーにする。 書面のポリシーとヘルプセンターを更新し、マクロを更新し、担当者とAIエージェントに同じ日に周知します。展開の進め方はサポートのポリシー変更管理のガイドで扱っています。
- 担当者の裁量のままにする。 予算内に残しますが、記録は続けます。
- 指名した承認者に回す。 コストが高い、または第二の目で確認したいパターン。
- 「断り方」を定型化する。 ある依頼を80%断っているなら、20%の「はい」が顧客に頼み続けることを教えてしまいます。小売店の従業員の言葉では、"They are getting something out of it, so it continues"(Cheshire1871, Reddit)。
このレビューは、ほかの2つのループにもつながります。例外率がチームの平均から大きく外れている担当者はコーチングの対象で、ここでサポートQAのキャリブレーションやエージェントへのフィードバックが役立ちます。また、配送業者の遅延のような特定の理由の急増は、サポートチームが静かに負担している運用上の問題です。ほかのサポートチケット分析とあわせて共有しましょう。
ステップ5:AIエージェントに書面の例外ルールを与える
AIエージェントによって、例外対応管理はより緊急になります。人は場の空気を読んで、ルールをそっと曲げられます。AIエージェントは書かれたルールに従うか、即興で動くかのどちらかで、どちらの失敗も公の場に現れます。
最初の心配は、顧客がAIを説得して例外を認めさせることです。
"People will find out how to convince the LLM you do meet the requirements for a refund.
And if you check the requirements using something deterministic (last order was within last 2 weeks, customer has a high loyalty points score, they're subscribed to some premium service) then why do you need an agent at all?"
逆の失敗も同じくらい深刻です。例外を認められず、認められる人にも顧客をつながないボットです。ある顧客は、請求期間の終わりでの解約を提案し続けるAIサポートチャットについて、こう書いています。"I ask for human. It repeats. I ask for human again. It repeats. I disconnect"(kldg, Hacker News)。
どちらへの答えも、人に対するものと同じです。AIが適用してよい例外を平易なルールとして書き、お金が動くものには厳格な境界を設け、それ以外の例外の依頼はすべて文脈つきで人に届くようにします。これはポリシーに適用したAIガードレールであり、AIエスカレーションの経路はその半分です。
主要なヘルプデスクのAIツールは、いまやこの形に対応しています。
| AIツール | 例外ルールの書き方 | それ以外はどうなるか |
|---|---|---|
| Zendesk AI agents | 「クリアランス品は返金不可」のようなポリシーの文脈を持つGenerative proceduresと、顧客タイプ別のセグメント | 「Escalate to」ステップが人またはチームに引き継ぎ、AIは停止する |
| Gorgias AI Agent | 「返品商品が届くまで返金を約束しない」のような境界を持つSkills | 平易な言葉で書く引き継ぎトピックと、「無効にできない」組み込みのトリガー |
| eesel | 「例外とエッジケース」テンプレート付きの、平易な言葉の指示 | 社内メモを添えてエスカレーション。お金に関わる操作は承認を待つ |
ZendeskのProcedureビルダーは、AIにとって「例外を書き出す」とはどういうことかをよく示しています。ポリシーを平易な言葉で書くと、元に戻せない操作の前にチェックを挟んだ分岐マップが作られます(Zendesk)。
Zendeskのドキュメントは限界についても率直で、Procedure内のコンテキストは「AIの正確な挙動を保証できない」とし、分岐が必要なものにはCheck conditionブロックを使うべきだとしています(Zendesk)。これは正しい考え方です。文言はAIを導きますが、お金に関する厳格な上限はアクション設定に置くべきです。
eeselで例外ルールを書くなら
eeselでは、新しいメンバーに説明するのと同じように、例外をエージェントの指示に平易な言葉で書きます。ドキュメントには「Cover exceptions and edge cases」のテンプレートがあり、「50ドル未満の破損の申告:写真の依頼を省き、返金を承認する」「直近1時間以内の注文:キャンセルに承認は不要」といった行や、VIPタグの付いた顧客は必ずエスカレーションするというルールが含まれています(eeselドキュメント)。エスカレーションのテンプレートがもう半分を担い、「顧客が望んでいること、あなたが調べたこと、あなたならどう返信したか」を社内メモに残し、人に割り当てます。
人を指導するのと同じように、エージェントを修正することもできます。私が一緒に仕事をしたサポート管理者は、実は例外ポリシーである次のルールをエージェントに教えました。未解決の問題が付随するキャンセルや返金の依頼には、まずトラブルシューティングを行うというものです。
"I have a rule in CS where we do not address a cancel or refund request when there is an issue attached to it."
「キャンセル前にトラブルシューティング」というポリシーをエージェントに組み込んだサポート管理者
お金がかかるものについては、アクション設定が強制力を持ちます。各アクションにはエージェントごとに3つの設定があります。Auto、Needs approval、Disabledです(eeselドキュメント)。アクションをAutoのままにしつつ、特定の状況では先に確認するようエージェントに伝えることもでき、これが書面の例外ポリシーを実際の関門にする方法です。承認が必要なとき、承認者には正確なアクションと金額が表示され、承認はタイムアウト後に自動で実行されることはありません。
Activityページには、誰がいつ何を承認したかが記録され、AIが関与したすべてのものの例外ログとして機能します。
例外対応管理でよくある間違い
コストが大きい順に、おおよそこの順番で直すことをおすすめします。
- 例外をメモに記録する。 メモは数えられません。必須のドロップダウンを使い、Gorgiasではそれがはい/いいえ項目ではなくドロップダウンであることを確認してください。
- 裁量の予算がない。 なければ担当者ごとに独自の基準を作り、顧客は2人目の担当者に聞くことを覚えます。各ロールが許可できることを書き出しましょう。
- 自社の責任による例外を好意のように扱う。 毎回許可している配送遅延のクレジットはルールにすべきです。顧客に頼ませるとチケットが増え、CSATが下がるだけです。
- ループを閉じない。 月次レビューがポリシー、ヘルプセンター、マクロのいずれも変えないなら、それはただのレポートです。すべての例外の種類が、レビューを判断で終えるべきです。
- AIに即興をさせる。 書面の例外ルールがないAIエージェントは、すべてを断るか、誤ったものを許可します。ルール、お金の境界、そして整ったエスカレーション経路を与えましょう。
- 古い項目を削除する。 使わなくなった例外の種類はアーカイブし、昨年のデータもレポートに表示されるようにしましょう。
eeselでサポートの例外に対応する
チームがZendesk、Gorgias、またはFreshdeskを使っているなら、eeselのAIヘルプデスクのチームメイトは、例外ルールを定着させる最も直接的な方法です。既存のキューに加わり、過去のチケット、ヘルプセンター、マクロから学び、あなたが平易な言葉で書いた例外に従います。お金がかかるものは、ダッシュボードまたはSlackで適切な人の承認を待ち、ルールの範囲外のものは、顧客が望んでいることと調べた内容を説明するメモを添えてチームに渡されます。
実際の例外を扱わせる前に、過去のチケットでシミュレーションを実行し、その回答をチームが実際に送った内容と比較できます。料金はチケット単位でシート数は無制限なので、すべての承認者がアクセスでき、100の無料クレジットからカード不要で始められます。eeselを試す。