EC受注処理の代行をAIで受託する｜受注確認・出荷連絡・追跡番号の登録まで、返金とキャンセルの判断は顧客に残す線

この記事は、ECサイトの受注処理と出荷連絡の代行を、AIと人の確認で月額の業務として受ける方法を扱います。

EC受注処理の代行は、制作会社が作ったECサイトの「その後」を、毎日の業務として預かる形です。
商品登録や特集などの運用代行とは、受ける中身も、間違えたときの影響も違います。

「注文が増えて、出荷の連絡が追いつかない」

ECサイトを納めて半年。顧客からこんな相談が来ます。
注文の確認、在庫の確認、倉庫への指示、出荷の連絡。少人数の店では、店主が夜にまとめて処理しています。

運用代行の延長で「受注の処理もやります」と引き受けると、返金、キャンセル、配送事故の相談まで、こちらに届き始めます。
受注処理は、お金と購入者に直接つながる業務です。売上を伸ばす運用とは、別の商品として設計します。

EC運用代行（商品登録・特集・分析・広告）の範囲と月額は、こちらで扱いました。

▶ EC運用代行の月額、制作会社は「売上の何%」で受けない──商品登録・特集・分析・広告の範囲の分け方と、成果報酬を避ける理由の計算例

EC受注処理の代行とは、決まったルールで注文を確かめ、出荷の指示と連絡を漏れなく回し、ルールに当てはまらない注文を顧客に渡す業務である

黒字化の外科医です。EC受注処理と出荷連絡の代行を、受ける範囲と残す判断に分けて解剖します。

なお私は弁護士ではありません。実務の指針として読み、個別の判断は専門家や公的な窓口に確認してください。

範囲を分けて設計すべき理由は、三つあります。

第一に、受注処理の大半は、ルールで回せるから。
支払いの確認、在庫の引き当て、出荷の指示、追跡番号の登録と連絡。決まった手順の繰り返しは、AIの下書きと人の確認に向いています。

第二に、返金とキャンセルは、取り消しにくい判断だから。
お金を戻す、注文を取り消す、特別に対応する。これは店の方針の判断で、代行する側が決めると、責任の線が崩れます。

第三に、購入者の個人情報を、毎日扱うから。
氏名、住所、電話番号。権限と取り扱いのルールを決めずに始めると、漏えいや誤送信のときに、誰が何をしたか追えません。

EC受注処理の代行で受ける範囲、残す範囲

受ける（AIの下書き＋人の確認）
・新しい注文の確認（支払いの状態、在庫、配送先の不備）
・不備のない注文の出荷指示（倉庫・発送担当への連絡）
・追跡番号の登録と、出荷連絡の送信（顧客が承認した定型文）
・「注文はいつ届くか」など、ルールで答えられる問い合わせへの返信の下書き
・不備のある注文、ルールに無い注文を、一覧にして顧客に渡す

顧客に残す
・返金、キャンセル、交換、値引きの判断
・決済の操作（返金処理を含む）
・配送事故、クレーム、レビューへの対応
・在庫の数の最終判断、商品の価格の変更

問い合わせへの返信の範囲と、誤回答の扱いの決め方は、こちらで扱っています。

▶ 問い合わせ一次対応のAI化を受託する制作会社へ──答えてよい範囲、誤回答が起きたときの扱い、人への引き継ぎの条件を、受ける前に顧客と決める

権限と委託：管理画面とメールを、どう預かるか

□ ECの管理画面は、代行用のスタッフの利用者を顧客に追加してもらう（共有のログインは使わない）
□ 権限は「注文の閲覧」「発送の処理」「定型の連絡」まで。返金・決済・設定・アプリの追加の権限はもらわない
□ 購入者の情報を扱うので、個人情報の取扱いの委託として覚書を結ぶ
□ AIのサービスに購入者の氏名・住所・電話番号を入れない運用にする（注文番号で扱う）
□ 誰がいつ何を処理したかを、管理画面の記録と処理表で追えるようにする
□ 終了時に利用者を削除してもらい、手元の処理表を返却・削除した記録を残す

管理画面の権限の受け取り方は、Shopifyの記事で具体的に扱いました。

