小規模ECの業務引き継ぎでは、「何の業務があるか」を伝えるだけでなく、次の担当者が受注・発送・在庫・問い合わせなどを自分で実行できる手順書を残すことが重要です。一人運営では、作業の進め方に加え、判断基準や外部の連絡先まで担当者本人に集中しやすいためです。
最初からすべての作業を文書化する必要はありません。まずは注文・発送・問い合わせなど、その日止まると顧客に影響する業務を優先し、「開始条件・操作手順・完了条件・例外対応・確認先」を書き出します。
この記事では、一人運営のECショップを次の担当者へ安全に引き継ぐための8ステップ、業務手順書テンプレート、未処理案件一覧、日次チェックリスト、引き継ぎテストを具体例付きで解説します。
- 業務手順書は「どう作業するか」、引き継ぎ資料は「現在、何を誰が引き受けるか」を整理する。
- 業務を毎日・毎週・毎月・不定期に分け、受注・発送・問い合わせから手順化する。
- 各手順に開始条件、操作、判断基準、停止条件、完了条件、連絡先を記録する。
- キャンセル・欠品・決済保留などの例外対応と、進行中の未処理案件を別に残す。
- パスワードを手順書に書かず、新担当者のアカウント・権限を安全に整備する。
- 最後は「前任者が操作せず、主要業務を1日回せるか」で引き継ぎを検証する。
小規模ECの一人運営で引き継ぎが難しい理由
一人でネットショップを運営していると、受注確認、決済、在庫、梱包、発送、問い合わせ、返品、商品登録を同じ人が担当することがあります。担当者本人は自然に処理できても、別の人には「どの画面で何を確認し、何を基準に判断するか」が分かりません。
問題は操作方法だけではありません。欠品時に販売を止めるか、返金額を誰が決めるか、システム障害時にどこへ連絡するかといった判断と権限の属人化も、引き継ぎを難しくします。
| 属人化している状態 | 引き継ぎ後に起こりやすいこと | 必要な資料 |
|---|---|---|
| 画面操作を本人しか知らない | 注文・発送処理が進まない | 操作手順書 |
| 判断条件が共有されていない | キャンセルや返金で対応がばらつく | 判断基準・例外処理表 |
| 外部の連絡先が分からない | 倉庫や決済会社への確認が遅れる | 連絡先・契約一覧 |
| 進行中の案件が見えない | 未発送・未返金を見落とす | 未処理案件一覧 |
| 権限が前任者に集中している | 新担当者が必要な画面を開けない | アクセス権限台帳 |
業務マニュアルと引き継ぎ資料は役割が違う
業務マニュアルは繰り返し使う作業方法、引き継ぎ資料は担当変更時点の現状を整理します。1つの文書にすべてを書き込むと、未処理案件など更新頻度の高い情報が埋もれやすくなります。
- 業務手順書:毎回使う操作方法と判断基準
- 引き継ぎ台帳:担当・ツール・権限・連絡先・未処理案件
- 日次チェックリスト:その日に実行・確認すべきこと
業務マニュアル全体の設計は、EC運営マニュアルの作り方|属人化を防ぐ実践手順とテンプレートも参考になります。
最初に作る業務一覧と優先順位
まず、現担当者が行っている作業を一覧にします。記憶だけで作ると細かな確認や例外処理が抜けやすいため、実際の1営業日を朝から記録し、週次・月次・不定期の業務を追加すると整理しやすくなります。
| 頻度 | 主な業務例 | 引き継ぎで確認すること |
|---|---|---|
| 毎日 | 受注、決済保留、出荷、問い合わせ、欠品確認 | 締切・未処理の見つけ方・停止条件 |
| 毎週 | 在庫差異、返品残件、売上集計、再発注 | 確認日・集計元・差異対応 |
| 毎月 | 売上・入金照合、棚卸し、ツール請求、実績レビュー | 担当者・締切・確認先 |
| 不定期 | 商品登録、価格変更、障害、クレーム、キャンペーン | 承認者・影響範囲・復旧方法 |
文書化の優先順位は「止まったときの影響」で決める
すべてを同じ詳しさでまとめる必要はありません。優先度は作業時間の長さではなく、止めたときに顧客・売上・個人情報・決済へ与える影響で決めます。
| 優先度 | 判断の目安 | 業務例 |
|---|---|---|
| 高 | 当日止まると顧客や取引に直接影響 | 決済確認、受注、発送、問い合わせ、重大な障害 |
| 中 | 数日以内の対応が必要 | 棚卸し、仕入調整、定例集計、返品の進捗確認 |
| 低 | 後から対応・再作成できる | 急ぎでない販促素材、通常時のページ微調整 |
※上の分類は一般的な例です。生鮮品や予約販売など、商材によって優先順位は変わります。
別の人が迷わず使える業務手順書の書き方
「毎朝、注文を確認する」と書くだけでは引き継ぎには不十分です。手順書は、初めて担当する人が同じ条件で同じ結果まで進められるように作ります。
最低限記載したい8項目
| 項目 | 書く内容 |
|---|---|
| 業務名・目的 | 何を達成し、どのミスを防ぐか |
| 担当・代替担当 | 通常担当者と不在時の連絡先 |
| 開始条件・期限 | いつ着手し、いつまでに処理するか |
| 使用ツール | システム名と画面メニュー |
| 通常手順 | 検索条件、確認項目、操作順序 |
| 停止・例外条件 | 作業を進めない状態と対応先 |
| 完了条件・記録 | どの状態になれば完了か、履歴をどこへ残すか |
| 版管理 | 作成日、更新日、更新者、対象システム |
記入例:当日発送対象の注文確認
業務名:当日発送対象の注文を確定する
開始条件:毎営業日、店舗で定めた受注確認時間になったとき
使用ツール:EC受注管理画面 → 注文一覧 → 未発送
- 当日の出荷締切に該当する注文を絞り込む。
- 注文番号・SKU・数量・決済状態・配送先を照合する。
- 決済保留、住所不備、欠品、不正注文の疑いがある注文は保留する。
- 条件を満たす注文のみ出荷対象として確定し、倉庫へ指示する。
- 出荷指示の受付結果と注文ステータスを確認する。
完了条件:出荷対象がすべて確定し、保留注文には理由・次の対応・担当者が記録されていること。
例外時:決済・在庫・住所の不一致は原因が解消するまで出荷しない。判断できない場合は所定の責任者へ確認する。
※時刻や画面メニューはショップ・システムの実態に合わせて変更してください。
スクリーンショットは操作の意味とセットにする
画面画像だけでは、ECカートのUI変更時に使えなくなることがあります。「どこを見るか」「どの値を確認するか」「何を操作するか」を文章でも残し、機密情報や顧客情報が写っている場合は伏せて保存します。
受注・発送・在庫・問い合わせ・返品で引き継ぐ内容
受注・決済:出荷してよい注文を判断できるようにする
注文ステータスと決済ステータスの意味を整理し、通常注文と保留注文を区別します。注文変更・キャンセル・不正注文の疑いに対して、誰がどの段階まで対応できるかも記載します。
- 注文確認の頻度、対象の絞り込み条件、出荷締切
- 決済確定・未決済・保留・返金済みの区別
- キャンセル可能な段階と、倉庫・配送会社との連絡方法
- 住所変更、欠品、二重注文、不正注文疑いの停止条件
不正注文についてはEC不正注文対策の実務手順も参照してください。
発送:締切・確認項目・完了処理を揃える
商品SKU、色・サイズ、数量、同梱物、配送方法、送り状、追跡番号の確認方法を書きます。「倉庫へデータ送信できた」だけで完了とせず、出荷状態と発送通知の反映まで確認します。
日々の誤発送を防ぐチェック項目は、EC発送チェックリスト|誤発送・同梱漏れを防ぐ確認表で詳しく解説しています。
在庫:どの数字を基準とするかを明確にする
基準在庫を管理するシステム、販売可能数の計算方法、入荷・返品・棚卸しの反映方法を明示します。複数モールや倉庫がある場合、在庫同期が止まった際の連絡先と一時停止条件も残しておきます。
在庫が一致しない場合は、EC在庫差異が起こる原因と防止手順も参考になります。
問い合わせ:返信文だけでなく判断基準を残す
問い合わせの確認頻度、使用する共有窓口、返信目安、返信テンプレート、注文変更や返金の権限を記録します。返信テンプレートは「いつ使うか」という条件とセットにすると引き継ぎやすくなります。
返品・返金:受付から案件完了まで状態を区別する
返品は「受付 → 条件の確認 → 返送案内 → 受領・検品 → 返金・交換 → 在庫更新 → 完了連絡」の順に記載します。購入時に表示していた返品条件や販売チャネルの規約も確認します。返品品を検品前に販売可能在庫へ戻さないことが重要です。
実際の業務フローはEC返品・返金対応マニュアル|受付から返金までの手順を参考にしてください。
商品登録・販促・経理:頻度が低くても変更権限を明確にする
商品名・SKU・価格・カテゴリー・画像・SEO項目の登録ルールをまとめます。クーポンやキャンペーンは設定時刻・終了条件・承認者まで残します。決済入金や請求書の確認も、締切と担当者を定めておきます。
例外処理は「条件 → 止めること → 次の対応」で書く
| 状態 | 止める・保留すること | 次の対応 |
|---|---|---|
| 住所不備 | 出荷確定 | 顧客へ必要な確認を依頼し履歴を記録 |
| 決済保留 | 未確定注文の出荷 | 決済管理画面で確認し、解消後に判断 |
| 在庫不足 | 不足商品の追加販売・出荷 | 実在庫を照合し、必要なら顧客へ連絡 |
| 配送事故 | 原因未確認の再発送 | 追跡履歴と配送会社への照会を記録 |
| 返品・交換 | 条件未確認の返金・在庫戻し | 購入時条件・商品状態・決済を照合 |
| 管理画面障害 | 二重操作や再送 | 障害状況を確認し、復旧・再処理の判断者へ連絡 |
利用ツール・アカウント・契約・外部連絡先の引き継ぎ
手順書があっても、作業に必要なシステムへ入れなければ運営は止まります。ECカート、決済、受注管理、配送、問い合わせ、広告、解析、ドメイン、サーバーなどの契約・管理者情報を整理してください。
| 用途 | 管理対象 | 引き継ぐ情報 |
|---|---|---|
| EC運営 | ECカート・モール | 管理責任者、担当権限、サポート窓口 |
| 決済 | 決済代行サービス | 照合・返金の権限、障害連絡先 |
| 出荷 | 倉庫・送り状・配送 | 締切、契約番号の保管先、問合せ窓口 |
| 顧客対応 | メール・問い合わせ管理 | 共有窓口、担当割当、テンプレート保存先 |
| サイト管理 | ドメイン・サーバー・WordPress | 契約更新担当、バックアップ、障害時の連絡先 |
| 経理 | 会計・請求・入金確認 | 締切、照合方法、確認責任者 |
パスワードや個人情報を手順書に貼り付けない
「管理画面のログインIDとパスワードを一覧表に書く」方法は避けます。新担当者専用のアカウントを作り、必要な操作だけを許可する権限設定を行います。認証情報は承認されたパスワード管理方法で別管理し、利用可能なサービスでは多要素認証(MFA)を有効にします。
- 管理者パスワード・APIキー・決済情報を通常の手順書に記載しない。
- 顧客の氏名・住所・連絡先を一般的な研修用資料へコピーしない。
- 前任者のアクセス権は、引き継ぎ後の業務継続を確認して適切な時期に無効化する。
- 契約者本人の個人名義サービスは、契約条件を確認して正規の移管方法を検討する。
日本の個人情報保護委員会は、事業規模や取り扱う情報のリスクに応じた安全管理措置を求めています。また、米国NISTの小規模事業者向け基本対策でも、多要素認証・強いパスワード・バックアップ等が推奨されています。参考:個人情報保護委員会:個人情報保護法ガイドライン、NIST:Cybersecurity Basics。
外部連絡先には「いつ連絡するか」まで残す
倉庫、配送会社、仕入先、決済会社、ECサービス、制作会社、税務・会計担当の窓口と受付時間を記録します。担当者名だけでなく、緊急窓口、問い合わせ番号の記録先、対応履歴の保存先も明確にします。
引き継ぎ当日に必要な未処理案件と緊急時対応
未処理案件は業務マニュアルと分けて管理する
手順書が完成していても、引き継ぎ当日時点で止まっている注文や返品は分かりません。引き継ぎ前日または当日に、対応中の案件を一覧化します。
| 案件(架空例) | 現在の状態 | 次の作業 | 期限・担当 |
|---|---|---|---|
| 注文A | 住所確認中 | 返信内容の確認後に出荷可否を判断 | 当日/受注担当 |
| 返品B | 返送待ち | 受領後に検品、返金可否を確認 | 到着時/CS担当 |
| 商品C | 在庫残数が発注点以下 | 仕入先へ納期を確認 | 翌営業日/在庫担当 |
| 障害D | 送り状連携エラー調査中 | 再送前に処理済みデータを照合 | 優先対応/管理者 |
※注文名・案件内容・期限は説明用の架空例です。実際の台帳には内部で決めた最小限の識別子を使い、閲覧権限を制限してください。
障害時は「被害の拡大防止 → 影響確認 → 復旧」の順で判断
決済障害や個人情報に関わる疑いがある場合、通常の出荷処理と同じ判断では対応できません。関係する操作を一時停止し、影響する注文・利用者・システムを把握して、決められた管理者や専門窓口へ連絡します。
- 重複決済・誤出荷などの被害拡大を防ぐ。
- 影響する注文と個人情報の有無を確認する。
- 管理責任者・決済会社・配送会社など必要な連絡先へ報告する。
- 原因と処理履歴を記録し、復旧方法を決める。
- 正常な状態を確認した後に販売・処理を再開する。
個人情報の漏えい等が疑われる場合は、法令や契約に基づく報告・本人通知の要否を責任者と確認してください。すべてのケースで同じ対応期限とは限りません。
小規模ECの業務引き継ぎを進める8ステップ
現在担当している作業を、受注・在庫・発送・CS・返品・商品・経理・システムに分けて記録します。
毎日・毎週・毎月・不定期に分類し、止まると困る受注・発送・問い合わせから着手します。
操作するメニュー、確認する項目、完了したと判断できる状態まで明文化します。
住所不備・欠品・決済保留・キャンセル・返品など、止める条件と連絡先を記載します。
必要なサービスのアカウント、管理者、外部窓口、権限付与・廃止の担当を確認します。
現在進行中の注文やトラブルを案件ごとにまとめ、新担当者の当日業務が分かる状態にします。
最初は前任者が説明し、次に新担当者が操作します。必要に応じて安全なテスト環境で例外も試します。
前任者なしでも運営できるかを確認し、曖昧だった説明・更新されていない画面操作を修正します。
コピーして使える引き継ぎテンプレート
テンプレート①:業務手順書
業務名:[例:受注確認・出荷対象の確定]
目的:[正しく処理するために防ぎたいミス]
担当・代替担当:[担当名または役割]
実施タイミング:[毎営業日/締切条件]
開始条件:[注文状態・発生イベントなど]
利用ツール・画面:[サービス名/メニュー名]
操作手順:[1. 対象を絞る 2. 内容を照合する 3. 処理する 4. 結果を記録する]
停止条件:[例:決済未確定、在庫不一致]
例外時の対応・確認先:[担当者・連絡方法]
完了条件:[画面上の状態と記録場所]
更新履歴:[更新日・更新者・変更内容]
テンプレート②:引き継ぎ台帳と未処理案件一覧
業務の現在状態を共有する資料には、最低限「業務・現在状態・次の担当・期限・記録場所」を記載します。顧客の住所や支払情報そのものを台帳へ転記せず、権限のあるシステム内の注文番号などで参照できる形にしてください。
| 必須項目 | 記入例 |
|---|---|
| 業務・案件ID | 注文A/受注確認 |
| 進捗 | 住所確認待ち |
| 次の作業 | 顧客からの回答を確認する |
| 担当・期限 | 受注担当/当日 |
| 詳細の保存先 | 受注管理画面の案件履歴 |
| 連絡・承認先 | 店舗責任者/所定の共有窓口 |
テンプレート③:日次・週次・月次チェックリスト
| 頻度 | 確認項目の例 |
|---|---|
| 日次 | 新規注文、決済保留、未発送、欠品、問い合わせ、返品、発送通知 |
| 週次 | 未処理案件、在庫差異、返金残件、配送ミス、対応期限超過 |
| 月次 | 売上・入金照合、棚卸し、サービス請求、権限一覧、手順書更新 |
日次チェックリストは1画面または1枚で使える長さに抑え、「チェックした」だけでなく、未完了なら案件台帳へ理由と次の作業を記録する運用にします。
引き継ぎチェックリスト
- 毎日止められない業務が一覧化されている
- 受注・発送・在庫・問い合わせ・返品の手順書がある
- 開始条件・完了条件・期限・停止条件が明記されている
- 在庫・決済・キャンセルの判断者が分かる
- 外部の契約・連絡先と緊急窓口が確認できる
- 新担当者に必要なアカウントと権限が付与されている
- パスワードと個人情報が手順書へ直接記載されていない
- 未処理案件と日次チェックリストを引き渡した
- 新担当者が主要業務を実際に操作した
- 手順書の更新日・更新者・正式な保存先を記録した
- 前任者の不要な権限を適切に廃止する段取りがある
引き継ぎ完了の判断方法と運用KPI
「前任者なしで1日運営できるか」を試す
資料を渡しただけでは、実際に使えるか分かりません。新担当者が手順書を見ながら一連の作業を行い、前任者は必要な安全確認を除き操作せずに結果を確認します。
- 当日対象の注文を自分で見つけられるか。
- 決済・在庫・住所を照合し、出荷可能か判断できるか。
- 発送状況と顧客対応の未処理案件を確認できるか。
- 欠品や障害などの例外を適切に保留・報告できるか。
- 終業時に未処理案件と翌営業日の作業を記録できるか。
実際の注文で危険な処理を試す必要はありません。決済・返金・注文削除などの操作は権限やテスト環境を確認し、安全な条件で検証してください。
改善状況を確認する4つの指標
| 指標 | 確認方法 | 改善の狙い |
|---|---|---|
| 手順書だけで完了できた業務の割合 | 追加質問なしで完了した対象業務数 ÷ 検証した業務数 | 自走できる範囲を把握する |
| 判断の確認質問数 | 業務・期間別の質問件数 | 曖昧な判断基準を見つける |
| 未処理案件の期限超過数 | 期限を過ぎて未完了の案件数 | 顧客対応の漏れを防ぐ |
| 業務ミス・再処理件数 | 出荷・在庫・決済などで再処理した件数 | 手順やチェック方法を改善する |
※指標は自社で使う管理例です。集計対象、期間、業務難度をそろえて比較してください。数字が小さいことだけを目的に、必要な確認質問を省略しないようにします。
手順書は運営が変わったときに更新する
ECシステムの管理画面、配送契約、返品条件、責任者が変わったら手順書も修正します。正式版の保存先を1か所に決め、「最終更新日・更新者・変更内容」を残してください。古い版は誤って使われないようにします。
小規模ECの業務引き継ぎに関するよくある質問
一人運営でも業務手順書は必要ですか?
はい。担当者の休暇・病気・退職などで業務が止まらないよう、少なくとも受注・発送・問い合わせと緊急連絡先を文書化しておくと、代替対応を始めやすくなります。
最初にどの業務から引き継げばよいですか?
止まると顧客へ直接影響する業務から始めます。多くのECでは、決済確認、受注、発送、問い合わせ、欠品対応が優先候補です。商材や運営形態によって調整してください。
手順書と引き継ぎ資料を1つにまとめてもよいですか?
可能ですが、継続的に使う操作手順と、引き継ぎ時だけ更新する未処理案件・担当情報は分けた方が管理しやすい場合があります。資料同士のリンクを整える方法も有効です。
パスワードや顧客情報も引き継ぎ資料に書くべきですか?
手順書へ平文のパスワードや顧客の詳細情報を記載する方法は避けましょう。新担当者用のアカウントを発行し、必要な権限を付与します。案件は権限のあるシステム内の情報へ参照できる形で管理します。
引き継ぎが完了したとどう判断しますか?
新担当者が手順書を見て主要業務を処理し、例外が起きたときに停止・確認・報告を判断できる状態が一つの目安です。初日や最初の1週間で出た質問をもとに手順書を更新しましょう。
業務手順書はどれくらいの頻度で見直しますか?
画面仕様、運用ルール、担当、外部連絡先の変更時には見直します。それとは別に、定期的な業務点検や新担当者の質問をきっかけに更新する運用が効果的です。
まとめ|「自分が不在でも1日運営できる状態」を作る
小規模ECの引き継ぎで重要なのは、分厚い手順書の作成ではなく、担当者が変わっても受注・発送・問い合わせなどの重要業務を同じ判断基準で実行できる状態です。
まず現在の1日分の作業を書き出し、止められない業務を選びます。次に開始・完了条件、例外処理、権限、外部連絡先を残し、未処理案件を引き渡します。最後に新担当者が手順書だけで実際に処理できるか確認してください。
- 明日の受注・発送・問い合わせの作業を一覧にする。
- 最も止められない業務を1つ選び、開始条件・完了条件・例外処理を書く。
- 別の人に手順書を読んでもらい、分からない部分を修正する。
本記事の業務表・案件・担当者・操作例は説明用の例です。実際の操作名、運用期限、権限設定、法令・契約条件は利用サービスや事業の状況に合わせて確認してください。
