受注後のステータスフロー
顧客が商品を購入した後に入金確認や在庫の引当、倉庫に出荷指示し、配送業者が顧客に商品が届け、売上計上されるまでの一連の受注業務フローを受注ステータスフローと呼ぶ。ECにおける主要な「業務」や「自社独自の業務」が発生するフローとなる。 顧客が注文した内容は、ステータスが「1.受注」「2.未引当」「3.中途引当」「4.引当済」「5.出荷指示済」「6.出荷済」「7.着荷済」「8.計上済」と遷移していく形となる。 また、このステータスに応じて、入金を確認したり、決済を確定させたり、配送会社における送り状の番号を送ったり、ポイントを付与したり「業務」が発生していく。
この「業務」は業態や業種によって、EC事業の体制や作業者の割り当てによって異なる。 一般的な例をもとに、あるべき業務フローを検討するのが良い。
一般的でシンプルなフローをベースに紹介する。
1.受注
受注時の与信
受注時に自動で行われる業務が中心となっている。
- クレジットカードのオーソリゼーション(この決済に関する事前確認)。
- 後払いのリアルタイム与信(この後払い決済を受付て良いか確認)。
ユーザーキャンセル
受注後、「引当済」までにユーザーが注文をキャンセルするケースがあるので、仕様を考慮する必要がある。
- 注文をそもそもユーザーがキャンセルできるのか。
- どこからキャンセルできるのか(自社ECの購入履歴画面からか、コールセンターに電話か)。
- キャンセルできるとすればいつまでなのか(在庫引当前までなど)。
2.未引当
注文確認
人力および自動で、注文を受け付けて問題ないかを確認する。
- 備考にお客様が入力した情報の確認。 納期や配送に関する質問や要望、例えばラッピングに関する特殊な要望などが記載されている。
- 離島や特定住所の場合は、そもそも送付して問題ないか、送料の再計算が必要かなどを調整する必要がある。
- ブラックリストにあたるユーザーからの注文の場合は、内容を確認する場合がある。
- その他、よくある商品間違いや、サイズ間違いや、業務特性によって顧客に確認すべきことのやり取り。
- 上記いずれにも当たらない問題がない注文の場合は、自動で次のステータスに移動するなども可能である。
注文分割
受注後に注文を分割する。例えばA,B,Cの３点商品を購入していて、Cの出荷が１週間遅れる場合などは、注文をA、BのものとCのものに分割する。
- 配送日が異なる場合は、決済タイミング(出荷時の場合が多い)を分けるためにこのような処理を行う。
- 決済に関しては、決済事業者側にクレジットカード使用に関するトークン情報が保持されているため、決済を分割した注文数分行うことが可能である。
注文変更
注文変更の場合は、以下のような仕様を検討する。
注文をそもそもユーザーが変更できるのか、変更に合わせて決済方法や金額の修正、付与ポイントの修正、など手間が多く発生するため、これらの反映が自動化されていないような場合は、変更を受け付けず、キャンセル後再注文してもらうような手法をとる場合もある。
どこから注文変更できるのか(自社ECの購入履歴画面からか、コールセンターに電話か)。
- 注文変更できるとすればいつまでなのか(在庫引当前、出荷指示前までなど)。
入金確認
入金確認は、その方法によって連携や確認方法が異なる。 自動化することによって、業務効率を上げることが可能。
入金確認(クレジットカード)
- 利用されたクレジットカード情報、利用者情報が問題ないか確認する。
- これまで不正に利用されていないかなど、外部サービスを利用して確認することもある。
入金確認(銀行振込)
- 銀行振込は銀行に入金があったかを確認する必要がある
- 仮想口座を使うと、入金と口座が１：１で紐づくので、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日後にポイントを付与する。