EC受注処理とは、注文受付から注文内容・決済・在庫・配送先の確認、在庫引当、出荷、発送通知までを一続きで管理する業務です。誤出荷や売り越しを減らすには、処理の順序だけでなく、在庫を更新する時点、例外対応の履歴、担当者間の共有方法まで決めておく必要があります。
この記事では、ネットショップ運営者向けに、通常の受注フローからキャンセル・返品・問い合わせへの対応、複数チャネルで一元管理や自動化を検討する判断基準までを整理します。
EC受注処理とは？注文受付から出荷通知までを一つの流れで管理する業務
EC受注処理は、注文を受けて終わる業務ではありません。注文情報を確定し、決済状況と在庫を確認したうえで出荷につなげ、出荷完了を顧客へ通知するまでが基本の範囲です。自社で梱包・発送する場合も、外部倉庫へ出荷指示を出す場合も、注文を正確に引き継ぐという考え方は共通します。
受注経路がECカートに限らず、電話・FAX・メールなどに広がる場合も、受け付けた内容を同じ管理対象に載せることが重要です。受注方法ごとに別の台帳や担当者の記憶で処理すると、在庫や出荷状況が分かれ、二重処理や対応漏れにつながります。
注文受付から出荷完了通知までの標準フロー
注文受付から出荷完了通知までは、次の順序で処理します。小規模な店舗で一人が複数工程を担当する場合でも、各工程の確認項目と完了条件は分けて記録します。
- 注文を受け付ける
ECカートやモールから注文を取り込みます。電話・FAX・メールで受けた注文は、商品、数量、購入者、配送先、支払方法などを確認し、管理台帳や受注管理画面に登録します。内容に不足や確認待ちがある間は確定注文にせず、確認が完了して処理可能になった時点で、注文番号や受付日時とともに記録します。
- 注文を確定し、内容と決済を確認する
商品・数量・SKU、配送先、配送希望、支払方法、決済状況を確認します。前払いなど、入金確認が出荷可否に関わる決済では、入金済みか確認待ちかを出荷判定に反映させます。住所変更や配送希望などの個別対応がある場合は、注文情報と対応履歴の両方に残します。
- 在庫を引き当てる
注文を確定したら、販売可能な在庫を注文に割り当てます。同じ在庫を複数チャネルで販売している場合は、注文確定や在庫引当の情報を他のチャネルにも反映し、別の注文に同じ在庫を割り当てない状態を作ります。
- 出荷を指示する
自社出荷なら、ピッキング対象、商品、数量、配送先、配送方法を出荷担当へ渡します。外部倉庫を利用する場合は、同じ情報を倉庫への出荷指示として連携し、処理結果を受注側のステータスへ戻します。
- 検品・梱包し、帳票を作成する
受注情報と現物の商品・数量を照合します。商材に合った梱包方法と配送方法になっているかも確認し、送り状や納品書を受注データから作成します。手入力や転記を減らすほど、住所・数量・配送方法の誤りを抑えやすくなります。
- 出荷を確定し、顧客へ通知する
荷物を引き渡した時点で出荷を確定し、発送日や追跡に必要な情報を顧客へ案内します。「出荷準備中」と「出荷済み」を区別し、まだ発送していない段階で発送通知を送らないようにします。
この基本的な流れは、ネットショップの受注から配送までの業務や、複数チャネルの受注を集約する考え方にも共通します。電話・FAX・メールの注文も、内容確認後に受注管理対象として登録し、ECカートからの注文と同じ流れに載せることがポイントです。
受注情報・在庫・出荷を正確につなぐ管理ポイント
誤出荷や売り越しは、注文、在庫、出荷の情報が別々に更新されると起きやすくなります。受注単位で情報をそろえ、どの処理をきっかけに在庫やステータスを更新するかを決めておくことが、正確な運用の土台です。
受注管理では注文内容や顧客情報、支払方法、配送状況を一覧で確認できる状態が重要です。さらに、在庫の変動と帳票の作成を同じ受注データからつなぐと、転記によるミスと確認作業を減らせます。
注文ごとに確認・記録する情報
受注ごとに、少なくとも次の情報を同じ記録にひも付けます。
| 管理項目 | 確認する内容 |
|---|---|
| 注文の識別情報 | 注文番号、受付日時、販売チャネル、注文ステータス |
| 商品情報 | 商品名、SKU、数量、セット内容、商品ごとの出荷条件 |
| 購入者情報 | 氏名、連絡先、購入者と届け先の関係 |
| 配送情報 | 配送先、配送希望、配送方法、追跡情報、出荷状況 |
| 決済情報 | 支払方法、決済状況、入金確認の要否 |
| 対応履歴 | 問い合わせ、変更、キャンセル、返品、返金・交換に関する記録 |
購入者情報と配送先は別項目として扱います。贈答などで両者が異なる場合、購入者への連絡先と配送先を混同すると通知や出荷を誤るためです。
支払方法も、単なる注文情報ではなく出荷可否を判断する項目です。決済が確認できるまで出荷しない運用なら、「注文受付済み」と「出荷可能」を同じ状態にせず、決済状況を独立して管理します。
在庫引当と更新のタイミングを決める
在庫の扱いは、注文確定時に引き当て、出荷時に実在庫を減らすというように、処理の意味を分けて定義します。店舗の運用に合わせて「販売可能数」「引当済み」「出荷済み」を混同しないことが重要です。
| 時点 | 在庫の扱い |
|---|---|
| 注文確定 | 販売可能な在庫を注文に引き当て、他の注文へ重複して割り当てない |
| 出荷確定 | 出荷した数量を実在庫から減らし、出荷結果を受注へ反映する |
| 出荷前キャンセル | 引当を解除し、販売可能な在庫へ戻す。決済や別の保留条件があれば、その状態も記録する |
| 返品受領 | 返品された商品を検品し、再販売できるものだけを販売可能在庫へ戻す |
| 入荷 | 検品・受け入れが完了した数量を在庫へ加える |
| 棚卸 | 実在庫との差異を確認し、差異の理由と調整内容を履歴に残す |
キャンセルや返品で在庫を戻す場合も、処理を受け付けた時点で自動的に販売可能へ戻せるとは限りません。返品商品の状態確認や返金処理など、店舗のルールに応じて戻す条件を決めます。
複数モール、自社EC、実店舗で同じ在庫を販売する場合は、在庫数を更新する場所と各チャネルへ反映する方法を統一します。注文確定、出荷、キャンセル、返品、入荷、棚卸のどの操作が在庫を変えるのかを明確にしないと、チャネル間の在庫ズレ、売り越し、欠品、誤出荷が発生しやすくなります。
出荷指示・送り状・納品書を受注データからつなぐ
受注データを出荷指示、送り状、納品書へ同じ内容のまま引き継ぐと、転記による入力ミスを減らせます。連携対象は、少なくとも商品、数量、配送先、配送方法、注文番号です。帳票に出力した情報と受注画面の情報が異なる場合は、出荷前に差異を確認できる手順も必要です。
自社出荷では、受注データからピッキングリストや納品書を作成し、現物と注文情報を照合してから梱包します。外部倉庫を利用する場合は、受注データを出荷指示として渡し、倉庫から返された出荷結果、送り状番号、出荷日時を受注ステータスへ反映します。
出荷指示を出した時点と、実際に出荷が完了した時点は別のステータスとして管理します。ここが分断されると、倉庫では出荷済みなのに受注側は未処理のまま、または顧客へ追跡番号を案内できないといった問題が起きます。
顧客通知と例外対応を止めない受注処理の運用
通常の注文では、注文受付、出荷準備、出荷完了という状態に応じて処理を進めます。しかし、問い合わせやキャンセル、返品が発生すると、注文の現在地、決済、在庫、配送の状況を同時に確認しなければなりません。
例外対応を担当者の記憶や個人メールだけで処理すると、担当者が不在になったときに対応が止まります。注文ステータスと対応履歴を一つの管理単位にまとめ、誰が見ても次の対応が分かる状態にします。
通知は注文・出荷の確定した時点で送る
通知は、実際に処理が確定した時点と注文ステータスを結び付けて送ります。
| 通知 | 送信する時点 | 主な内容 |
|---|---|---|
| 注文受付通知 | 注文内容を受け付け、管理対象として確定した時点 | 注文番号、商品、金額、配送先、今後の流れ |
| 出荷準備に関する案内 | 注文確認や在庫引当が完了し、出荷準備へ進んだ時点 | 出荷予定など、確定している情報 |
| 発送・追跡案内 | 荷物を発送し、出荷を確定した時点 | 発送日、配送方法、追跡に必要な情報 |
「出荷準備中」は、検品や梱包が完了していない状態です。一方、「出荷済み」は配送事業者などへ荷物を引き渡した後の状態として区別します。この区別がないと、発送前に追跡案内を送ったり、出荷遅延が起きているのに発送済みと表示したりするおそれがあります。
通知文面は、ステータスが変わったときに自動または定型文で送れるようにすると、送信漏れを抑えられます。ただし、自動送信の条件は自社の注文確定・出荷確定の定義と一致させてください。
問い合わせ・キャンセル・返品は履歴を見て判断する
問い合わせでは、まず注文番号などで対象注文を特定し、次の情報を確認します。
- 注文内容、購入者、配送先
- 支払方法と決済状況
- 在庫引当の有無
- 出荷準備中か、出荷済みか
- 送り状番号や配送状況
- 過去の問い合わせと案内内容
キャンセルは、出荷前か出荷後かで処理が変わります。出荷前なら引当解除、決済の取り消しや返金の要否、顧客への完了通知を確認します。出荷後なら、荷物の配送状況や返品の要否を確認したうえで、キャンセルではなく返品・返金の処理になる場合があります。実際の扱いは決済サービスや店舗規約に合わせて定義します。
返品では、返品を受け付けた日時、対象注文、返品理由、商品の受領状況、検品結果、返金・交換の判断、在庫へ戻したかどうか、顧客との連絡内容を残します。返品商品を受け取っただけで販売可能在庫へ戻すのではなく、再販売の可否を確認してから在庫を更新します。
担当者が替わっても処理できるようにする
担当者が替わっても処理を続けるには、注文ごとに「現在の状態」と「次に行うこと」を残します。最低限、次の項目を共有します。
- ステータスの意味と、各ステータスへ進める条件
- 担当者と対応期限
- 保留理由や確認待ちの相手
- 決済、在庫、配送の確認結果
- 顧客へ伝えた内容と伝えた日時
- 次の担当者が行う処理
たとえば「保留」とだけ記録すると、なぜ止まっているのか分かりません。「配送先の番地確認待ち」「入金確認待ち」「返品商品の検品待ち」のように、保留理由と解除条件まで記録します。
受注・出荷・顧客対応を複数人で分担する場合は、個人の受信箱ではなく、受注管理画面や共有台帳に履歴を残します。マニュアルには操作方法だけでなく、キャンセルや返品などの例外時に誰が判断し、どの情報を更新するかも含めます。
複数チャネルでは一元管理・自動化をどう判断するか
一元管理は、複数の注文を一つの画面に集めることだけが目的ではありません。販売チャネルごとに分かれていた注文、在庫、出荷状況を共通のルールで処理し、同じ情報を何度も転記しないための仕組みです。
単一のECを少量の注文で運営している場合は、管理画面と共有ルールの整備だけで足りることもあります。一方、チャネル数や注文量が増え、手作業による確認・転記がミスの原因になっているなら、業務の一部または全体を仕組み化する段階に入っています。
一元管理を検討しやすい運用状況
次のような状態が複数あるなら、一元管理や自動化を検討しやすくなります。
| 状況 | 仕組み化を検討する理由 |
|---|---|
| 複数モールや自社ECで同じ商品を販売している | 在庫更新が分かれると売り越しや欠品が起きやすい |
| 実店舗とECで同じ在庫を使っている | 店舗販売とオンライン注文の在庫を同じルールで扱う必要がある |
| 注文情報を別の画面や表へ何度も転記している | 入力ミス、二重処理、更新漏れが発生しやすい |
| 注文量の増加で確認や出荷が遅れている | 人数を増やす前に、繰り返し作業を減らせる可能性がある |
| 在庫ズレや売り越しが発生している | 在庫更新の契機と反映先を統一する必要がある |
| 特定の担当者がいないと処理できない | ステータスや履歴を共有し、属人化を解消する必要がある |
一元化の対象は、注文だけに限定しません。日々の処理で横断確認する受注情報、商品・SKU、在庫、出荷状況、顧客対応履歴を共通のフローに載せます。顧客分析や販促まで同時に統合する必要があるかは、受注処理の課題とは分けて判断します。
導入前に業務フローと優先順位を整理する
導入前には、現在の業務をチャネル別、担当別、利用システム別に書き出します。注文受付から出荷・通知までを時系列に並べ、どこで次の問題が起きているかを確認します。
- 同じ情報を複数回入力している
- 確認待ちで注文が止まっている
- 在庫更新の担当やタイミングが決まっていない
- 出荷結果が受注側へ戻っていない
- キャンセルや返品の履歴を探しにくい
- 担当者が不在だと判断できない
次に、連携が必要な対象を整理します。候補には、ECカート、各モール、実店舗の在庫、倉庫、配送、決済などがあります。個別サービスの対応可否は変わるため、候補を選ぶ段階で最新仕様と自社の要件を照合します。
要件は、必須、できれば必要、将来検討のように優先順位を分けます。たとえば、売り越しが課題なら最初に在庫連携を優先し、帳票の細かなカスタマイズや分析機能は後段に回す、といった判断です。現場担当者にも確認し、管理者が把握していない手作業や例外処理を要件から漏らさないようにします。
一度に切り替えず、優先業務から定着させる
導入時は、受注集約、在庫連携、出荷指示など、影響が大きく効果を確認しやすい業務から段階的に移行します。最初からすべてのチャネルと例外処理を切り替えると、問題が起きたときに原因を特定しにくく、現場も混乱しやすいためです。
選定時は、機能数だけでなく次の点を確認します。
- 自社のSKU、セット商品、出荷形態に合うか
- 利用中のECカート、モール、倉庫、配送、決済と連携できるか
- 注文・在庫・顧客対応の履歴を確認できるか
- 担当者ごとの権限や作業分担を設定できるか
- 障害や仕様変更時のサポート体制があるか
- 将来チャネルや出荷拠点が増えたときに拡張できるか
移行後は、旧運用と新運用のどちらを正とするかを明確にし、二重更新を避けます。実際の注文を使って、注文取り込み、在庫引当、出荷指示、送り状・納品書、発送通知、キャンセル・返品までを確認します。
操作研修やマニュアルでは、通常処理だけでなく、保留、住所変更、決済確認待ち、キャンセル、返品などの例外も扱います。担当者が変わっても同じ判断ができるよう、ステータスの意味、更新する項目、次の担当者を明記し、運用開始後も定期的に見直します。
まとめ
EC受注処理は、注文受付から注文内容・決済・在庫・配送先の確認、在庫引当、出荷、発送通知までを一つの流れで管理する業務です。
誤出荷や売り越しを減らすには、受注ごとの確認項目、在庫を更新する時点、出荷指示と帳票のつなぎ方を決めます。キャンセル・返品・問い合わせでは、注文の現在地と対応履歴を共有し、担当者が変わっても次の処理が分かる状態にします。
複数モールや自社EC、実店舗で転記や在庫ズレが増えた場合は、現状のフローと課題を可視化してください。そのうえで、受注集約や在庫連携など優先度の高い業務から、一元管理や自動化を段階的に導入するのが基本です。