受注後のステータスフロー
受注ステータスとは
顧客が商品を購入した後に入金確認や在庫の引当、倉庫に出荷指示し、配送業者が顧客に商品が届け、売上計上されるまでの一連の受注業務フローを受注ステータスフローと呼びます。 ECにおける主要な「業務」や「自社独自の業務」が発生するフローとなります。
顧客が注文した内容は、ステータスが「1。受注」「2。未引当」「3。中途引当」「4。引当済」「5。出荷指示済」「6。出荷済」「7。着荷済」「8。計上済」と遷移していきます。 また、このステータスに応じて、入金確認や決済確定、配送会社における送り状番号の送信、ポイント付与等の「業務」が発生していきます。
この「業務」は業態や業種によって、EC事業の体制や作業者の割り当てによって異なります。 一般的な例をもとに、あるべき業務フローを検討するのが良いでしょう。
ここでは一般的でシンプルなフローをベースに紹介します。
1.受注
受注時の与信
受注時に自動で行われる業務が中心となっています。
- クレジットカードのオーソリゼーション(この決済に関する事前確認)。
- 後払いのリアルタイム与信(この後払い決済を受付て良いか確認)。
ユーザーキャンセル
受注後、「引当済」までにユーザーが注文をキャンセルするケースがあるので、以下の仕様を考慮する必要があります。
- 注文をそもそもユーザーがキャンセルできるのか。
- どこからキャンセルできるのか(自社ECの購入履歴画面からか、コールセンターに電話か)。
- キャンセルできるとすればいつまでなのか(在庫引当前までなど)。
2.未引当
注文確認
人力および自動で、注文を受け付けて問題ないかを確認します。
- 備考にお客様が入力した情報の確認。 納期や配送に関する質問や要望、例えばラッピングに関する特殊な要望などが記載されています。
- 離島や特定住所の場合は、そもそも送付して問題ないか、送料の再計算が必要かなどを調整する必要があります。
- ブラックリストにあたるユーザーからの注文の場合は、内容を確認する場合があります。
- その他、よくある商品間違いや、サイズ間違いや、業務特性によって顧客に確認すべきことのやり取り。
- 上記いずれにも当たらない問題がない注文の場合は、自動で次のステータスに移動するなども可能です。
注文分割
受注後に注文を分割します。例えばA,B,Cの3点商品を購入していて、Cの出荷が1週間遅れる場合などは、注文をA、BのものとCのものに分割します。
- 配送日が異なる場合は、決済タイミング(出荷時の場合が多い)を分けるためにこのような処理を行う。
- 決済に関しては、決済事業者側にクレジットカード使用に関するトークン情報が保持されているため、決済を分割した注文数分行うことが可能です。
注文変更
注文変更の場合は、以下のような仕様を検討します。
注文をそもそもユーザーが変更できるのか、変更に合わせて決済方法や金額の修正、付与ポイントの修正、など手間が多く発生し得ます。これらの反映が自動化されていないような場合は、変更を受け付けず、キャンセル後再注文してもらうような手法をとる場合もあります。
どこから注文変更できるのか(自社ECの購入履歴画面からか、コールセンターに電話か)。
注文変更できるとすればいつまでなのか(在庫引当前、出荷指示前までなど)。
入金確認
入金確認は、その方法によって連携や確認方法が異なります。 自動化することによって、業務効率を上げることが可能な部分でもあります。
入金確認(クレジットカード)
- 利用されたクレジットカード情報、利用者情報が問題ないか確認します。
- これまで不正に利用されていないかなど、外部サービスを利用して確認することもあります。
入金確認(銀行振込)
- 銀行振込は銀行に入金があったかを確認する必要があります。
- 仮想口座を使うと、入金と口座が1：1で紐づくので、API経由などで自動で入金を処理できます。
- 仮想口座の場合は、番号が使いまわしとなっています。
入金確認(後払い)
- 後払いサービスに該当注文を連携して与信が下りるか確認します。
- 確認は、カート時点からリアルタイム与信を行うようなことも可能です。
入金確認(Amazonペイメント)
- 主なメリットとして、Amazonに登録されている住所を利用する場合、保証があります。
- より詳細なAmazonペイメントの情報については後述します。
発注
発注が必要な場合は、発注処理を行う。発注をEDIもしくはFAXなどで自動連係することも多いです。メーカーに発注して、メーカーから直送するようなケースも存在するし、メーカーからの商品を一度倉庫に集めて配送するケースも存在します。発注する際にも注文をある程度まとめてから発注するものと随時メーカーに送る方法などがあります。
3.中途引当
何らかの理由で在庫が引当できなかったケースをまとめたステータスです。 在庫の調整であったり、顧客との調整(納期の変更、注文のキャンセルなど)します。
4.引当済
ECサイトで物が売れたからといって、直接商品が確保され、そのまま配送に回されるわけではありません。商品は実際には、倉庫の棚にある。注文データを倉庫に渡すことによって出荷可能な商品を確保し、注文(お客様、配送先)と紐づけ、出荷指示につなげる必要がある。規模が大きくなると倉庫も複数になるので、どの倉庫で引当てて、どの配送会社で送るかなど業務の規模が複雑になる傾向があります。
5.出荷指示済
配送分割
送付元の拠点が異なる場合や、送付タイミングが異なる場合に対応します。
6.出荷済
売上確定
決済事業者のAPIを呼び出し、売上を確定します。
後払いサービス連携
後払いサービスに出荷した旨を連携する。後払いサービスから、配送先に対して、振込用の伝票(ハガキ)が送られることになります。
出荷通知
顧客へ出荷した旨をメールなどで通知する。配送会社と連携していれば、「配送状況確認(後述)」に必要な送り状番号(荷物番号)も併せて通知します。
配送状況確認
クロネコヤマトや佐川急便では、配送状況を確認するWEBサービスを用意している。 出荷通知時に採番した伝票番号、送り状番号を使って問い合わせることが可能です。
ヤマト http://jizen.kuronekoyamato.co.jp/jizen/servlet/crjz.b.NQ0010?id=伝票番号 佐川 http://k2k.sagawa-exp.co.jp/p/web/okurijosearch.do?okurijoNo=送り状番号
7.着荷済
着荷通知
配送会社のAPIから着荷情報を受け取り、着荷による計上を起算する際に利用します。 ただし配送会社のミスオペレーションが発生することもあり、リカバリ方法の検討は必要です。
出荷後の返品オペレーション
以下のような仕様を検討する。
- 顧客への返金処理。
- 返品された商品をどうするか、在庫として戻すか。
8.計上済
経理システムへの連携
- 売上が確定したデータを経理システムに連携します。
ポイント付与
- 出荷後すぐ、もしくはN日後にポイントを付与します。