AIで返金リクエストを自動化する方法(サポートチーム向けガイド)

「返金リクエストの自動化」が実際に意味すること

まず、最大の誤解を解いておきましょう。返金の自動化は、オンオフを切り替えるだけのスイッチではありません。AIをどこまで信頼するかという幅の中のどこかを選ぶことであり、そのちょうど良い位置を見極めることがすべてです。

軽い方の端では、AIが届いたチケットを読み、注文内容を確認し、オペレーターが承認するための返信を下書きします。送信ボタンを押すのは人です。もう一方の端では、AIがチケットを読み、ポリシーと注文を照合し、ストア経由で返金を実行し、顧客に返信するまで、すべて人の介在なしに行います。ほとんどのチームはその中間のどこかにいて、信頼が積み重なるにつれて自動化の度合いを右側へ寄せていきます。

この整理が重要な理由は、返金リクエストが「機械に任せて安全なもの」と「人が対応すべきもの」にきれいに分かれるからです。注文番号が明確でポリシーの範囲内にある返金は、単調な作業です。そして単調な作業こそ、自動化すべき対象です。一方、怒りのクレームが絡んだ返金、不正の疑いがある注文、チャージバックが関わる返金は、まだ人の出番があるところです。

これは、優れた一次対応の削減(ティア1デフレクション)の考え方と同じです。予測可能な量の対応はAIに任せ、チームは本当に判断が必要な厄介な20%に集中できるようにします。返金は、注文追跡や「注文はどこにあるか(WISMO)」に関する質問と並んで、もっとも一次対応向きの領域のひとつです。

始める前に:返金ポリシーを「人の頭の中」から取り出す

ここは誰もが飛ばしてしまうステップですが、これがうまくいくかどうかを決める工程です。

AIは、判断基準がどこかにきちんと文章化されている場合にのみ、返金の判断を自動化できます。多くのチームでは、「ポリシー」とは実際には最ベテランのオペレーターの頭の中にある不文律です。30日以内なら返金する、セール最終処分品は返金しない、サブスクリプションを解約する前にまずトラブルシューティングを行う、といったものです。文章化されていなければ、AIはそれに従うことができませんし、新人スタッフも同じです。

そこで、どんなソフトウェアに触れる前にも、機械が実際に実行できる形でルールを書き出しましょう。

• 期間(配達からX日以内の返金)。
• 例外(セール最終処分品、開封済みの消耗品、デジタル商品)。
• 金額のルール(全額返金、再入荷手数料、ストアクレジットか現金か)。
• 手順のルール(まずトラブルシューティングを行う、写真を求める、注文番号を確認する)。

これは、AIが参照するナレッジベースを構築、あるいは整理する良い機会でもあります。朗報なのは、しっかりしたAIエージェントであれば、すでにある情報源、つまりヘルプセンターや過去のチケット返信、マクロから学習できるという点です。そのため、多くの場合はゼロから書くのではなく、既存のものを編集するだけで済みます。チームがすでに返金・交換マクロを活用しているなら、それは貴重な資産です。すでに顧客向けの言葉で書かれた、あなたのポリシーそのものだからです。

AIで返金リクエストを自動化する方法:ステップバイステップ

詳しく見ていく前に、全体の流れを把握しておきましょう。リクエストが届くと、AIが注文内容とポリシーを確認し、その確信度とリクエストがポリシーの範囲内かどうかに応じて、3つのうちのいずれかが起こります。

1. ヘルプデスクとストアを連携する

AIには2つの連携が必要です。ヘルプデスク(チケットが届く場所)と、ストアまたは請求システム(注文と返金の情報がある場所)です。ヘルプデスクはZendesk、Freshdesk、Gorgias、Help Scout、あるいはお使いのものであれば何でも構いません。ストアは、Eコマースであれば通常Shopify、あるいはサブスクリプション・請求ツールです。

ストアとの連携がなければ、AIは「返金の仕組みはこうです」という返信の下書きしか作れません。連携があれば、AIは実際の注文情報を取得し、配達日を確認し、実際のアクションを実行できます。これが、単なる高機能FAQボットと、実際にチケットをクローズできるものとの違いです。

