ECの返品・交換はどこまで自動化する？受付後の商品・返金まで比べる

休み明けに返品・交換のメールがたまり、注文を調べて、同じ案内を何度も返す。休日にも申請を受けられるようにしたいけれど、倉庫や経理の仕事はどう変わるのでしょうか。

自動化を選ぶときは、申請受付から返送品の確認、交換品の確保・発送、返金の結果確認まで、任せられる仕事と社内に残る対応時間を比べます。受付が早くなっても、商品とお金の処理が手作業で残るなら、その担当と時間は引き続き必要です。

受付済みでも、商品の処理と返金は残る

申請を受けて内容を記録し、お客様に受領を知らせたら、受付の仕事はいったん完了します。その時点で、商品が倉庫に戻っているとは限りません。交換品を確保できたか、返金額が決まったかも別の確認です。

この違いを分けておくと、休日に進められる仕事と、倉庫や経理が動く時間に残す仕事が見えてきます。

戻った商品と、交換で送る商品を確かめる

返品では、倉庫での受取と検品を分けて考えます。到着を記録した後も、商品の状態を確かめ、販売可能な在庫に戻すか、別の扱いにするかを決める仕事が残ります。到着したという情報だけで、再び販売できるとは判断できません。

交換では、送る商品の在庫確認と確保も必要です。在庫数が表示されていても、その交換用に確保できたかは別です。金額に確認事項があれば、それを解決したうえで発送へ進めます。発送結果と在庫への反映、お客様への案内までを、担当が追えるようにします。

返金の依頼と、返金結果の確認を分ける

返金は、確定した金額で処理を依頼する仕事と、決済側の処理結果を確認する仕事に分かれます。依頼を出しただけで完了にすると、失敗や処理待ちが残っていても見落としかねません。

金額は確認済みの店舗方針と注文内容に沿って確定し、返金結果を確認してお客様へ案内します。方針の解釈が分かれる案件は、店舗責任者の確認へ戻します。結果がまだ出ていない案件には、誰がいつ再確認するかを残します。

今の運用で足りるか、サービスへ移すか

同じ申請を複数の一覧へ写したり、受付通知の後に同じ内容を手動でも返信したりしているなら、まず、その作業が本当に必要かを確かめます。不要と確認できた重複は、自動化せずにやめる選択があります。

一方、必要な仕事でも、確認の仕方や案内文が担当ごとに違うために往復が生じているなら、今の運用をそろえるだけで続けられるかもしれません。次の選択肢は導入の順番ではなく、残っている仕事に応じて選ぶものです。

ここでいうSaaSは、契約して使う既存のクラウドサービスです。比べるときは、受付だけを任せる前提にせず、返送品の情報、交換品の確保、返金、在庫への反映、顧客への連絡まで、どこを扱えるか確かめます。任せられる範囲は、サービスの機能に加え、店舗の運用や契約・接続条件によって変わります。

対象にしたい返品・交換を標準機能で扱えるなら、それだけで足ります。確認が必要な案件を人へ戻せることや、社内に残る処理を担当時間内に終えられることも含めて比べます。

追加連携を考えるのは、必要な情報を別の仕組みへ転記する仕事や、注文・在庫・決済の間の状態の食い違いが、実際に残ると確認できた場合です。単に案内文や社内の判断がそろっていないなら、接続を増やしても解決しません。

標準機能でも連携でも埋まらない仕事が具体的にある場合は、その部分に限った開発を候補にします。何が不足するか、接続できるか、変更後に誰が維持するかが分からないうちは、連携も開発も保留します。

架空のアパレルECなら、今回は定型返品の受付から

ここからは、自社のオンラインストアで服を販売する架空の会社の例です。返品・交換の方針は店舗責任者が確認済みとします。新しい受付期限や送料負担を決める例ではありません。

この店では、同じ条件の返品について、申請を受け、注文を照合し、決まった案内を返す作業が繰り返されています。その部分を既存の標準サービスで扱えると動作確認できた、という設定です。交換品の在庫確保や金額確認、検品後の判断まで機械へ移せるかは、まだ確認できていません。

申請上の条件がそろう定型返品

今回移すのは、申請内容と注文情報から受付条件を確認できる返品です。標準サービスに申請の記録、注文との照合、受領通知、確認済みの案内文の送付を任せます。条件から外れる申請は自動承認せず、CS担当が店舗責任者へ確認します。CS担当とは、お客様への対応を受け持つ担当者です。

