EC運営で最も時間を食う日常業務は受注処理です。毎日発生し、件数が増えれば比例して時間が増えます。
弊社はAmazon単独から始めて、現在はAmazon・楽天市場・メルカリShops・自社ECの4店舗を運営しています。その過程で受注処理の方法を何度か変えてきました。
結果として、1〜2時間かかっていた作業が30分になりました。ただし一足飛びにそうなったわけではなく、段階を踏んでいます。何がどう変わったのかを順に書きます。
段階1：Amazon管理画面で1件ずつラベルを購入
最初はこれでした。Amazonの管理画面を開き、注文を1件ずつ確認し、1件ずつラベルを購入して印刷する。
注文が少ないうちは成立します。ただ、件数が増えると単純に比例して時間が増えます。10件なら10回、50件なら50回、同じ操作を繰り返すことになります。
この方式の問題は、作業時間が件数に完全比例することです。売上が伸びるほど、受注処理に取られる時間が増えていく。改善の余地がない構造でした。
段階2：プライスターで一括ラベル発行
次の段階が、Amazon運営ツールのプライスター導入です。
ここで初めてチェックボックスで選んで一括ラベル発行ができるようになりました。1件ずつの操作から解放されたわけです。
正直に書くと、この変化が最も劇的でした。100件の注文があっても、選択して一括で発行すれば作業は1回で済みます。件数と作業時間の比例関係が崩れた瞬間です。
まだAmazon単独運営だった時期の話ですが、「一括処理できるかどうか」が受注処理の効率を決めるということを、ここで実感しました。
段階3：クロスモールで複数モールを一括処理
楽天市場に出店し、複数モールの運営が始まると、また別の問題が出てきます。
Amazonの管理画面とプライスターで完結していたものが、楽天のRMSも見なければならなくなる。一括処理はできるが、モールの数だけ一括処理をするという状態です。
ここで一元管理ツールのクロスモールを導入し、複数モールの受注をまとめて処理できるようになりました。この時期に日本郵便との契約も整えています。
段階4：GoQへの移行
クロスモールからGoQSystemへ移行した理由は、機能面の不足でした。
クロスモール時代にAmazonのEASY SHIP契約をしたのですが、当時のクロスモールはEASY SHIPに対応していませんでした（現在の対応状況は分かりません）。配送方法を使えないのでは意味がないため、対応しているGoQへ移行しました。
その後メルカリShopsを開始し、現在は3モールすべての受注を一括処理しています。
結果：1〜2時間が30分に
Amazon管理画面で1件ずつ処理していた頃と比べると、作業時間は1〜2時間から30分以内になりました。
しかも当時はAmazon1店舗のみ。現在は3モール分の受注を処理してこの時間です。実質的な効率は数倍になっている計算です。
ただし習熟に1〜2週間かかった
誤解のないように書いておくと、導入した翌日から30分になったわけではありません。
GoQに慣れるまで1〜2週間かかりました。ステータスの設計、自動振り分けの設定、画面の操作。それぞれを自社の運用に合わせて調整する期間が必要です。
ツールを導入する際は、この習熟期間を織り込んでスケジュールを組んでください。繁忙期の直前に導入すると、慣れないまま処理量が増えて破綻します。
導入して分かったこと：受注処理は設計されている
GoQを使って感じたのは、受注処理がスムーズに流れるよう設計されているということです。
ステータスを作り、条件に応じて自動で振り分ける。荷物サイズごとに分ける。ラベルとピッキング票を一括発行する。これらが最初から想定された機能として用意されています。
自分で仕組みを作るのではなく、用意された仕組みに自社の運用を合わせる。この発想の切り替えができると、導入がスムーズになります。
反省点：SKUを最初から統一しておくべきだった
最大の反省点はこれです。
3モールのSKUを最初から統一しておけば、移行時の作業が大幅に減っていました。
クロスモール時代、弊社は楽天側をJANコードで管理していました。GoQはSKUを軸に管理するため、移行時に紐付けをやり直す必要が生じたのです。楽天の「システム連携用SKU番号」という項目にAmazonのSKUを入れることで対応しましたが、この作業に時間を取られました。
これから多店舗展開する方は、商品登録を始める前にSKUの命名規則を決めてください。Amazon・楽天・メルカリShopsで同じSKUを使う。それだけで、後のツール移行が格段に楽になります。
使っていない機能もある
参考までに、GoQの機能をすべて使っているわけではないことも書いておきます。
商品登録機能は使っていない
Amazonと楽天の商品登録は、どちらも各モールの管理画面から手動で行っています。GoQの商品登録機能は使っていません。
理由は、それぞれのモールで登録の作法が違うためです。Amazonはカタログへの相乗り、楽天は一からのページ作成。性質が違う作業を1つのツールでまとめる必要性を感じていません。
メルカリShopsだけは例外
ただしメルカリShopsは別です。受注処理を契約するとGoQから商品登録できる機能が付いてくるため、こちらはGoQで登録しています。
この機能は楽天市場の商品を取り込む仕様になっています。つまり楽天のページが基準になるため、楽天側の整備がそのままメルカリShopsに反映されます。
在庫連携は使っている
在庫連携は3モールすべてで利用しています。商品の取り込みもここから行えるため、在庫管理の中核として機能しています。
まとめ：受注処理の効率化で押さえるべき点
ここまでの経験から、押さえるべき点を整理します。
- 一括処理できるかが分岐点。1件ずつの操作から解放されるだけで、作業時間の構造が変わります
- モールが増えたら一元管理へ。モールごとに一括処理する状態も、いずれ限界が来ます
- ツールは機能で選ぶ。使いたい配送方法に対応していなければ、乗り換えるしかありません
- 習熟期間を見込む。導入直後は逆に時間がかかります。1〜2週間は覚悟してください
- SKUは最初から統一する。これが最大の反省点です。後から直すと何ヶ月もかかります
- 全機能を使う必要はない。自社の運用に合う部分だけ使えば十分です
受注処理は毎日発生する作業です。1日30分の削減でも、年間では100時間を超えます。その時間を仕入や商品開発に回せると考えれば、投資する価値は十分にあります。
具体的なステータス設計と日々の運用については4店舗分の受注処理をどう回すか｜GoQのステータス自動振り分けと人が見る部分、在庫管理については在庫の一元管理はこう回す｜GoQで3モールを運用する実務と失敗談で書いています。
