こんにちは。マーケティングアソシエーションのボブです。
ECサイトの顧客対応が主な担当なんですが、実は顧客対応以外にも、出荷の手伝いもしたりしてるんですよ。
というわけで、前置きがかなり手短ですが、今日は出荷のお手伝い「受注処理」って何してるのかってお話です。
受注処理とは？
ECサイトで注文が入ると、注文された商品をきちんと顧客に届けるために処理が必要です。
- 支払いに問題がないか
- 届け先に問題はないか
- 商品は用意できるか
大まかですが、このように出荷できるかの確認と、出荷できる準備が必要です。
概ね、物流に任せられるまでの処理を行うことを「受注処理」と定義しますので、
今回は物流へのバトンタッチまでの流れで、割と処理が多いものを例に挙げます。
支払いに問題がないかは、高額な注文の支払いができるのかだとか、不正な注文ではないのかなどを確認します。
支払いに問題が無いことを確認したら、届け先がちゃんとした住所になっているかを確認して、在庫が用意できたら、出荷の担当に注文の情報を渡すという作業ですね。
全注文そんなことしてたらすごく大変そうって思いませんか？
実際には殆どのケースで、怪しくない注文のチェックはシステムで対応して、システムで弾かれた注文だけをチェックしているので、チェックする注文は全体の一部だったりします。
システムでは「高額な注文ですよ～」とか「郵便番号と住所が合わないですよ～」とか「ブラックリストですよ～」とかの設定された情報で注文を弾いてくれたりするので、それに弾かれたものの確認が最初の処理になります。
よしよし、確認も終わったしこれで完璧…ではないんですね。
次に、確認した注文を出荷できるように、出荷担当にデータで渡さないといけません。
これも一例ですが、出荷担当が必要とするデータは以下のような感じ。
- 出荷する商品の情報
- お届け先の情報
- 出荷日（お届け指定日）の情報
できれば、物流側のシステムで取り込める形式だと理想です。
…そうそう、カスタマーサポートと物流のシステムは違うことが多いんです。
なので受注処理は必要なことが多かったりします。
ここで、データだけ渡したり、システムにデータをアップロードしたりは運用によって違うんですが、出荷できる状態にするために結構必要な作業なんですね。
効率的な受注処理の秘訣は「システム化」
ここまでのお話でもちょっとネタバレしちゃいましたが、システム化して効率化を図ることが一般的です。
出荷できる注文を確認しなくていいようにする、できるだけ精度を上げて確認する注文を減らすってことです。
注文数の多少はサイトの規模で変わってきて、１日数十件の対応であれば全部確認することもできるでしょうし、高額な商品であれば確認コストをかけることもできたりすることもあるんですが、数千とか場合によっては万単位の注文が入るサイトもあって、それを全部確認しようって言うのは物理的にちょっと難しかったりします。
なので、システムに任せる部分を増やして効率化を図ることが多くなります。
受注処理と物流の間の情報ギャップを埋める
ここまで読んでいただいていたらお気付き方もいるかもしれませんが、前述の通り受注管理と物流のシステムは、異なるモノを使用することが多いです。
それは、受注と出荷で必要な情報が異なるためです。
受注処理では注文が成立するかが重要な一方、出荷ではきちんと届くかが重要です。
最終的にはちゃんと請求できるかということですが、それぞれの作業において必要な情報が異なります。
なので、物流はどういう情報を必要としていて、どういうことが分かって、何が分からないのかを把握していないと、コミュニケーションが上手くいきません。
お互い様ではありますが、物流側で必要な情報を把握することで、やり取りも円滑になります。
大切なのは、顧客対応と受注処理の連携強化
受注処理で起こるトラブルは、顧客対応と密接にかかわってきます。
あ～だから顧客担当が処理することがあるのか、って思ってもらえると書いた甲斐があるので、そう思ってください。
トラブルに発展するのは、キャンセル希望をしていたのにとか、お届け先変更希望をしていたのに出荷されたといった、カスタマーに希望を出していたのに出荷されてしまったというケースが殆どです。
基本的なことですが、対応できる要望を反映した処理を心がけています。
まとめ
ECサイトの受注処理と一言にまとめるのは実はできなくて、結構独自の運営をしていることも多いです。
今回は一連の流れの中で、経験上一般的だと考える内容で書いてみました。
前置きは手短でしたけど、手短に言えるのはこのくらいって感じですね。
さて、今日は（いつもの）ビールで乾杯します。