eeselの場合、これはサービス契約ではなく、セルフサービスでの連携です。ヘルプデスクとストアを自分でつなぐだけで、エージェントはすぐに過去の履歴を読み込み始めます。これは、そもそも導入する価値があるかどうかを検討する段階で重要なポイントです。

2. 返金ポリシーと過去のチケットを学習させる

準備段階で書いたポリシーと、既存のナレッジソースをAIに読み込ませましょう。ここから、AIは汎用的な受け答えをやめ、あなたのチームらしい話し方をするようになります。

見落とされがちなポイントですが、新人オペレーターに説明するのと同じように、平易な言葉でルールを教えられるべきです。「注文に未解決の問題がある場合は、キャンセルや返金の処理をせず、まずトラブルシューティングを行う」といった具合です。優れたエージェントであれば、コードを書いたりフローチャートを作ったりしなくても、その指示を受け取って以後の対応に反映させます。

この「まずトラブルシューティング」というルールは、架空の例ではありません。私が一緒に仕事をしたあるサポート管理者は、デジタルメディアのサブスクリプション事業を運営しており、たった一文でこのポリシーをエージェントに教えました。

「カスタマーサポートには、問題が付随している場合はキャンセルや返金のリクエストに対応しない、というルールがあります。」

それまでAIはキャンセルを自動承認してしまっていましたが、平易な言葉での一度の修正指示によって、チームの他のメンバーと同じようにまずトラブルシューティングを行うようになりました。目指すべき基準はここです。ポリシーは一箇所にまとまっており、その変更はエンジニアリングチームへのチケット起票ではなく、一文で済むということです。

3. AIが自分の判断で行ってよいことを決める

ここは安全性を調整するダイヤルであり、構築全体の中でもっとも重要な設定です。

ここでは2つのことを設定する必要があります。1つ目は、AIが取れるアクションです。返信のみ、タグ付けとルーティングのみ、あるいはストアで実際に返金を実行するまで、といった選択肢があります。2つ目は、もっとも影響の大きいアクションに対するガードレールです。返金の自動実行は、注文が期間内であり、設定した金額の上限を下回り、係争中でない場合にのみ許可します。この範囲外のものはすべて、下書き作成またはエスカレーションに回されます。

率直なアドバイスとしては、必要だと感じるよりもさらに狭い範囲から始めることです。極めてシンプルな返金(ポリシー範囲内、少額、問題のない注文)だけを自動実行させ、それ以外はすべて下書きにしましょう。AIの挙動を確認できたら、金額の上限やカテゴリーを広げていけます。「狭く始めて広げる」は、常に「広く始めて後で謝る」に勝ります。誤って返金してしまった注文を取り戻す作業は、下書きをいくつか手作業で承認するよりもずっと厄介な月曜日を生むからです。これは、うまく機能しているAI設定に共通するエスカレーションの考え方と同じです。

4. 実際の顧客に触れる前に、過去のチケットでシミュレーションする

この工程は絶対に飛ばさないでください。自動化を信頼できるチームと、怖い思いをして自動化をオフにしてしまったチームを分ける、唯一と言っていいポイントです。

本番運用の前に、直近の数百件の実際の返金チケットに対してAIを動かし、AIがどう対応していたかを確認しましょう。すでに正解が分かっているチケットに対して、AIが送っていたであろう返信や、取っていたであろうアクションを見ることができます。誤った判断は、怒った顧客としてではなく、ルールを調整すれば直せる差分として表面化します。

この数字は、実際の運用から得られたものです。ZendeskとShopifyを使い、月間およそ1,000件のチケットに対応しているドイツのジュエリーブランドで行ったシミュレーションでは、エージェントは返品・返金で93.8%の割合で実用的な下書きを作成し、返金ステータスに関する質問には100%正しく回答することが分かりました。本番運用の前にこれを確認できることで、運用開始の判断が恐ろしいものではなく、退屈なものになります。私たちが何年も前から、あらゆるロールアウトを過去のチケットでシミュレーションするようにしているのは、自信満々に見えるボットが静かに間違いを犯すのを何度も目にしてきたからです。シミュレーションは、それを発見するもっとも低コストな方法です。

