↗付きの用語リンクは、別タブで説明を開きます。
EC担当者が交代するとき、管理画面にログインできるようにしただけでは、運営を引き継いだことにはなりません。出荷待ちの注文、取引先への確認、返金判断、倉庫への締切連絡など、画面に表れにくい仕事が残っていることがあります。
担当者が変わっても受注・出荷業務を継続できるよう、引継ぎ前後の確認手順を整理します。外部倉庫と自社出荷の優劣ではなく、次の担当者が判断と作業を引き受けられる状態を整えることが目的です。
結論:未完了の仕事から引き継ぐ
引き継ぎ資料はサービス一覧から作りがちですが、最初に見るべきなのは「今日、誰かが対応しなければ止まる仕事」です。発送期限が近い注文、欠品の連絡、入金確認、返金、仕入先への発注などを期限順に並べます。
各案件について、現在の状態、次の操作、判断する人、締切、確認先を残します。資料を渡したという記録だけでなく、引受側が内容を確認したかまで管理します。定型業務のマニュアルは、その後で代表的な処理から揃えても構いません。
急な欠員の場合は、責任者が暫定の窓口と優先順位を決めます。不明な発送や返金を推測で実行するのではなく、止める範囲、顧客へ案内する内容、確認期限を明確にします。
業務・担当・正本を対応させる
以下は、引き継ぎ台帳の構成例です。担当欄には人名だけでなく役割を併記しておくと、将来の変更時にも読み直しやすくなります。正本とは、その情報について最終的な確認元とする記録のことです。
| 業務 | 引き継ぐ内容 | 引受確認の例 |
|---|---|---|
| 受注確認 | 取得先、確認待ち、決済状況、例外注文 | 未処理一覧の件数と各状態を照合できる |
| 出荷 | 担当倉庫、締切、送り状、出荷確定、追跡反映 | 注文から発送通知までの担当が途切れない |
| 在庫・補充 | 実在庫、販売可能数、引当済み、発注残 | 在庫を増減させる処理と確認元を説明できる |
| 顧客対応 | 回答待ち、返品・返金、過去の合意 | 次の返信期限と承認者を確認できる |
| 商品・販促 | 公開予定、価格変更、広告・クーポンの期間 | 変更予定と終了後の戻し作業が分かる |
| サービス管理 | 契約窓口、管理者、請求、権限、通知先 | 自分のアカウントで必要な作業ができる |
OMS(受注管理システム)に注文が集まっていても、倉庫への個別依頼や顧客とのメールが別の場所にある場合があります。「管理画面を見れば分かる」で終わらせず、どこまでがシステムの記録で、どこからが別管理かを確認します。
出荷の責任が切れる地点をなくす
物流では、送り状を発行したことと、荷物が運送会社へ渡ったことは同じではありません。引き継ぎでは、出荷指示、商品の準備、梱包、送り状発行、引き渡し、出荷確定、追跡番号の反映を分けて確認します。
例えば、旧担当者が送り状を発行し、新担当者が梱包を担当する場合、印刷済み伝票だけを見て「発送済み」と判断すると未出荷を見逃します。反対に、処理状況が分からず送り状を作り直すと、二重発送の原因になります。注文番号を軸に、実際の引き渡し状況とシステムの状態を照合します。
外部倉庫を使っている場合も、倉庫側が対応する範囲と、店舗側が承認・連絡する範囲を分けます。住所変更、キャンセル、同梱、欠品、締切後の依頼は、通常注文とは別の確認先が必要なことがあります。具体的な例外の整理には、受注・出荷の例外処理チェックを利用できます。
権限は渡す前と止める前の両方で確認する
担当者交代を理由に、旧担当者のIDとパスワードを共有する運用へ戻さないようにします。サービスが個別ユーザーに対応している場合は、新担当者のアカウントを用意し、必要な役割・操作範囲を設定します。たとえばShopifyは、ユーザーと役割を通じて管理画面のアクセスを管理する仕組みを提供しています。Shopify公式:ユーザー管理。
確認表には、管理者、復旧用連絡先の管理責任者、多要素認証の引き継ぎ方法、請求通知先、連携アプリの管理者を記録します。パスワード、認証コード、APIキーそのものは台帳へ書かず、安全な管理方法を使います。
旧アカウントの停止と同時に、メール転送、自動処理、共有ファイルへのアクセスが止まる場合があります。停止前に依存関係を調べ、責任者が決めた期限と手順で移管・権限見直しを進めます。引き継ぎのために不要なアクセスを無期限で残すことも避けます。契約や個人情報の取り扱いは、会社の管理責任者へ確認してください。
代表注文で引受テストをする
すべての注文を再現する必要はありませんが、通常注文一つだけでは例外の対応力を確認できません。自社で頻度や影響が大きいケースを選び、テスト環境や承認済みの方法で、確認先と判断手順をたどります。実注文を無断で変更・取消したり、検証のために顧客へ通知したりしないようにします。
- 通常注文:在庫確認から発送通知まで、担当と確認元が分かるか。
- 欠品注文:販売停止、購入者への案内、返金を誰が判断するか。
- 出荷前の変更:倉庫への指示が取り消せる段階かを確認できるか。
- 出荷通知の失敗:実出荷を確認してから、重複しない方法で再処理できるか。
- 返品:到着、商品の状態、販売可能な在庫への戻し、返金を区別できるか。
結果は「操作できた」「権限不足」「手順不明」「外部回答待ち」などに分けます。問題が残った場合は引き継ぎ完了にせず、暫定対応者と解消期限を付けます。操作時間の短さより、止まったときに誰へ何を確認するかが分かることを重視します。
体制別に確認の深さを変える
一人運営では、病欠や休暇でも受注状況と連絡先を確認できる代理者を決めることが先です。複数担当では、作業する人と承認する人を分け、担当の境界で確認が抜けないようにします。外部倉庫や制作会社が関わる場合は、連絡窓口だけでなく、依頼を受け付ける条件と営業時間も確認します。
担当交代とシステム変更、物流移転を同時に行うと、不具合の原因が分かりにくくなります。可能であれば変更を分け、まず現行運用を引き受けてから改善します。物流方式そのものの見直しは、本記事の引き継ぎ確認とは別の判断として扱います。
引き継ぎ後も未完了一覧を照合する
切替後の最初の営業日、最初の繁忙日、締め処理など、自社の業務に合わせた確認日を決めます。注文残、出荷未反映、顧客回答待ち、発注残を見直し、旧担当者にしか分からない作業が残っていないかを確認します。
ここで見つかった不足は、引き継ぎ資料の問題として直します。個人の記憶に頼って補うだけでは、次の交代でも同じ問題が起こります。台帳には最終確認日と更新担当を残し、手順変更のたびに更新します。
まとめ
ECの担当者変更では、未完了案件、業務の境界、情報の正本、権限、例外時の判断をセットで引き継ぎます。資料を渡すだけでなく、新担当者が状況を確認し、必要な判断と連絡を行えることまで確かめます。自社の運営体制に合わせて、止められない業務から順に整理することが大切です。
