大手EC事業者従業員数1,000名以上カスタマーサポート部門

EC問い合わせの一次対応・返品処理AIを本番化

注文・配送・返品に関する問い合わせの一次対応を担うAIエージェント。誤った案内が返品・クレームに直結するため、業務システムと連携した正確な状態取得と回答の作り込みを徹底して本番投入した。

🎯背景・課題

繁忙期に問い合わせが急増し、一次対応の待ち時間が長期化。定型的な確認業務にオペレーター工数が割かれていた。

直面していた課題

•注文・配送状況の確認など定型問い合わせが大量
•誤った案内が返品・クレームに直結するリスク
•基幹の注文・在庫システムとの安全な連携が必要
•返金・返品ポリシーの例外条件で誤回答が起きやすい

💡Wizitのアプローチ

「速い」より「間違えない」を優先。注文状態は推測させず必ずシステムから取得し、ポリシーの例外条件を評価セットで重点的に作り込んだ。

本番化までの進め方

🔬

① 出力の作り込み

→

🔒

② ガバナンス突破

→

★

本番化

📈

③ 継続eval・ROI

👥

④ 内製化

進め方の詳細

▸Phase1: 返金・返品ポリシーの例外を含む評価セットを作成し、誤回答を反復修正
▸Phase2: 注文・在庫システムへ安全に接続（MCP/API）し、状態を確実に取得
▸Phase2: エスカレーション基準を設計し、判断が難しい案件は確実に有人へ
▸Phase3: 本番後の誤対応を継続evalで監視・改善

主な技術・仕組み

🔧基幹システム連携（注文・在庫・配送状況）
🔧ポリシー例外を含む評価セットでの作り込み
🔧エスカレーション制御
🔧継続eval・対応品質モニタリング

🧩この事例の仕組み

注文状態は推測させず基幹システムから取得。判断が難しい案件は確実に有人へ。

🔀 自動化する／しないの線引き

自動で対応

配送状況の確認・定型FAQ・返品の一次受付

有人へ回す

ポリシーの例外・個別事情・クレーム対応

🔬 PoC死をどう回避したか

チャットの初稿はすぐ動いた。難所は返金・返品の例外条件。「規約上は返金不可」を平然と間違える出力を、評価セットで一つずつ潰す作り込みに注力した。

🔒 ガバナンスをどう突破したか

注文・顧客データへのアクセスを最小権限で設計し、操作ログ・監査証跡を整備。基幹システム連携の安全要件を満たして本番化した。

📈成果

一次対応の自動解決

Before

0%（導入前）

→

After

相当割合を自動化

有人対応の負荷を軽減

繁忙期の待ち時間

Before

長期化

→

After

短縮

一次対応の即時化

誤案内による返品・再対応

Before

一定数

→

After

低減

例外条件の作り込みで抑制

定性的な変化

★オペレーターが定型確認から解放され、難度の高い対応に集中
★繁忙期のスケールに人員増だけで対応しなくてよくなった
★対応品質のモニタリングが運用に組み込まれた

🗓️ タイムライン

Phase1 出力の作り込み: 約2ヶ月 → Phase2 連携・本番: 約2ヶ月 → Phase3 継続eval（運用中）

🚀 その後の横展開

他カテゴリ・他ブランドの問い合わせ窓口へ展開中。

※ 守秘義務により、クライアント名および特定につながる固有情報は伏せています。

同じような課題、ありませんか？

止まっているPoCが本番化できるか、最短で見極めます。

相談する