ECの問い合わせへAIコールセンターを使うときは、件数の多い用件をまとめて自動化しないでください。配送・返品・在庫・支払いを分けます。情報を読むだけの応答と、注文や返金を更新する処理も別にします。

最初の候補は、本人と注文を特定できれば現在の状態をそのまま案内できる用件です。更新処理が必要な場合は、成功結果を受け取るまで完了と案内しません。まず直近一か月の入電理由を四つに分け、照会だけで終わる件数を確認してください。

配送案内は注文と荷物の状態を分ける

「商品はいつ届くか」という質問でも、注文受付から配達中まで参照する情報が異なります。注文番号だけで予定日を推測せず、出荷単位と追跡情報を取得してから案内します。

一つの注文が複数便に分かれる場合があります。未出荷の商品が残る注文を「発送済み」とまとめないでください。

Shopifyの注文の配送状態は、未出荷や処理中だけではありません。一部出荷、保留、出荷済みも別の状態です。自社システムの値を、電話で案内する言葉へ一対一で対応させます。

追跡番号があっても配送会社へまだ反映されていない場合は、到着日を断定しません。「出荷手続き済み」と「配送中」を分けます。住所変更や配送停止は照会ではなく更新処理です。締切を過ぎた注文は、倉庫や配送会社へ確認する受付へ切り替えてください。

返品受付は条件判定と登録を一件で追う

返品は、返品できるかを答えるだけでは完了しません。注文と商品を特定します。購入経路や到着日、返品理由と開封状態も確認します。自社の返品規定へ当てはめ、受付番号を発行して後続処理へ渡すところまでを一件として追います。

消費者庁の特定商取引法ガイドは、通信販売の返品条件について説明しています。返品の可否と期間、送料負担の有無を表示する必要があります。AIには、承認済みの返品規定と適用開始日を参照させます。通話中の解釈で条件を広げたり狭めたりしないでください。

公開事例では、PKSHA VoiceAgentとEC-CUBEを連携した返品受付が紹介されています。電話番号や顧客番号から注文情報を照会し、返品可否を判定して受付結果をEC-CUBEへ戻す構成です。自社で試す場合も、照会した注文と使った規定の版を残します。登録結果まで同じ受付IDから確認できるようにしてください。

商品不良と顧客都合を分けられない場合や、規定にない事情がある場合は有人対応へ渡します。AIが判断できなかった通話を「返品不可」と案内しないことが重要です。

在庫案内は販売可能数を保証しない

在庫の質問では、倉庫にある数量と、いま注文へ割り当てられる数量を区別します。他の注文への引当や店舗在庫、入荷予定が別システムにある場合、単一の在庫数だけでは購入可否を判断できません。

Shopifyのフルフィルメントサービスでは、倉庫側から在庫や追跡情報を受け取る仕組みが案内されています。複数倉庫を使う場合は、どの拠点の時点情報かも記録します。

AIが案内するのは、照会時点の販売状態と次回確認方法までにします。「確保しました」と伝えるのは、在庫引当の成功結果を受け取った場合だけです。入荷予定日が未確定なら、予約や取り置きを約束せず、入荷通知や有人確認へ進めます。

支払いは状態照会と金銭処理を分ける

支払い関連では、決済失敗と本人認証待ちを分けます。処理中、入金済み、返金待ちも別の用件です。注文画面の表示だけでなく、決済システムが返す現在の状態を確認します。

StripeのPaymentIntentのライフサイクルでは、支払方法待ちと追加認証待ちが別の状態です。処理中と成功も分かれています。非同期の支払方法では、処理完了まで数日かかる場合もあります。処理中の決済を失敗または入金済みと案内しないでください。

利用者にカード番号やセキュリティコードを読み上げてもらう設計は避けます。支払方法の再登録は安全な画面へ案内し、電話では必要最小限の本人確認と状態説明に限定します。返金や二重請求、不正利用の申告は金銭処理を伴います。担当部署へ引き継いでください。

完了と有人引き継ぎを別の結果にする

AIの応答結果は、少なくとも四つに分けます。自動完了と有人確認待ちがあります。処理失敗と停止希望も別にします。「案内した」と「注文システムへ登録できた」を同じ完了にしないでください。

更新処理では、受付IDを発行してから外部システムを呼び出します。成功時は登録された処理番号を残します。ただし、受付IDを渡すだけで二重登録を防げるわけではありません。連携先に同じ処理の再実行を防ぐ機能があるか、その有効期間と使い方を確認します。

タイムアウトは未処理とは限らないため、再送前に登録結果を照会します。処理済みか確認できず、重複を防ぐ機能もない場合は自動再送を止めて有人確認へ渡してください。追跡用の受付IDと連携先の処理番号を対応付けておくと、復旧時に照合できます。

有人へ渡す情報は注文番号だけではありません。本人確認の結果と確認済みの商品を含めます。顧客の希望とAIが処理を止めた理由も必要です。担当者が最初から聞き直す状態では、自動化範囲を広げても処理時間は減りません。

六つの通話で最初の対象を決める

最初の業務は件数だけで選ばず、現在の状態と安全な終了条件を再現できるかで決めます。次の六つをテストしてください。

  1. 出荷済みの注文から正しい追跡情報を案内する
  2. 一部だけ出荷された注文を複数便として説明する
  3. 返品期限外の申出を規定に沿って有人へ渡す
  4. 注文が見つからない場合に本人確認を打ち切る
  5. 処理中の決済を入金済みと断定せず案内する
  6. 外部システムのタイムアウト時に二重登録せず受付を残す

六つの試験ケースには、それぞれ別の受付IDを付けます。一つのケースの通話内容と参照した状態、処理結果は同じ受付IDから追ってください。同一処理の再送試験では、その処理に割り当てた重複防止用のキーを維持します。

最初に選びやすいのは、配送状況のように照会だけで終了できる用件です。返品受付から始める場合は、規定の条件がデータ化されていることを確認します。登録失敗時に人が復旧できることも必要です。

直近一か月の入電を配送・返品・在庫・支払いへ分けてください。そのうち、照会するシステムと電話後の状態が一つに決まる用件を、最初の自動化候補にします。