EC運用代行は、ネットショップの作業を丸ごと渡す契約ではありません。商品情報、在庫、注文、出荷、返品、販促、顧客対応を止めないために、委託先が実行する作業と、自社が判断・承認する事項を分ける仕組みです。依頼範囲が曖昧なままでは、在庫切れ商品の販売、誤った価格、出荷遅延、返金の滞留、問い合わせの放置が起きても、誰が止めるか決まりません。先に日次の締め時刻、例外の連絡先、承認者、完了証拠を決めます。
最初に「運用」と「経営判断」を分ける
運用代行へ任せやすいのは、決められた条件に沿った登録、照合、一次対応、報告です。商品の発売可否、原価を踏まえた価格、値引き上限、返金例外、販売停止、個人情報事故の公表などは、自社の責任者が判断します。売上目標だけを伝え、値下げや広告費、顧客補償まで無制限に任せると、作業は進んでも利益と責任が見えなくなります。
| 領域 | 委託先が実行しやすい仕事 | 自社に残す判断 | 完了証拠 |
|---|---|---|---|
| 商品 | 指定原稿・画像・属性の登録 | 発売、表示根拠、権利、販売条件 | 公開URLと登録差分 |
| 在庫 | 連携結果と差異の確認 | 引当ルール、販売停止、予約可否 | 差異一覧と対応結果 |
| 注文・出荷 | 状態更新、送り状、通知 | 欠品代替、分割、期限超過対応 | 未処理・例外がゼロか一覧化 |
| 返品・返金 | 受付、記録、定型案内 | 承認、補償、例外、再販売可否 | 検品・返金・在庫反映 |
| 販促 | 承認済み企画の設定と停止 | 価格、期間、対象、粗利下限 | 設定値と公開後確認 |
| 顧客対応 | 一次返信、分類、担当振分け | 法務・安全・高額補償の回答 | 期限超過と未解決一覧 |
一般的な更新、保守、分析の分担は止まらないサイト運用の設計で扱います。この記事では、購入と配送が発生するEC固有の境界だけに絞ります。
商品情報は一つの原本から更新する
商品名、SKU、価格、税、在庫、画像、説明、販売期間、配送条件の原本を一つ決めます。EC本体、広告、商品フィード、モール、倉庫へ別々の表から入力すると、どれが正しいか分からなくなります。Google Merchant Centerの商品データ仕様でも、商品ページと価格・在庫状況を一致させ、予約や入荷待ちでは入荷予定日を扱うことが示されています。
- SKUを運用上の主キーにし、商品名だけで照合しない
- 価格、在庫、販売期間、配送条件は更新元と反映先を決める
- 画像・説明文・比較表の権利と根拠を商品票へ残す
- 変更依頼には開始日時、終了日時、承認者、戻し方を付ける
- 公開後に商品ページ、カート、最終確認、外部フィードを照合する
商品ページへ構造化データを出す場合は、Google Search CentralのProduct構造化データも参照し、表示している価格、通貨、在庫状況と矛盾させません。検索向けデータだけを正しくしても、購入画面が古ければ運用品質は上がりません。
日次業務は締め時刻と例外条件から決める
「毎日注文を見る」だけでは、いつまでに何を終えるかが不明です。開始時に障害・在庫連携・決済異常を確認し、注文締め時刻で未処理を確定し、欠品や住所不備を例外台帳へ移し、出荷後に売上・在庫・配送状態を照合します。最後に未解決を翌日の担当者へ引き継ぎます。
| 時点 | 確認 | 停止・連絡条件 |
|---|---|---|
| 営業開始 | サイト、決済、在庫連携、夜間注文 | 購入不能、決済多発失敗、連携停止 |
| 注文締め | 入金、住所、在庫、出荷対象 | 欠品、不正疑い、高額注文、住所不明 |
| 出荷後 | 送り状、通知、在庫減算、保留注文 | 未通知、二重出荷、引当差異 |
| 営業終了 | 売上、注文数、返金、問い合わせ、例外 | 数字不一致、期限超過、未承認返金 |
| 引き継ぎ | 担当、次の期限、顧客連絡、証拠 | 所有者不明の未解決案件 |
受注から出荷までを状態で管理する
注文番号ごとに、未入金、確認中、出荷待ち、出荷済み、保留、キャンセル、返品、返金等の状態を定義します。「対応中」という自由記述だけでは、次の作業と期限を機械的に拾えません。状態が変わる条件、変更できる担当、顧客通知、在庫への影響を一組にします。
欠品、配送先不明、決済保留、予約商品混在、分割出荷、受取拒否などは通常フローから外し、例外台帳へ移します。台帳には注文番号、事実、顧客へ伝えた内容、判断者、次の期限を残します。顧客のカード番号やパスワード等をコピーしてはいけません。
返品・返金は受付、検品、承認、在庫を分ける
返品連絡を受けた時点で返金完了にせず、受付、返送待ち、到着、検品、承認、返金、在庫反映を分けます。WooCommerceの注文管理の公式資料も、注文状態、個別注文、個人データ削除、テスト、トラブル対応を分けて案内しています。利用するEC基盤の仕様に合わせ、誰が次の状態へ進められるかを決めます。
消費者庁の通信販売広告Q&Aでは、返品特約を広告と最終確認画面へ明瞭に表示する考え方が示されています。運用代行会社が独自判断で返品条件を書き換えず、承認済みの条件と実際の案内を一致させます。不良、誤配送、顧客都合、配送事故を分類し、送料負担、再販売可否、返金方法を記録します。
販促は公開前の四者照合で止める
セール、クーポン、ポイント、送料無料、広告は、商品ページ、カート、最終確認画面、広告・配信面の四者を照合します。消費者庁の通信販売のガイドラインでは、最終確認画面で申込内容を容易に確認・訂正できることや、一定事項の表示が求められています。バナーだけを差し替え、購入条件や終了日時が一致しない状態で公開しません。
| 項目 | 確定内容 | 確認場所 |
|---|---|---|
| 対象 | SKU、除外商品、在庫下限 | 商品原本とEC設定 |
| 条件 | 価格、割引、最低金額、併用可否 | 商品、カート、最終確認 |
| 期間 | 開始・終了・タイムゾーン | EC、広告、メール |
| 採算 | 原価、送料、決済、広告、返品影響 | 承認者の計算票 |
| 停止 | 在庫、障害、誤表示時の停止担当 | 緊急連絡表 |
| 受入 | テスト注文、表示、通知、計測 | 証拠URLと注文番号 |
広告とSEOを含む費用配分はSEOと広告の予算配分で、同じ粗利と成果分母を使って判断します。運用代行の月額費と広告費を混ぜず、実行費、媒体費、制作費、ツール費を分けます。
顧客対応は一次返信と最終判断を分ける
問い合わせは、商品、在庫、配送、注文変更、返品、不良、決済、会員情報、法人取引、苦情に分類します。委託先は受領連絡、事実確認、定型案内までを担当し、高額補償、法的主張、安全性、個人情報、SNS炎上等は責任者へ上げます。返信速度だけをKPIにすると、事実確認前の断定や過剰な約束が増えます。
- 一次返信期限と、解決期限を別にする
- 顧客の質問、確認した事実、回答、次の期限を一つの履歴にする
- 注文番号以外の秘密情報をメールやチャットへ複製しない
- 同じ原因が三件以上続いたら、個別返信から商品・配送・表示の改善へ移す
- 公開レビューへの返信は、個別注文の情報を出さず承認済みの方針に従う
権限は作業に必要な範囲だけ付ける
商品登録担当へ返金やユーザー管理、顧客対応担当へテーマコードや請求管理まで付ける必要はありません。WordPress.orgの役割と権限の公式資料でも、管理者、編集者、投稿者等で許可される操作が異なります。実際には利用中のEC基盤で、個別ID、多要素認証、最小権限、期限、退職・契約終了時の停止手順を確認します。
ECサイトには注文・顧客情報があるため、保守とセキュリティを作業外にしません。IPAのECサイト構築・運用セキュリティガイドラインは、経営者、実務担当者、外部委託先を対象に、運用時の対策と契約上の確認を整理しています。診断を計画する場合はWeb脆弱性診断の発注手順で通常運用と範囲を分けます。
事故の疑いは通常運用から切り離す
未知の管理者、注文情報の外部公開、不正な決済変更、改ざん、マルウェア警告、顧客への不審メール等があれば、商品更新や販促の通常フローを止めます。ログやアカウントを削除せず、発見時刻、対象、画面、通知、変更履歴を保全し、責任者、EC基盤、決済、保守・セキュリティ担当へ安全な経路で連絡します。
個人情報保護委員会の漏えい等の対応資料で、報告が必要な場合と最新の報告先を確認します。事故対応はWebサイトのインシデント対応手順へ移し、代行会社だけで公表要否や顧客通知を決めません。
KPIは売上と滞留を一緒に見る
売上、注文数、客単価だけでは、運用が詰まっている場所を判断できません。出荷期限超過、在庫差異、商品データ不一致、一次返信遅延、未承認返金、例外案件の滞留日数を併記します。売上が伸びても欠品キャンセルや返金が増えていれば、成功とは言えません。
| 指標 | 確認する問い | 次の行動 |
|---|---|---|
| 在庫差異 | ECと実在庫がずれたSKUは何件か | 連携、締め時刻、手入力を直す |
| 出荷期限超過 | どの理由で止まったか | 例外条件と担当を見直す |
| 一次返信遅延 | 分類別にどこが滞留したか | 定型文か判断者を補う |
| 返品・返金滞留 | 受付から完了まで何日か | 検品と承認を分ける |
| 商品データ不一致 | 価格・在庫・期間が何面で違ったか | 原本と公開後照合を直す |
| 粗利後の獲得効率 | 販促が利益を残したか | 対象、条件、配分を変える |
購入率が下がった理由を調べる時は、運用代行の作業量だけで結論を出さず、問い合わせ・購入が来ない原因の診断で流入、訴求、導線、フォーム、計測を分けます。
日次の運用ループと引き継ぎを受入条件にする
契約開始時は、いきなり全領域を渡しません。商品登録だけ、受注・出荷だけ、問い合わせだけ等、一つの流れで二週間から一か月試し、例外と承認待ちを記録します。処理件数より、期限内完了、差異、再作業、所有者不明の案件が減ったかで判断します。
| 確認 | 合格条件 | 未達なら |
|---|---|---|
| 範囲 | 対象・対象外・締め時刻が一覧化 | 契約と手順を直す |
| 権限 | 個別ID、最小権限、停止方法がある | アクセスを広げない |
| 例外 | 欠品・返金・事故の判断者と期限がある | 通常フローへ入れない |
| 証拠 | 注文番号、差分、承認、公開後確認が追える | 完了扱いにしない |
| 引き継ぎ | 自社が原本、アカウント、履歴を回収できる | 属人化を解消する |
| 終了 | 権限停止、未処理、データ返却を確認 | 契約終了にしない |
商品登録やキャンペーンページなど更新実行の依頼方法はホームページ更新方法の選び方へ分けます。EC運用では、その更新が在庫、注文、顧客案内、広告、計測へどう連動するかまで受入対象にします。
まとめ
EC運用代行を止まらない仕組みにするには、商品、在庫、注文、出荷、返品、販促、顧客対応ごとに、委託先の実行、自社の承認、締め時刻、例外条件、完了証拠を決めます。商品情報は一つの原本から更新し、注文と返品は状態で管理し、販促は商品ページ・カート・最終確認・広告面を照合します。
権限は個別IDと最小権限にし、事故の疑いは通常運用から切り離します。売上だけでなく、在庫差異、期限超過、返信遅延、返金滞留、商品データ不一致を見れば、外注した作業量ではなく、業務が本当に安定したかを判断できます。
現在の受注・在庫・出荷・顧客対応をどこまで任せるか整理したい場合は、ホームページ保守・運用の支援範囲をご確認ください。利用中のEC基盤、月間注文数、止まっている業務、社内の承認者を分かる範囲でまとめ、お問い合わせページからご相談いただけます。顧客情報、パスワード、カード情報は送らないでください。
