ECサイトの業務フローは、商品を登録して注文を発送するだけではありません。仕入れ、商品情報、集客、決済、在庫、物流、顧客対応、売上確認がつながって初めて、購入者へ約束した商品を届けられます。作業の一覧に加えて、担当と次の工程へ進む条件を整理することが大切です。
本記事では、ECサイト運営の全体像と各工程を解説し、通常注文、欠品、変更、取消、返品の流れを紹介します。業務フローを作る手順、自動化や外部委託の考え方、日々の点検方法も取り上げます。担当者が変わっても処理が止まらない運営を整える際にお役立てください。
ECの業務フローや処理漏れを見直したい方は、FORCE-Rへご相談ください。
| 確認したいポイント | 結論 | 詳細 |
| EC業務フローの全体像は？ | 販売前から購入後までつなぐ | 担当、情報、判断と次へ進む条件を整理します。 |
| 受注から出荷の手順は？ | 取込・確認・確保・指示・実績 | 注文・決済・配送の状態を分け、結果まで確認します。 |
| 効率化の進め方は？ | 棚卸し後に条件を決めて試行 | 自動化や委託でも、例外時の担当と完了確認を残します。 |
Contents
ECサイトの業務フローは販売前から購入後までつながる
ECサイトの業務フローは、販売準備、集客・販売、受注・決済、出荷、購入後対応、実績確認をつないだものです。作業順を示すだけでなく、何の情報を受け取り、誰が判断し、どの状態なら次へ進めるかを明確にします。システムを導入している場合も、業務上の判断は別に整理する必要があります。
例えば、注文情報が受注管理へ取り込まれても、住所や支払いに確認が必要なら、そのまま出荷してよいとは限りません。反対に、商品が発送されていても、追跡番号や売上の処理が残っている場合があります。一つの画面の完了表示だけで、注文全体が終わったと考えないことが重要です。
フロント業務とバックエンド業務を連携させる
販売を促す仕事と、注文を処理する仕事は、計画の段階から連携させます。商品企画、ページ制作、広告などは購入のきっかけを作り、受注、在庫、出荷、顧客対応などは購入後の約束を実行します。この区分は整理に役立ちますが、両者が無関係に動くという意味ではありません。
キャンペーンを始める前には、在庫、出荷能力、同梱物、問い合わせへの回答を確認します。広告担当が販売数を増やしても、倉庫が必要な梱包に対応できなければ、出荷が遅れる可能性があります。販促の予定と物流の準備を同じ期間で確認すると、開始後の行き違いを減らせます。
自社物流と外部倉庫で引き継ぎを変える
自社で出荷する場合と外部倉庫へ委託する場合では、指示と結果を受け渡す方法が異なります。外部へ任せるときは、出荷指示を送った時刻だけでなく、倉庫が受け付けたか、作業中か、発送済みかを確認できる仕組みが必要です。中小機構の受注から発送までの講座案内でも、両方のケースが分けられています。
委託先に任せる範囲を明確にしても、購入者への連絡が自動で完了するとは限りません。配送遅延や変更依頼があった場合に、誰が状況を確認し、誰が回答するかを決めます。倉庫へ問い合わせたまま顧客への案内が止まらないよう、回答期限と代行者も設定しましょう。
正常な流れと例外を分けて記録する
通常どおり進む注文の流れを先に作り、欠品や取消などの分岐を追加すると整理しやすくなります。最初からあらゆる例外を一枚へ入れると、日常の作業が見えにくくなります。共通の工程と、特定の条件で必要になる作業を分けて示しましょう。
フローの対象も明記します。国内向けの通常商品と、予約商品、定期購入、法人取引、越境販売では、必要な確認が異なります。まず対象の販売経路と注文を決め、その範囲で使えるものを作ります。別の条件へ展開するときは、同じ手順をそのまま使えるか確認してください。
業務フローと操作手順書も分けて考えます。フローは仕事のつながりと判断を示し、手順書は具体的な画面操作や入力内容を示します。画面が変わるたびに全体の流れを書き直すより、該当する操作手順を更新できる形にすると維持しやすくなります。どちらにも改訂日と管理する担当を記載しておきましょう。参照先を相互に記載すると、初めて担当する人も必要な操作へ進みやすくなります。
販売前の業務：商品・在庫・ページを準備する
販売前には、商品、価格、在庫、配送、商品情報、購入画面の準備をそろえます。ページを公開できたことだけでは、注文を受けてよい状態とはいえません。入荷や倉庫の設定、決済、問い合わせ窓口まで確認し、公開を判断する担当者を決めましょう。
準備の進行は、商品ごとの一覧で管理すると分かりやすくなります。商品番号、発売予定、画像、説明、価格、在庫、倉庫登録、確認結果を対応させます。担当部署が分かれる場合も、同じ商品番号で会話できるようにすると、別の規格や入数を扱う誤りを防ぎやすくなります。
商品企画・仕入れと入荷予定をそろえる
販売する商品と数量を決めた後は、いつ入荷し、いつ出荷できるかを確認します。販売開始日、入荷予定日、実際に倉庫へ登録される日は同じとは限りません。発注済みの数量を、そのまま出荷可能な在庫として扱わないことが基本です。
商品が到着したら、数量や規格、状態を確認し、所定の場所へ保管します。入荷しただけでシステムへ反映されていなければ、販売できない場合があります。反対に、未検品の商品を販売可能として公開すると、受注後に不良が分かるおそれがあります。入荷、検品、登録の完了を分けて管理してください。
商品情報を登録し公開前に照合する
商品ページは、名称、規格、価格、画像、配送条件などを正式な商品情報と照合して公開します。サイズや色の違いを選ぶSKUがある場合は、選択肢と在庫、価格が正しく対応しているかも確認します。画像が正しくても、注文データで別の商品番号になる誤りには注意が必要です。
説明文や画像は、購入者が商品を判断するための情報です。使用条件、内容量、付属品、納期など、問い合わせが多い点を先に示します。古いページを複製するときは、前の商品名、価格、配送条件が残っていないかを確認し、公開前と公開後の表示を両方確かめましょう。
公開確認は、管理画面の入力内容だけでなく、購入者が実際に見る画面で行います。スマートフォンで選択肢を変えたときの表示、送料、購入できる数量、注文完了後に受け取る情報も確認します。テストが難しい部分は未検証として残し、担当者が検証済みの範囲を誤解しないようにしてください。
在庫共有と販促開始の条件を決める
複数のECや店舗で販売する場合は、販売可能在庫をどう配分し更新するかを決めます。倉庫にある実数と、すでに注文へ確保された数、販売画面に出す数は異なります。Shopify在庫管理の解説も参考に、引当と販売可能数の関係を整理してください。
販促を開始するときは、ページだけでなく、同梱物やクーポン、配送予定の案内も確認します。SNS経由の施策では、ソーシャルコマースの種類と注意点の解説を踏まえ、投稿から購入まで情報が一致しているかを点検しましょう。施策終了後に特典や案内を戻す作業も、予定に含めることが重要です。
施策が終わった後の確認では、値引きや特典を戻しただけでなく、予約された広告やメールが残っていないかも点検します。販売終了の商品へ誘導が続くと、購入者の問い合わせや誤注文につながります。開始と終了の作業を対で管理し、戻す設定、残す履歴、確認担当を予定表へ記載しておきましょう。
ECの販売施策と受注・出荷をつなげたい方は、FORCE-Rへお問い合わせください。
受注から出荷までの業務フロー
受注後は、注文取込、内容・支払いの確認、在庫確保、出荷指示、倉庫作業、発送実績の反映へ進みます。決済手段やカートによって順序と条件は変わるため、自社の仕組みに合わせて定義します。すべての注文が同じ順番で自動処理されると考えないようにします。
注文の状態、決済の状態、配送の状態は、それぞれ区別して確認します。例えば、注文受付済みでも支払い確認待ち、出荷指示済みでも倉庫未受付、送り状発行済みでも未発送という状態があり得ます。業務フローには、どの画面や記録を根拠に判断するかも添えておきましょう。
注文を取り込み内容を確認する
注文取込では、販売元の注文番号を保持し、重複と取込漏れを確認します。APIやCSVで取り込む場合も、接続していることだけで全件が届くとは限りません。処理件数や最終更新、エラーを照合し、失敗した注文を誰が確認するかを決めます。
確認する内容は、商品、数量、金額、住所、配送希望、備考、適用した特典などです。すべてを毎回人が目で見るのか、条件に合う注文だけ確認するのかは、業務とシステムに合わせて設計します。判断基準がないまま自動化すると、確認すべき注文まで通常処理へ進むおそれがあります。
一日の終わりには、受注元の件数と、処理対象へ取り込んだ件数を照合します。取消やテスト注文など、数が違う理由も区別して残します。差を見つけたときに全件を再取込すると重複が起きるおそれがあるため、未取込の注文を特定して対応できる手順を用意することが重要です。
支払いと在庫の条件を確認する
出荷へ進める決済条件を、支払方法ごとに定めます。銀行振込の入金確認と、カードの認証や承認、売上の処理は同じではありません。後払いなども含め、どの状態なら出荷できるかを契約先の手順で確認します。不明な状態を、担当者の推測で完了にしないことが大切です。
在庫引当では、受けた注文に必要な商品を確保します。取り寄せや分納がある場合は、注文全体を待つのか、出せる商品を先に出すのかを整理します。ネクストエンジンの受注管理機能の説明は、注文の取込、状態管理、入金処理、出荷連携などを確認する参考になります。
倉庫へ指示を送り作業の開始を確認する
出荷指示は、商品と数量に加え、配送方法、住所、同梱、ギフトなど必要な条件を渡します。画面で指示を作ったことと、倉庫へ正しく届いたことを分けて確認しましょう。送受信に失敗した場合の通知と、再処理の方法も必要です。
倉庫が作業を始めた後は、受注担当が自由に内容を変えられない場合があります。LOGILESSの出荷機能の説明では、作業中の変更ロックなどが示されています。自社のシステムでも、変更できる期限と停止依頼の方法を確認し、顧客対応の担当者へ共有してください。
当日発送の締め時間は、購入者へ表示する時刻と、社内の確認期限、倉庫の受付期限を区別します。社内で処理できた時刻が倉庫の締め後なら、予定どおり出せない場合があります。休日や配送会社の集荷が変わる時期も含め、案内と実際の処理能力が合っているかを確認してください。
検品・梱包・発送と通知をつなげる
倉庫作業では、商品を取り出し、注文との一致を確認し、条件に合わせて梱包して配送会社へ渡します。商品の種類や数量だけでなく、同梱物、納品書、送り状の取り違えにも注意します。検品の記録と、作業完了を判断する条件を決めておきましょう。
発送後は、配送会社、追跡番号、出荷日などの実績を受注側へ反映し、購入者へ案内します。送り状を発行した時点で発送通知を出すと、実際には未発送の荷物を発送済みと伝える可能性があります。自動メールを使う場合も、何をきっかけに送信するかを確認してください。
複数個口や別倉庫からの発送では、一つの注文に複数の追跡番号が付く場合があります。一部が発送された時点で注文全体を発送済みにすると、残る商品が見えにくくなります。注文単位と出荷単位の関係を残し、購入者へどの商品がどの荷物で届くかを説明できるようにします。
欠品・変更・取消などの例外を処理する
例外の処理は、通常の流れを止める場所と、再開や終了を判断する担当を明確にします。保留の表示だけでは、倉庫で作業が続いている場合があります。受注管理と物流の両方で停止が反映されるかを確認し、顧客への案内と実際の処理を一致させましょう。
例外は、理由、対象、確認事項、担当、次の期限を記録します。「確認中」の状態にまとめるだけでは、住所確認なのか入荷待ちなのかが分かりません。担当者が変わっても次の作業を判断できるよう、保留理由と解除の条件を分けて残すことが大切です。
欠品と入荷待ちを案内する
欠品では、在庫差の確認と、購入者へ提示できる選択肢を整理します。入荷の見込みを調べずに待ってもらう案内を続けると、予定が何度も変わります。確定した情報と見込みを区別し、分納、代替、取消など、自社で対応できる内容を確認します。
購入者の意向を確認した後は、倉庫や決済の処理へ反映します。欠品した一商品を取り消したことで、送料や特典の条件が変わる場合もあります。注文の明細だけでなく、支払総額と案内内容を照合し、元の条件から何が変わるかを説明してください。
注文内容と配送先の変更を反映する
変更を受けたら、受付時点で作業を止められるかを確認し、反映結果まで追います。顧客対応の担当者が了承しても、倉庫がすでに発送していれば、同じ方法では変更できません。どの時点から別の手続きになるかを明確にしましょう。
変更の記録には、変更前と変更後、依頼を受けた日時、実施者、処理結果を残します。外部連携がある場合は、元のシステムにも修正が必要かを確認してください。連携先だけを直した結果、次の同期で古い内容へ戻ることがないよう、正式な更新元を決めます。
変更受付の窓口が複数ある場合は、メールと電話で異なる依頼が届いたときの扱いも定めます。単に後の連絡を優先するのではなく、本人確認と依頼内容を照合し、最終的に何を反映したかを記録します。担当者がそれぞれ変更を実行しないよう、処理中の案件が分かる仕組みも必要です。
取消と返金を別の処理として管理する
注文取消、出荷停止、決済取消・返金は、関連する別々の処理です。受注画面で取消を完了しても、出荷指示や決済が残っていれば対応は終わりません。対象の注文番号と決済識別番号を対応させ、必要な処理と結果を確認します。
取消後に在庫を戻す場合も、現物の状態を確認します。すでに梱包済みなのか、配送会社へ渡したのか、返送中なのかで扱いが変わります。LOGILESSの受注処理の流れも参考に、製品ごとの状態と自社の完了条件を照合し、画面の呼び方だけで判断しないようにしましょう。
ECの例外対応と顧客案内を整理したい方は、FORCE-Rへご相談ください。
購入後の対応と売上確認を終える
購入後は、配送状況、問い合わせ、返品・交換、返金、売上・入金の照合を進めます。発送したことで購入者の疑問や、決済上の処理がすべて終わるわけではありません。対応中の案件を注文と結び付け、未完了の作業を一覧で確認できるようにします。
問い合わせでは、注文番号と過去の履歴を確認し、同じ購入者へ担当者ごとに異なる説明をしないようにします。公開コメントへ個人情報を返さず、正式な窓口へ案内することも必要です。返信した時点と、問題が解決した時点を分けて管理しましょう。
返品・交換は現物と金額の両方を追う
返品は、受付、返送、倉庫到着、検品、在庫処理、返金の進捗を分けます。商品が戻っていないのに販売可能在庫へ戻したり、返金だけが漏れたりする状態を防ぐためです。消費者都合と商品不良などの理由も分け、適用する条件を確認します。
交換を行う場合は、元の注文と交換品の出荷を結び付けます。再送の売上を通常注文へ重ねて計上しないよう、経理とも処理をそろえましょう。返送された商品を再販売できるかは、検品と商品特性に基づいて判断し、受け取っただけで自動的に通常在庫へ戻さないようにします。
返品が倉庫へ届いた後に注文を特定できないと、検品や返金が止まります。購入者へ案内する受付番号と、倉庫で確認する番号をそろえ、伝票や同梱書類の扱いを決めます。注文が分からない返品や、数量が予定と違う返品についても、保管場所と照会先を定め、通常在庫に混ぜないようにします。
実店舗での受取や返品も履歴へ反映する
店舗を含む運用では、オンラインの記録と実際の商品の受け渡しをつなぎます。店舗で受け取ったか、返品を受け付けたかがEC側へ伝わらないと、問い合わせや返金が重複する可能性があります。店舗担当者が確認する情報と、更新する担当を決めてください。
O2OとOMOの違いの解説を参考に、窓口を増やす施策と、情報を共有する仕組みを合わせて考えます。購入者がどこへ連絡しても同じ注文の状態を確認できるようにすると、何度も説明を求める負担を減らせます。ただし、共有する個人情報は業務に必要な範囲へ絞りましょう。
売上・返金・入金を照合する
売上の集計と、決済会社やモールからの入金を別々に確認します。手数料、返品、取消、調整などによって、注文の合計と実際の振込額が一致しない場合があります。差があることを直ちに誤りとせず、明細を確認して説明できる状態にします。
経理へ渡すデータは、期間、売上の基準日、税込・税抜、費用の扱いをそろえます。注文日と出荷日、入金日が異なるため、どの基準で集計した数字かを明記してください。画面上の売上をそのまま会計へ転記せず、自社の会計方針と取引の実態に合わせて確認します。
業務フローの作り方と効率化の進め方
業務フローは、現状の棚卸し、担当と情報の整理、完了条件の設定、関係者の確認、試行の順で作ります。理想の形だけを描くより、今どこで確認や入力が重複しているかを把握することが出発点です。担当者の記憶にある例外も、実際の注文から確認しましょう。
各工程には、きっかけとなる情報、実行担当、使うシステム、判断、完了の記録を添えます。例えば出荷指示なら、出荷可能となった注文を受け取り、受注担当または自動処理が倉庫へ送り、受付結果を確認する流れです。こうした単位で整理すると、工程間の抜けを発見しやすくなります。
自動化は条件が明確な作業から始める
自動化する前に、判断条件と例外時の処理を決めます。毎回同じ情報を転記する作業や、条件がそろった注文の通知などは、候補になりやすいものです。一方で、購入者との合意や専門的な判断が必要な案件は、人へ引き継ぐ道を残します。
自動処理を設定したら、正常時だけでなく、データ不足、通信失敗、同じ情報の再送も試します。失敗したことを担当者が知る方法と、再開時に重複処理しない方法が必要です。自動化した件数だけでなく、エラーの修正や手動確認にかかった時間も評価してください。
自動化の変更は、設定した人以外も内容を確認できるようにします。どの注文が対象で、何を実行し、どの条件では止まるかを記録すると、意図しない処理が起きたときに調べやすくなります。古いルールと新しいルールが同時に動かないかも点検し、変更後は実際の結果を確認してください。
外部委託は受け渡す情報と責任を決める
委託では、任せる作業の前後と、結果を確認する担当を明確にします。商品登録を任せるなら、素材を渡す人、内容を確認する人、公開する人を決めます。倉庫へ任せるなら、出荷指示、停止、実績、返品の受け渡しまで確認しましょう。
料金も、月額だけでなく、商品や注文が増えた場合、修正や緊急対応がある場合の条件を確認します。外注すれば社内作業がすべてなくなるとは限りません。情報提供、確認、例外判断の時間を見込み、委託先と自社の両方で運営できる体制を整えてください。
担当者の異動や委託先の変更がある場合は、進行中の注文と未完了の対応を引き継ぎます。手順書だけでは、いま何を待っているかが分かりません。案件番号、現在の状態、次に行う作業、期限、関係者を整理し、引き継いだ側が確認できたことまで残すと、交代時の処理漏れを減らせます。
滞留と品質を定期的に点検する
改善では、作業時間だけでなく、待ち時間とミスの発生場所を確認します。注文取込から確認まで、出荷可能から倉庫受付までなど、工程の間で時間がかかる場合があります。処理中の件数と長く残った注文を見ると、担当追加や連携修正が必要な場所を特定できます。
集客の成果も見る場合は、ユニークユーザーなどの指標の違いの解説を参考に、訪問人数と注文件数、出荷件数を区別します。購入後の課題は、リピート率と向上施策の解説も踏まえて確認しましょう。販売量の増加に対応できるかと、顧客が再び利用したくなるかを、両方見直すことが大切です。
棚卸しや連携障害など、通常の流れを一時的に止める予定も共有します。停止中に受けた注文をどこへ残し、再開後にどの順で処理するかを決めておけば、担当者ごとの判断で順序が変わることを防げます。再開したことだけで安心せず、停止期間の未処理が解消されたかまで確認しましょう。
ECの日常業務と運営体制を改善したい方は、FORCE-Rへお問い合わせください。
まとめ：ECサイトの業務フローは完了条件と引き継ぎを決める
ECサイトの業務フローは、販売前から購入後まで、担当と情報、判断、完了条件をつなげて作ることが基本です。受注、決済、在庫、配送の状態を分け、通常の注文と例外を整理しましょう。処理を依頼したことと、実際に完了したことを区別すると、対応漏れを防ぎやすくなります。
まずは一件の注文を追い、商品情報から出荷、問い合わせ、売上確認までの流れを棚卸ししてください。保留や変更、取消、返品の分岐を追加し、関係者と確認したうえで試行します。自動化や外部委託も、判断条件と結果確認を整えてから使うことで、無理なく運営を改善できます。
ECの業務フローや運営課題の整理は、FORCE-Rへご相談ください。自社で改善する工程と外部支援の範囲を、個別にご確認いただけます。
