なぜ保証請求はサポートチームを疲弊させるのか
保証チケットは外から見ると単純ですが、中から見ると過酷です。どれも同じ少数の質問(「まだ保証対象ですか?」「領収書がありません」「どうやって送り返しますか?」)ですが、答えるたびに調べる必要があります。注文を探し、購入日を保証期間と照らし、不具合が対象か確認し、そのうえで返送手順を案内します。
人間の頭脳がほとんど要らないチケットに、クリック作業が多すぎます。しかも量は容赦がありません。私が見たあるDTCサプリメントブランドは、月に約7,000件のGorgiasチケットを抱え、まったく追いつけず、一息つくためだけにメール量の少なくとも半分を自動解決する必要がありました。別の複数ブランドを運営するEC事業者は、返金や注文追跡に関する定型的な問い合わせが1日500件以上あると話していました。保証請求はまさにこの定型的な中間層にあります。量が多く、複雑さは低く、無数の照会に殺されます。
もう一つの問題は、保証請求がお客様の嫌う形で「遅い」ことです。製品が壊れた人はすでに不満です。注文番号を尋ねるだけの返信に1日待たされ、実際の返送ラベルにさらに1日待たされれば、保証対象の修理が悪いレビューに変わってしまいます。これは典型的なWISMOの領域、つまり「私の...はどこ?」のパターンですが、ここでは「代替品はどこ?」であり、支払った製品が故障しているため、より重大に感じられます。
つまり、保証請求の問題は難しさではありません。定型的で、データが多く、しかも時間に敏感という点が重なっていることです。これはまさにAIが得意とする特徴です。
「保証請求のAI」とは実際に何か
「保証請求のAI」と聞くと、多くの人は「それはお気の毒です」としか言わないチャットボットを思い浮かべます。私が言うのはそれではありません。役に立つ保証AIは請求そのものを処理します。受信したメッセージを読み、お客様がいつ何を購入したかを突き止め、ポリシーと照らし、不足分を集め、次の具体的なステップを出します。
私が想定している最初から最後までの流れは次のとおりです。
順に見ていきます。
- 請求が届く。 お客様がメールを送るかチャットを開き、製品が故障したと伝えます。AIはそれを読み、一般的な返品や製品の質問ではなく保証請求として分類します。このチケット分類のステップが、適切なフローへ振り分けます。
- 保証期間を確認する。 AIは注文を調べて購入日を見つけ、保証期間と比較します。ストアのデータに接続されていれば、お客様に何も尋ねずに「8か月前にご購入で、保証は12か月なので対象です」と答えられます。
- 購入証明を収集する。 注文がメールアドレスに紐づいていない、または再販業者経由で購入された場合、AIは領収書やシリアル番号を求め、内容を読み上げて確認します。手作業のキューが何日も止まりがちなのがこのステップです。
- RMAまたは次のステップを下書きする。 適格性が確認できたら、AIは自社のプロセスに沿って、返品承認、配送ラベルの手順、または交換注文を作成します。ヘルプデスクに接続されたツールなら、会話からRMAを自動的に発行できます。
- 例外ケースをエスカレーションする。 あいまいなもの、ポリシー外のもの、高額なものは、完全なコンテキストを添えて人に引き継がれます。
要点は、ステップ1から4が機械的だということです。照会と文書作成です。人がやっても価値ではなく遅延が増えるだけです。人が本当に役割を果たすのはステップ5です。
AIが担うべきこと、担うべきでないこと
保証の仕組みが成功するか失敗するかはこの線引きで決まるので、はっきり言います。失敗のパターンは、AIが愚かで役に立たないことではありません。お客様が怒っていたからという理由でポリシー外の請求に特別な交換を承認してしまうなど、AIが判断すべきでない決定を任されることです。
AIは左の列に置いてください。保証ステータスの照会、適格性の確認、購入証明の収集、RMAの発行です。これらはルールに基づき、検証できます。AIは作業の根拠を示せますし、あなたが監査することもできます。
人は右の列に置いてください。特別対応(「厳密には保証切れだが対応しよう」という判断)、争われている請求やポリシー外の請求、不正に見えるものすべてです。これらには判断が必要で、ときに管理者の承認が要り、常に説明責任が伴います。AIが独断で400ドルの交換品を無償提供することは避けたいはずです。
よい点は、この線を自分で引けることです。優れたツールならエスカレーションルールを設定でき、AIは定めた枠の中でのみ動き、請求がその枠を超えた瞬間に引き継ぎます。それが「役に立つAI」と「責任リスクを生むAI」の違いです。
実際に機能するのか?数字で見る
もっともな疑問です。ここでは曖昧な話をやめられます。私たちは、ドイツのオンラインジュエリー小売業者の実際のチケットトラフィックでAI teammateを稼働させました。月に約1,000件のチケットをZendeskとShopifyで処理しており、284件のチャットのサンプルを100件のチケットと突き合わせて検証しました。チケットカテゴリごとに、AIの下書きがどれだけ役に立ったかを採点しました。
保証請求は有用な下書き96.4%で、返品・返金の93.8%をわずかに上回り、製品に関する問い合わせと返金ステータスはどちらも100%でした。保証はアカウント全体で最も強いカテゴリの一つで、正直なところ私の感覚どおりでした。これらのチケットは構造化されているため、AIが使える材料が多いのです。
私が読者なら知りたいので、正直な注意点をいくつか挙げます。「有用な下書き」とは、エージェントがほとんどまたはまったく編集せずに送れるという意味で、96%がそのまま送信されたわけではありません。同じ試験で、完全にそのまま送られた下書きは12%にとどまり、事実誤りの割合は7%でした。だからこそ最初は人がレビューを続け、不正や紛争のケースは決して自動運転で出さないのです。重要なのは「デモでAIがどれだけ優秀か」ではなく「自社のチケットでどれだけ優秀か」であり、それを知る唯一の方法は、導入前に自社の履歴で実行することです。
これが、本番前にシミュレーションすることの最大の理由でもあります。自信ありげに聞こえるボットが、静かに誤った回答を返す例を私たちは見てきました。だから私が信頼する導入はすべて、まず過去の実チケットでテストされ、ベンダーが選び抜いたサンプルではなく、実際の保証件数での精度とカバー率を確認できます。
既存のヘルプデスクで保証請求のAIを設定する方法
そのためにヘルプデスクを入れ替える必要はありません。私が取るアプローチは、すでに使っているZendesk、Freshdesk、Gorgias、Help ScoutにAIを重ね、注文データにつなぐことです。手順は次のとおりです。
1. ヘルプデスクと注文データを接続する
AIが保証請求を処理するには2つのデータソースが必要です。チケット(サポートがすでに行われている場所に常駐するため)と、ストアまたはERP(注文や購入日を照会するため)です。コマースプラットフォームを接続することが、適格性の確認をやり取りの往復ではなく自動にするステップです。
Shopifyを使っているなら、注文記録を直接読めるShopifyサポート向けに作られたAIがここで効果を発揮します。以下は、その注文照会が実際に動く様子のおおよそのイメージです。
2. 保証ポリシーを与える
AIは知っていることの範囲でしか優秀になれません。保証ポリシーのページ、ヘルプセンター、保証期間、無効になる条件、RMAプロセスを明記した社内ドキュメントを参照させてください。これは「どうやって送り返しますか?」という質問に答えるときに使うのと同じナレッジベースです。ポリシー文書が正確であるほど、後工程のミスは減ります。
3. エスカレーションとアクションのルールを決める
AIが何を言えるかだけでなく、何を実行してよいかを決めます。RMAを自動で発行してよいのか、エージェントが承認するための下書きにとどめるのか。請求額がいくらを超えたら人に引き継ぐのか。これらのルールを明示的に書き出してください。ここが先ほどのAIと人の境界を実際に適用する場所であり、優れたツールなら、大きな「自律」スイッチを一つ入れるのではなく、アクションの範囲を細かく絞れます。
4. 過去のチケットでシミュレーションする
実際のお客様に触れる前に、過去の保証チケットで実行してください。自社の件数での実際の解決率を確認し、実際の下書きを読みたいところです。多くのチームがこのステップを飛ばして後悔します。シミュレーションで特定の請求タイプでAIがつまずくと分かれば、誰かに影響が出る前にポリシー文書を直すかルールを厳しくできます。
5. 段階的に本番化する
下書きのみ、または狭い範囲(たとえば注文が紐づいた保証期間内の請求)から始め、数週間様子を見て、自信が増すにつれて範囲を広げます。その過程で解決率とデフレクション率を追跡してください。保証は構造化されているからこそ最初に自動化するのに適したカテゴリであり、システムへの信頼を築くリスクの低い場所です。
よくある失敗
私が見てきたうまくいかない例をいくつか挙げます。
- 初日から完全自律にする。 まず下書きから始めましょう。自律は段階的に獲得するものです。
- 注文データの接続を省く。 それがないと、AIはすべてのお客様に注文番号を尋ねることになり、意味がなくなります。
- あいまいなポリシー文書。 「保証についてはお問い合わせください」ではAIに何も伝わりません。期間と除外条件を具体的に書きましょう。
- 紛争のエスカレーション経路がない。 きれいな引き継ぎがなければ、AIはいずれ解決すべきでないものを解決しようとします。
保証請求にeeselを試す
3か月がかりのプロジェクトなしで導入したいなら、eeselが私のおすすめするAIヘルプデスクteammateです。私自身が使っていることも理由の一つです。すでに使っているヘルプデスクに接続し、過去のチケットと保証ドキュメントで学習し、Shopifyで注文を照会するため、お客様に手間をかけずに適格性の確認ができます。
保証に特に向いている理由は2つあります。1つ目は、本番前に自社の過去チケットでシミュレーションできるため、デモではなく自社の保証件数をどう処理するかが分かることです。2つ目は、請求を解決するたびに料金が増えるのではなく、チケット1件あたりの定額で課金されるため、保証が多い月でも請求書に驚くことがないことです。無料で始め、保証ポリシーを読み込ませて、その日の午後のうちにシミュレーションを実行できます。
よくある質問
AIだけで保証請求を処理できますか?
AIは保証請求の大部分をエンドツーエンドで処理できます。注文と照らして保証期間を確認し、領収書やシリアル番号を収集し、RMAを発行します。判断を要するもの、つまり特別対応、紛争、不正の疑いは、引き続き人に回すべきです。確実なパターンは、照会と事務作業はAI、例外は人という分担です。
保証請求におけるAIの精度はどのくらいですか?
実際のECライブチケットで行った試験では、保証請求に対するAIの下書きが役に立つと評価された割合は96.4%で、返品・返金の93.8%をわずかに上回りました。精度は、AIが保証ポリシーと注文データにアクセスできるかどうかに左右されます。そのため、本番前に自社の過去チケットでテストすることをおすすめします。
保証請求の処理にAIが必要とするデータは何ですか?
3つあります。保証ポリシー(保証期間と無効になる条件)、購入を確認するための注文・顧客記録、そして使い方に関する質問に答えるためのヘルプセンターです。Shopifyサポート向けAIのようなツールは注文データを直接取得するため、AIはお客様に尋ねずに購入日を確認できます。
保証請求のAIにはいくらかかりますか?
課金モデルによって異なります。解決ごとに課金するツールもあり、大量処理では高額になります。eeselはAIチケット1件あたり定額で、解決ごとの追加料金はありません。そのため保証請求が急増しても請求額は跳ね上がりません。ベンダーが会話単位、解決単位、チケット単位のどれで課金するかは必ず確認してください。これらは同じではありません。
AIが保証請求を解決できない場合はどうなりますか?
よい設定ならきれいにエスカレーションされます。請求が争われている、ポリシー外、または不正の疑いがある場合、AIは推測せず、完全なコンテキストを人間のエージェントに引き継ぎます。こうしたエスカレーションルールは自分で設定でき、AIは定めた範囲内でのみ動きます。