▶ Claude Code×Shopifyでテーマ改修とEC運用を受託する──開発テーマでの確認、権限の受け取り方、月額の計算例

今すぐ試せる：注文の「不備チェック表」を作るプロンプト

私はWeb制作会社で、顧客のECサイトの受注処理を代行します。
注文を「そのまま出荷できる」「顧客に確認する」に分けるためのチェック表を作ってください。
（購入者の氏名・住所・電話番号は入力しません）

【店の情報】
・扱う商品の種類：〔　　〕
・支払い方法：〔　　〕
・配送方法と、配送できない地域や条件：〔　　〕
・店のルール（同梱、のし、日時指定など）：〔　　〕

1. 出荷の前に確かめる項目を、チェック表にする。
2. 「顧客に確認する」に回す条件を列挙する（返金・キャンセル・特別対応の求めは必ず含める）。
3. 店のルールに書かれていないことは、推測で決めず「要確認」と書く。

受注処理工場：1日の流れと月額の計算例

1日の流れ（例：平日2回の処理）

10時：前日夜からの注文をAIで仕分け（不備なし／要確認）
　　　人が仕分けを確かめ、不備なしの注文の出荷指示を出す
　　　要確認の一覧を顧客に送る
15時：倉庫・発送担当からの追跡番号を登録し、出荷連絡を送る
　　　問い合わせの返信の下書きを人が確かめて送る
毎週：処理件数、要確認の件数、遅れ、誤りを顧客に報告する

月額の計算例（数字はすべて例）

前提：月600件の注文、平日2回の処理
　注文の確認と出荷指示：1件2分 × 600件 ＝ 1,200分 ＝ 20時間
　追跡番号の登録と出荷連絡：1件1分 × 600件 ＝ 600分 ＝ 10時間
　要確認・問い合わせの対応：30件 × 10分 ＝ 300分 ＝ 5時間
　週次・月次の報告：2時間
　人の時間の合計：20 ＋ 10 ＋ 5 ＋ 2 ＝ 37時間

　37時間 × 時間単価7,645円 ＝ 282,865円
　予備（人の時間の10%）：28,287円
　AI・ツールの実費：10,000円
　月額の下限：282,865 ＋ 28,287 ＋ 10,000 ＝ 321,152円
　1件あたり：321,152円 ÷ 600件 ≒ 535円

時間単価7,645円は、時間単価の記事の計算例の数字です。自社の数字に置き換えてください。セールの月は件数が跳ねるので、上限件数と超過の単価を範囲表に書いておきます。

構造的なリスク

逆説を指摘しておきます。

受注処理を預かると、店主は注文の中身を見なくなります。
すると、要確認の一覧への返事が遅れ、出荷の遅れが「代行の遅れ」に見えるようになります。

要確認の注文への回答期限と、期限を過ぎたときの扱い（保留のまま翌日に再送）を、範囲表に書いておきます。

よくあるQ&A

Q. 返金の操作も頼まれたら？

判断は顧客、操作も顧客の側に残すのが基本です。どうしても操作を受けるなら、顧客の書面の指示がある分だけ、と範囲表に書きます。

Q. 土日の注文はどうするか？

受付の時間帯を範囲表に書き、土日の注文は月曜の処理として扱います。サイトの表示も、顧客と合わせて直します。

Q. 手順書は、どこまで細かく作るか？

新しい担当者が、手順書だけで1日の処理を回せる細かさにします。型は、こちらにまとめました。

▶ バックオフィス代行の業務記述書・手順書テンプレート｜役割分担表、手順書の型、判断基準表、例外の引き継ぎ表、権限台帳、5業務の記入例

最後に

EC受注処理の代行は、売上を伸ばす仕事ではなく、注文を漏れなく、正しく流す仕事です。

ルールで回せる処理だけを受け、返金とキャンセルの判断と決済の権限を顧客に残した会社だけが、購入者に直接つながる業務を、安心して預かれるのです。

これまでの記事は、メンバーシップ「黒字化オペ室」でまとめて読めます。月額1,980円、記事2本分の金額です。詳しくはプロフィールから。

#Web制作会社 #EC受注処理 #EC運用代行 #出荷連絡 #AI業務代行 #BPaaS #業務代行 #制作会社経営 #中小企業 #ネットショップ