5. 狭い範囲で本番運用を始め、そこから広げる

まずは一部の範囲だけで有効にしましょう。よくあるパターンは、返金ステータスに関する質問と、明らかにポリシー範囲内の返金だけをAIに自動対応させ、それ以外はすべて下書き付きで人に振り分けるというものです。実際のキューで1週間ほど様子を見てください。

そのあとで、意図的に範囲を広げていきます。金額の上限を引き上げる、これまで保留していた返金カテゴリーを追加する、といった具合です。それぞれの拡大は、データによって裏付けられた小さく元に戻せる判断であり、祈るような気持ちで臨む一発勝負のローンチではありません。これは、何もかも中途半端にこなすか、まったく役に立たないかのどちらかになりがちな、典型的なルールベースのチャットボットの罠を避ける方法でもあります。

6. 数字を見ながら調整する

運用開始後は、いくつかの数字を見ればうまくいっているかどうかが分かります。人を介さずに完全に解決した返金チケットの割合、返金チケットの初回応答時間、そして返金に関するやり取りに限定したCSATです。解決率が上がり、CSATが維持されていれば、さらに範囲を広げましょう。CSATが下がった場合は、どのカテゴリーで下がったのかを確認し、そのカテゴリーだけ下書きモードに戻してください。

返金は、これらの数字がすぐに動くからこそ、最初の自動化として最適です。私が話を聞いた、複数ブランドを展開するあるEコマース事業者は、返金・解約・注文追跡といった繰り返しの多い問い合わせを1日500件以上抱えていました。まさにこうしたケースこそ、良い指標が最初の1か月で伸びやすいプロファイルであり、あるチームが最初の1か月で一次対応リクエストの73%を解決したのと同じパターンです。

返金自動化が裏目に出る原因となるミス

何度も目にしてきたいくつかの落とし穴を挙げておきます。あらかじめ知っておけば避けられるはずです。

• ポリシーを書く前に判断を自動化してしまう。 AIは、誰かの頭の中にしか存在しないルールを適用することはできません。まずルールを文章化しましょう(準備段階を参照)。これが、導入がうまくいかないと感じる最大の原因です。
• 初日から範囲を広げすぎる。 最初からすべての返金を自動実行してしまうと、お金を無駄に払うことになります。狭く始め、シミュレーションし、それから広げましょう。
• 感情的な案件へのエスカレーション経路がない。 「これで3回目の問い合わせです」といった言葉を伴う返金リクエストには、すぐに人の対応が必要です。ボットが顧客の怒りに気づかず、能天気に返金処理を進めてしまわないよう、きちんと振り分けましょう。エスカレーションのルールを正しく設定してください。
• 設定したまま放置してしまう。 ポリシーも、商品ラインナップも、季節ごとの返品期間も変わっていきます。四半期ごとにルールを見直しましょう。平易な言葉で設定できることの利点は、更新にたった一文しかかからないことです。

うまく扱えば、返金の自動化はサポート業務の中でもっとも分かりやすい成果のひとつになります。対応件数の大きな割合を占め、繰り返しが多く、同じ作業を人が行う場合のコストと比べてコスト削減効果を測定しやすいからです。

返金リクエスト対応にeeselを試す

サービス導入プロジェクトなしで、このガイドで説明した仕組みを実現したいなら、それこそ私が作っているものです。eeselはヘルプデスクとストアに接続し、既存のヘルプドキュメントや過去のチケットから返金ポリシーを学習し、返信の下書きから、ルールの範囲内での返金実行まで、AIが自分でできる範囲を正確に設定できます。シミュレーションモードは、まず実際のチケット履歴に対して実行されるため、顧客に影響が及ぶ前に解決率とすべてのアクションを確認できます。

料金は対応したチケットごと(約40セント)で、シート課金はありません。そのため、コストは人員数ではなく実際の作業量に連動します。数分あれば連携を行い、自社のデータでシミュレーションを実行できます。