休日にも受領通知は返しますが、その日に検品や返金まで終わるとは案内しません。CS担当は次の店舗営業日の始業時に未処理の申請を確認します。倉庫担当は倉庫稼働日の午前に検品の時間を取り、経理担当は店舗営業日の午後に返金額と処理結果を確認する時間を残します。

この返品を完了にするのは、返送品の受取・検品、在庫の扱い、確定額での返金結果、お客様への案内がそろったときです。受付済みの表示だけでは閉じません。

交換品の在庫と金額が、まだ確かめられていない申請

この交換は今のメール対応に残します。CS担当が次の店舗営業日の午前に注文と希望商品を確認し、倉庫担当へ在庫の確保を依頼します。金額の確認が必要な点は、経理担当が同日の返金・精算の確認時間に調べます。既存方針で判断できなければ、店舗責任者が決めるまで進めません。

在庫を確保でき、金額の確認が済んだら、既存方針に沿って倉庫担当が倉庫稼働日の出荷時間に交換品を発送します。返送品の在庫処理、交換品の発送結果、必要な金銭処理とお客様への連絡を確認して、この交換を完了にします。

在庫や金額が確定しない間は、CS担当が保留案件を受け持ち、次の店舗営業日の午前に再確認します。お客様には何を確認中かと次に状況を案内する日を伝え、未確定の発送や返金を約束しません。

返送された服が、検品待ちになっている案件

商品は届いていても、状態を確認できていない案件です。記録は「到着・検品待ち」とし、到着を理由に返金や販売可能在庫への復帰を自動で進めません。

倉庫担当が次の倉庫稼働日の午前に現物を確認します。扱いを判断できない商品は店舗責任者へ確認し、判断後に在庫を反映します。返金へ進める状態になったら、経理担当が店舗営業日の午後の確認時間に金額と処理結果を確かめます。

検品が終わらない案件は、CS担当が次の店舗営業日の終業前に倉庫へ状況を確認し、お客様へ案内します。待ちの間もCS担当が案件を持ち続け、商品の扱いと返金結果、必要な連絡を確認してから完了にします。

この店が残すのは、営業日の確認時間

この会社が選ぶのは、定型返品の申請受付・注文照合・案内だけを標準サービスへ移すことです。休日の手動の受領返信はやめる一方、CSの営業日の確認、倉庫の検品、経理の返金確認に使う時間は引き続き確保します。交換や検品の判断が残っているため、その勤務時間を減らす判断はしません。

交換品の確保や返金の連携へ広げるのは、確認方法と担当を決め、正しく処理できると確かめてからです。この店の未確認部分が残るうちは、受付の自動化だけを理由に対象を広げません。

対象を増やす前に、残った仕事が回るかを見る

見直すときは、同じ種類の返品・交換について、導入前に人が行っていた仕事と、導入後も人が行う仕事を比べます。手動の受領返信がなくなっても、倉庫への照会や返金の照合が増えていれば、会社全体で残る時間はその分も含めて見ます。自動で受けた件数だけでは、勤務時間をどこまで減らせるかは決まりません。

金額が違う、確保したはずの在庫が合わない、同じ注文を二重に処理した、といった問題が出たら、対象の拡大を止めます。影響する自動処理を止めて担当者が確認し、原因と修正後の結果を確かめるまでは、その範囲を人の確認に戻します。責任を持つ人が決まっていない処理も広げません。

保留にする案件には、待っている理由と担当、次に確認する日を残します。「倉庫からの返事待ち」で止めず、CS担当が次の営業日に確認してお客様へ案内するところまでを、残る仕事として引き受けます。接続や維持担当が未確認の連携は、店舗責任者が提供元への確認担当と次の確認日を決めるまで、候補のままにします。

自動化の範囲は、繰り返す仕事を何に任せるかと、会社に残す人の時間を一緒に決めるものです。標準サービスで足りるならそこで終え、未確認の交換や検品は人が受け持つ。その線引きができれば、受付の便利さと、商品・返金まで取引を終えられる体制を分けて比べられます。

定型申請から分かれる個別相談の窓口も考えるなら、問い合わせ窓口の選び方へ。

コンテンツ一覧へ戻る