サポートの返金承認マトリクスとは（そして、上限がひとつでは足りない理由）
多くのチームは1つのルールから始めます。「担当者はX$まで返金できる。それ以上はマネージャーへ」。これは、今四半期にすでに6回返金を求めた顧客への20$の返金や、明らかに倉庫側のミスで1分で通すべき400$の返金が来るまでは機能します。
マトリクスは2つ目の軸を加えることでこれを解決します。金額が最初の承認者を決め、リスクシグナルがそれを上げたり下げたりします。重要な順に、私なら次の項目を入れます。
| 項目 | 重要な理由 | 承認者の動き |
|---|---|---|
| 返金額 | 誤って承認したときのコスト | 開始する金額帯を決める |
| ポリシーの内か外か | 返品期限、最終セール品、損傷の証拠 | ポリシー外は1段階上げる |
| 顧客の返金履歴 | 返金を繰り返す顧客に不正が潜む | 返金を繰り返す顧客は1段階上げる |
| 返金方法 | ストアクレジットや交換品ならお金が自社に残る | クレジットや交換品は1段階下げられる |
| 紛争・チャージバックが開いている | 今返金すると二重払いになりうる | 常に紛争担当者へ |
最後の行は理論上の話ではありません。Stripeは受けた紛争1件につき15.00ドルの紛争手数料を請求し、異議を申し立てるとさらに15.00ドルかかります。PayPalのチャージバック手数料は米国で20.00ドルです。また、どちらの決済事業者も、返金しても元の取引手数料は戻しません。Stripeは返金に関するドキュメントで、元の取引の「処理手数料は返金されません」と述べています。
Shopifyのストアオーナーは、チャージバックのルールを痛い目にあって学びます。
「返金した後にチャージバックを受けて痛い目にあったストアオーナーを知っています。3倍の損失になります（注文、返金、チャージバック）。返金したからといって、チャージバックが終わる、あるいは防げるという保証はありません。チャージバックが進行中なら、絶対に返金してはいけません。」
例のしきい値を入れた記入済みのマトリクスは次のようになります。数字は出発点であり、すべての事業への推奨ではありません。宝飾ブランドと12$のスマホケース店では、必要な金額帯がまったく異なります。
自分の返金承認マトリクスを作る
自社の上限を入力し、今週対応した返金でテストしてみてください。入力に合わせてマトリクスが描き直され、右側のパネルにテストケースを誰が承認すべきかとその理由が表示されます。
金額のしきい値の決め方
しきい値の目的は、悪い返金を止めることではありません。確認のコストが、間違えたときのコストより低くなるようにすることです。マネージャーが12$の返金に10分を費やせば、その確認は返金より高くつき、顧客はそのために電話口で待たされています。
顧客はそれに気づきます。あるHacker Newsのコメント投稿者は、担当者がごくわずかな金額しか承認できない会社について書いています。
「カスタマーサービスの担当者は、承認できるのは1$の返金だけだと文字どおり私に言ってきました。2$は「多すぎ」で、あらゆるマネージャー承認が必要で、しかもマネージャーが捕まることはありませんでした...」
もう一方の極には、サポートで最もよく引用される権限委譲のルールがあり、この議論が出るたびに話題になります。
「[...] リッツ・カールトンは、官僚的な手続きなしにゲストのために問題を解決できるよう、従業員1人につき2,000$の裁量支出を与えていることで有名です。良い人材を採用し、良い人材を信頼し、良い人材に権限を与えましょう。」
多くのチームはその中間に落ち着き、大規模なコンタクトセンターは階層を積み重ねる傾向があります。r/verizonのあるコメント投稿者は上限をこう説明しています。「スーパーバイザーは約300$までのクレジットを承認でき、残りはマネージャーに上がります」（Reddit）。
文章にすると、マトリクスは驚くほど短くなることがあります。あるHacker Newsのコメント投稿者は、返金ポリシー全体を3つの条件で描きました。
「たとえば、どの顧客も、価値が200$未満であれば最初の2回の返品は何も聞かずに認められ、価値が50$未満であれば全額返金を1回認め、アカウント全体の返品率が15%未満であれば200$未満の返品はすべて受け付ける。これらのどれも満たさなければ、エスカレーションする。」
各金額帯の数字は次のように選びます。
- 自動の金額帯。 ほぼすべてを承認している返金額から始めます。前四半期の返金を抽出し、マネージャーが95%を超える確率で承認した金額を見つけ、自動のラインをその少し下に置きます。この金額帯は厳密にポリシー内に限定してください。
- 担当者の金額帯。 平均注文額の1〜3件分がよくある着地点です。担当者は、誰も保留にせずに通常の問題のある注文を解決できるべきです。
- チームリーダーの金額帯。 「ポリシー外だが妥当」という判断がここにあります。リーダーは返品ポリシーを十分に理解しているため、一度だけなら柔軟に運用できます。
- マネージャーと経理の金額帯。 高額な返金、BtoBのクレジット、契約に関わるものすべて。「誰かが対応するだろう」で止まらないよう、グループではなく金額帯ごとに1人を指名します。
もう1つの確認：しきい値が忙しい週にも耐えられることを確かめましょう。 250$から1,000$の承認者がリーダー1人だけで、その人が不在なら、その金額帯の返金がすべて止まります。サポートのオーバーフローを計画するのと同じように、各金額帯に名前のある代理を置いてください。
ヘルプデスクでマトリクスを強制できる範囲（とできない範囲）
多くの返金マトリクスのテンプレートはここで終わり、本当の作業はここから始まります。eeselのキューでよく見るヘルプデスクについて、返金と権限のドキュメントを調べました。担当者ごとの金額上限を記載しているものはありません。提供されているのはスイッチです。
| ヘルプデスク | チケットからの返金 | 返金できる人 | 担当者ごとの金額上限 | 承認ステップ |
|---|---|---|---|---|
| Zendesk | Shopifyアプリ経由で全額または一部（全Suiteプラン） | ドキュメント上は担当者ごとの設定なし | 記載なし | Suite Professional以上で承認リクエスト |
| Freshdesk | Shopifyウィジェットから全額または一部（Growth以上） | 全担当者に共通の管理者設定が1つ | 記載なし | 承認ワークフローはナレッジ記事のみ |
| Gorgias | マクロとサイドバーからShopifyの返金とキャンセル | Basic、Lead、Adminロール。ObserverとLiteは不可 | 記載なし | 人向けにはなし |
| Gladly | 注文カードの返金アクション、全額のみ | 「All Agents can perform all Actions」 | なし | 人向けにはなし |
| Kustomer | 全額、一部、または手動の金額 | 権限セット内のShopifyアクション | 記載なし | 高額返金はAIが人に引き継ぐ |
| eDesk | 商品ごとの返金、元の金額を超えられない | 「Shopify Refunds」ロール権限 | 記載なし | AIの手順はデフォルトでエスカレーション |
この表のいくつかの点は、見た目以上に重要です。
Shopifyの権限は、返金がヘルプデスクに移っても引き継がれません。 Shopifyは返金を、元の支払い方法とストアクレジットで別々のスタッフ権限に分けており、これは素晴らしい点です。しかし変更履歴には、返金権限は「Shopify管理画面とモバイルアプリで適用されますが、ユーザーが注文を返金できるほかのShopifyアプリやサードパーティアプリでは適用されません」とあります。担当者がGorgiasやZendeskから返金できるなら、ヘルプデスク自体のロール設定が唯一の関門です。
Gladlyは全担当者にボタンを与えます。 Shopifyアクションのドキュメントには「All Agents can perform all Actions」とあり、注文カードの返金は送料を含めて常に全額を返金します（Gladly）。Gladlyを使っているなら、マトリクスは設定ではなく研修と品質管理の中にあります。
eDeskは便利なブレーキを加えます。 返金は「元の金額を超えることはできず」、金額が元と異なる場合、担当者は相違理由（Discrepancy Reason）を選ばなければなりません（eDesk）。この理由欄は、どこにでも欲しい監査証跡です。
Zendeskは、本物の承認オブジェクトに最も近い存在です。Customer Service Suite Professional以上では、担当者がチケットに承認リクエストを出せ、Zendesk自身の例は担当者のチームリーダーに返金が回るというものです。細部は返金マトリクスに向いています。1リクエストにつき最大5人の承認者、承認者は依頼者や担当者にはなれず、承認が保留中のチケットはクローズできません（Zendesk）。できないのは、金額に基づいて承認者を自動で選ぶことです。担当者が引き続きマトリクスを読んで選びます。
そのため実際には、マトリクスのヘルプデスク側は3つの設定に集約されます。そもそも誰に返金権限があるか（サポート担当者のアクセス制御に関する私のメモを参照）、担当者に理由を記録させるマクロまたはフォーム、そしてレポートに使えるチケットタグです。
Zendeskは、担当者がShopifyアプリから返金するとshopify_refundタグを自動で付与します（Zendesk）。これにより四半期レビューが楽になります。
決済レイヤーで金額のラインを強制する
人がクリックで超えられない厳格な上限が必要なら、お金が動く場所に置く必要があります。各決済・コマースツールが実際に強制できる内容は次のとおりです。
| ツール | 返金できる人 | 金額しきい値の強制 | 組み込みの承認 | 返金期限 |
|---|---|---|---|---|
| Stripe | Refund Analyst、Support Associate、Support Specialistなどのロール | あり。「Refund is created」の金額条件（パブリックプレビュー） | 承認必須またはブロック。リクエストは14日で期限切れ | カードの期限は返金ドキュメントに記載なし |
| PayPal | オーナーが権限を設定した最大200人のセカンダリユーザー | 記載なし | 記載なし | 180日、全額または一部 |
| Shopify管理画面 | 元の支払いとストアクレジットで別々の権限 | なし、オンとオフのみ | スタッフが返品リクエストを承認または拒否。POS Proならマネージャーの暗証番号を必須にできる | 販売者が14、30、90日またはカスタム日数を設定 |
| Loop Returns | 販売者のチーム | あり。返品額または注文額のルール | Manual Reviewアクション | 販売者が設定 |
Stripeが際立っています。 二者承認では、管理者が「Refund is created」に金額条件付きのルールを追加でき、承認は「金額がしきい値を超えた場合のみ」発動します。制御はRequire approval（審査者が承認するまで返金を一時停止）かBlockのどちらかです。「A user can't approve their own request」で、14日間放置されたリクエストは期限切れになり、特定のアクションに適用できるアクティブなルールは1つだけです。そのため、階層はルールを連ねるのではなく、条件を組み合わせて表現します。Stripeはエージェントタグ付きのAPIキーで作成された返金に対するデフォルトの承認ルールも提供しており、決済会社がAIとお金をどう考えているかがわかります。
Shopifyはダイヤルではなくスイッチです。 ストア権限には「Refund to original payment method」と「Refund to store credit」が別々の権限として並んでいますが、どちらの説明にも金額上限はありません。それでもこの分離は役に立ちます。新しい担当者にはストアクレジットへの返金だけを許可できます。また、Shopifyでは「you can't cancel or reverse a refund after you initiate a refund」（Shopify）なので、誤った承認は取り消せません。
返品アプリは金額によるルーティングを担えます。 Loopのワークフローは、返品合計、注文合計、顧客タグ、返品理由で振り分け、リクエストをManual Reviewに送れます。Loop自身の例では、300$を超える返品を手動レビューに送り、倉庫が高額商品を先に検品します。
返品が返金の大半を占めるなら、マトリクスの上位はここに置くのが適切で、以前取り上げた返品ツールとも相性が良いです。そのフローの残りは返品自動化ガイドで扱っています。
承認がボトルネックにならないようにする
承認が滞ると、承認マトリクスは静かに破綻します。顧客には組織図は見えず、保留中であることだけが見えます。
「返金の承認を得るために上司に確認する必要がありました。注文全体が、私自身が承認できる額をわずかに超えていたからです。少しだけ保留にすると伝えました。上司が少し時間を要したので、待っていました。」
しきい値が低すぎると、承認者も不満を抱きます。
「[...] 37セントの返金のために店長の承認を15分も待つ必要はないし、そもそも店長がそれに関わる必要すらない。そんな些細なことに対応するのは、店長の時間と給料の無駄だ。」
マトリクスを速く保つ方法は次のとおりです。
- 承認を、承認者がすでに働いている場所に置く。 Zendeskは2026年5月にSlackでの承認を追加し、承認者はそこでコメントも残せるようになりました。誰も開かない受信トレイにある承認は、決して実行されない返金です。
- 各金額帯に承認の時間目標を設ける。 Zendeskには承認リクエスト用のネイティブなリマインダーがないため、数時間後に保留中の承認にフラグを立てるビューまたは自動化を設定しましょう。
- 背景情報は一度だけ書く。 承認者には、注文、金額、違反しているポリシーの行、担当者の推奨が見えるべきです。Zendeskはリクエストの説明を2,500文字に制限していますが、テンプレートを使えば十分です。
- 依頼者に承認させない。 Zendeskは担当者の承認をブロックし、Stripeは自己承認をブロックし、HubSpotも見積もりで同様です。使っているツールにその機能がなければ、ルールにしてください。
- 期限切れの意味を決める。 Stripeはリクエストを14日で期限切れにします。期限切れの承認を「却下」とするか、1段階上に回すかを事前に決め、顧客にどちらだったかを伝えましょう。
AIエージェントにもマトリクスの行を与える
これは、すでに返金リクエストにAIを使っているチームでも、ほとんどの返金ポリシーがまだ追いついていない部分です。AIエージェントが注文に触れられるなら、マトリクスに専用の金額帯が必要で、その範囲は新入社員より狭くすべきです。
これについて私が読んだ最良の考え方は、AIエージェントに承認なしで何をさせているかを巡るスレッドから来ました。
「私が最終的に引いた線は、アクションがどれだけ危険かではなく、元に戻せるかどうかでした。お金は簡単だとわかりました。返金すればいいのです。[...] 悪い返金は悪い午後で済みます。悪いメッセージは誰かの受信トレイに永遠に残り、それを取り消すボタンはありません。」
可逆性のテストには賛成ですが、1つ注意があります。ShopifyとPayPalでは、送信した返金は取り消せません。つまり返金における「元に戻す」は「コストを負担する」という意味であり、まさにそのために金額帯があります。Hacker Newsの別のコメント投稿者は、多くのチームが最終的に求める構成を述べています。AIが「推奨案を用意し、人が立ち寄って承認または却下する」というものです（lubujackson, Hacker News）。
AIによる返金の判断は、必ず3つのうちのどこかに行き着くべきです。これはお金に適用したヒューマン・イン・ザ・ループの設計であり、ほかのどれよりも先に設定するAIガードレールです。
ベンダーはこのパターンに収束しており、使う手段はそれぞれ異なります。
| AIツール | 返金の実行方法 | ガードレールの位置 |
|---|---|---|
| Zendesk Copilot auto assist | 担当者が承認した後に、Shopifyの注文をキャンセルして返金 | Zendeskは返金アクションに「should be marked as agent-approved」と述べている |
| Gorgias AI Agent | キャンセル、商品の削除、商品の交換の一部として返金 | 注文合計に対するアクション条件。取り消せないアクションでは顧客の確認がデフォルトで有効 |
| Richpanel | Refund Orderツール | ツールごとの「Require approval」。返金は注文合計とポリシーで制限 |
| Kustomer AI Agent | 返金と返品 | 設定した金額を超えると人が承認し、その後AIが会話を完了 |
| Gladly AI | 全額または一部の返金 | 金額を先に表示し、顧客に確認する |
| eDesk AI Agent | 手順内の「Approve Refund」という結果 | デフォルトの結果は人へのエスカレーション |
このうち2つはより詳しく見る価値があります。Zendeskのアクションに関するドキュメントは、事前承認されたアクションが「may be executed in a different order than specified」であると警告しており、これが返金を事前承認すべきでない、文書化された理由です。またGorgiasの顧客確認は買い物客からの確認であり、マネージャーからのものではありません。誤ったキャンセルは防げますが、社内の承認ではありません。さらにGorgiasの料金ページによると、Gorgias AI AgentのアクションはStarterプランに含まれず、自動化された1件のやり取りはプランに応じて0.85ドルから1.00ドルかかります。Gorgias AI Agentの料金の内訳に全体の表があります。
引き継ぎで私がまねしたいのはKustomerの方式です。人が返金を承認し、AI向けにメモを残し、AIが顧客に伝えて会話を閉じます。
eeselでAIの金額帯をどう書くか
eeselでは、AIチームメイトが実行できるすべてのアクションに、エージェントごとに3つの設定があります。Auto、Needs approval、Disabledです（eeselのドキュメント）。Shopify連携には書き込みアクションとしてRefund OrderとCancel Orderが含まれ、自動化を作成して有効にするまで、ストアには何も変更が加わりません（Shopify連携）。
マトリクス自体は、エージェントの指示に平易な言葉で書き込みます。ドキュメントには「The conversation involves a refund over $100」を含むエスカレーションのテンプレートと、「Damage claims under $50: skip the photo request, approve the refund」のような行を含む例外のテンプレートがあります（指示のドキュメント）。一緒に仕事をしたあるサポート管理者は、どの金額帯よりも優先されるルールをエージェントに教えました。
「CSには、問題が紐づいているキャンセルや返金のリクエストには対応しない、というルールがあります。」
「キャンセルする前にトラブルシューティングする」というポリシーをエージェントに組み込んだサポート管理者
返金に承認が必要なとき、承認者には正確なアクションと金額を示すカードが届き、Approve、Always allow、Denyが選べます。承認はタイムアウト後に勝手に実行されることはなく、Activityページに誰がいつ判断したかが記録されます。
Slackから承認したい場合は、同じリクエストがスレッドにApprove、Deny、Reviewボタン付きで表示され、承認が承認者の1日の流れの中に収まります。詳しくはAIエスカレーションのガイドをご覧ください。
返金マトリクスのよくある間違い
キューで最もよく見るもので、おおよそコストの大きい順です。
- 金額のラインが1本だけで、リスクの列がない。 上限が1つだけだと、最も頻繁に返金する顧客への20$の返金は承認され、明らかに自社の責任である300$の返金は止まります。どちらも痛手です。一方はお金が漏れ、もう一方は優良顧客を解約へ押しやります。少なくとも、ポリシー外と返金を繰り返す顧客の列を加えてください。
- ヘルプデスクが強制してくれると思い込む。 Stripeの承認やAIのアクション設定を行っていない限り、上限は統制ではなく方針です。返金タグまたはレポートを使って、毎月担当者別に返金を監査してください。
- 承認者がグループになっている。 「リーダーのチャンネル」は承認者ではありません。金額帯ごとに担当者と代理を指名し、エスカレーションプロセスに明記してください。
- ストアクレジットを現金と同じに扱う。 ストアクレジットはお金が自社に残ります。緩めの金額帯を与えれば、担当者はより多く提案するようになり、それは多くの場合、顧客が望んでいたことでもあります。その提案の言い回しは、私の返金マクロが参考になります。
- チャージバックの担当者がいない。 紛争が開いた後に出した返金は二重払いになりえ、紛争手数料もかかります。チャージバックは毎回1人に回してください。
- 金額帯を見直さない。 チームリーダーが前四半期に自分の金額帯の98%を承認したなら、その金額帯は低すぎます。マトリクスは生きたサポートポリシーとして扱い、担当者とAIを同じ日に更新してください。
eeselで返金マトリクスを運用する
返金が、背後にShopifyストアがあるZendesk、Freshdesk、またはGorgiasから入ってくるなら、eeselのAIヘルプデスクチームメイトはマトリクスを現実のものにする最も簡単な方法です。既存のキューに加わり、過去のチケット、ヘルプセンター、マクロから学び、自動の金額帯にある返金を実行します。平易な言葉で書いたしきい値を超えるものはすべて、ダッシュボードまたはSlackで適切な担当者の承認を待ち、ポリシー外のものは、見つけた内容を説明するメモとともにチームに回されます。
実際の返金に触れる前に、過去のチケットでシミュレーションを実行し、返金リクエストをどう処理したかを、チームが実際にしたことと比較して確認できます。料金は対応したチケットごとで、席数は無制限なので、マトリクス上のすべての承認者が追加費用なしでアクセスできます。
100の無料クレジットで始め、Shopifyストアとヘルプデスクを接続し、初日からRefund OrderをNeeds approvalに設定しましょう。eeselを試す。