通販・ECのAI電話は、問い合わせを減らすだけのFAQではありません。注文前、注文後、配送、返品、定期購入という顧客の現在地を分け、答えるだけの用件と照合・変更・人間判断が必要な用件を安全に接続するCustomer Journeyです。
EC Customer Journeyを電話用に分解する
| 問い合わせ | 最初の処理 | 確定前に必要なこと |
|---|---|---|
| 商品・在庫 | FAQまたは在庫照会 | リアルタイム性確認 |
| 配送状況 | 注文候補照合 | 本人確認 |
| 住所変更 | 変更可否判定 | 出荷状態・確認 |
| 返品・交換 | 条件案内・受付 | 期限・商品状態 |
| 定期購入 | 次回情報の照会 | 本人確認・締切 |
| 決済 | 安全な案内 | カード情報を聞かない |
Inquiry → Tool Action Matrix：回答と操作を混ぜない
営業時間や返品ポリシーは回答、配送状況はLookup、住所変更やキャンセルはAction、他人の注文情報につながるものは本人確認、人の裁量が必要なクレームや例外はHumanという5種類に分けます。AIが注文内容を理解しても、注文変更が確定したとは限りません。
Order Change Safety Flow
配送先変更・キャンセル・返品受付は、Draft、確認、Commitを分離します。APIの応答が途切れても同じ操作を二重に実行しない冪等キーを持ち、確定後には何が変わったかを短く復唱します。AI電話とCRM連携の最小権限・監査ログの考え方を、注文管理にも適用します。
AI / Human Boundary：顧客体験を壊さない例外処理
配送事故、返金判断、期限外の例外、決済情報、悪質な問い合わせ、複数注文の複雑な照合は、人が引き継ぎます。折り返し・再入電ループ対策を使い、担当者が受けた情報を再度聞かなくてよいCaseを残します。営業時間外は時間外受付として、翌営業日の回答範囲を明示します。
導入前に確認するEC固有リスク
他人の注文情報開示、配送先変更、キャンセル期限、返品条件、決済情報、在庫の鮮度、二重実行、倉庫・CRM・EC基盤の更新遅延を確認します。Shopify等のプラットフォーム連携は、利用中プランと公式API・プライバシー要件を実装時点で確認し、電話AIに管理者権限を渡さないことが基本です。
4つの問い合わせをOrder StateとFulfillment Stateで分ける
| 問い合わせ | Order State / Fulfillment State | 許可するAction | 人へ渡す条件 |
|---|---|---|---|
| 配送状況 | 支払・注文確定後 / 未出荷・一部出荷・出荷済 | Tracking等の確定情報をLookup | 追跡情報が古い、配送事故 |
| 住所変更 | 未処理 / 出荷前 | 本人確認後に変更候補をDraft化 | 出荷済、外部倉庫へ引渡し済 |
| 返品・交換 | 配送済 / 返品受付前・返送中 | ポリシー案内、受付CaseのCreate | 例外返金、期限外、商品状態判断 |
| 定期購入 | 契約有効 / 次回確定前 | 次回予定のRead、条件内の変更Request | 支払・契約条件変更、締切経過 |
Orderが作られたことと、倉庫が出荷を始めたことは別状態です。電話AIは「変更できそう」ではなく、正本のOrder・Fulfillment状態と権限から、案内・仮受付・確定のどれかを選びます。
具体Flow：配送、住所、返品、定期購入
配送状況
注文番号等で照合→配送事業者の追跡情報と取得時刻を確認→情報が鮮度内なら案内→鮮度外・例外ならCaseにして担当へ。APIで取得できない時に到着予定を推測しません。
住所変更
本人確認→OrderとFulfillmentの状態確認→変更可能期間なら変更案を復唱→明示確認→冪等キー付きAction→結果を読み返す、の順です。出荷開始後は変更を確定せず、配送会社・担当CSの手順へ渡します。
返品・交換
購入ID、商品、理由、到着日を受け、ポリシーに沿った案内とCase作成に限定します。返金額・例外の承認・再送は人の判断に残し、同じ返品を再入電で二重作成しない照合キーを使います。
定期購入
次回発送日、変更締切、対象商品をReadし、締切内なら希望を仮受付します。契約・決済情報の変更は、音声でカード情報を受けず、本人認証されたWeb導線または担当者へ切り替えます。
API Failure・Duplicate Action・Stale InventoryのFallback
| 失敗 | してはいけないこと | 安全なFallback |
|---|---|---|
| API 5xx / Timeout | 成功・失敗を会話だけで決める | Request IDで状態照会し、未確定ならCaseへ |
| Duplicate Action | 再試行のたびに変更・返金を送る | Order ID＋操作種別＋versionの冪等キー |
| Stale Inventory | 古い在庫で確定・代替品を約束する | 取得時刻を持ち、鮮度外は仮受付へ |
| Scope不足・PII redaction | 空欄を「該当なし」と答える | 権限不足として人へ渡し、Scopeを見直す |
Shopify等の一次資料で確認する権限境界
Shopifyの注文・Fulfillmentには用途別のread/write scopeがあり、注文・顧客・配送情報はProtected Customer Dataの要件に含まれます。電話AIに全権限を渡すのではなく、照会用と変更用のToolを分け、Protected Customer Dataの承認、保存・表示範囲を実装前に確認します。
関連論点を自社の受付へ落とし込む
AI電話受付、折り返しループ対策、AI電話とCRM連携、AI電話セキュリティ、営業時間外対応も併せて確認し、入口の会話だけでなく、記録、例外、担当者への引継ぎまで一つの流れとして整理してください。
よくある質問
電話で注文情報を案内する時に必要なことは？
他人への情報開示を避けるため、注文番号・連絡先など業務に合う本人確認を行い、必要最小限だけ案内します。
配送先変更やキャンセルをAIだけで確定できますか？
期限、本人確認、在庫・出荷状態、二重実行防止を満たす場合に限ります。条件外は人間へ渡します。