返品・交換システム：申請から検品、返金、交換品の出荷まで
2点の返品申請に対して届いたのは1点。もう1点はサイズ交換を希望。申請、実際の入荷、商品の状態、金銭処理をつなぎ、カスタマーサポート・倉庫・経理が同じ記録で対応できるようにします。
ネットショップと実店舗を持つ衣料品店を想定します。顧客は購入したシャツのうち1点を返品し、もう1点を大きいサイズに交換したい。サポートが相談を受け、店舗が荷物を預かり、倉庫が交換品を用意し、経理が返金します。連絡が別々だと、何が届き、いくら返金し、交換品が確保できたのかが分かりにくくなります。
返品・交換システムは、この購入後の業務をつなげられます。Shopifyには顧客の申請と返品処理、Microsoft Dynamics 365には返品承認、倉庫での検品、処置を扱う機能が記載されています。以下では、各商品の行き先と顧客の次の操作を軸に、自社向けに設計できる機能を説明します。
Shopify — Self-serve returns and cancellations · Microsoft Dynamics 365 — Sales returns
顧客は商品を選び、サポートは申請一覧で確認する
ログインまたはメール認証後に、購入した種類、サイズ、数量、申請対象の商品を表示します。顧客は数量、理由、返金か交換かを選び、必要に応じて写真を添付。申請後は受付番号と返送方法を確認できます。注文番号だけで他人の住所や購入履歴を閲覧できないようにします。
サポートは「情報待ち」「承認待ち」「返送待ち」で絞り込み、元の注文、過去の返品、添付資料を一画面で照合できます。社内規定の期限や数量を超える申請は、権限のある担当者が理由を残して判断。同じ商品の再申請は元の受付につなぎ、二重返金を防ぎます。
入荷画面で実際の数量を記録し、在庫に戻すか判断する
店舗や倉庫の担当者は受付番号を読み取り、予定商品と実物の数量、サイズや製造番号、包装状態、検品写真を照合します。2点中1点だけ届いたら、その1点だけを受け付け、残りは未着のまま残します。番号のない荷物や商品違いは確認待ち一覧に入り、サポートが同じ記録で顧客に確認できます。
検品結果は、再販売可、整備待ち、追加確認待ち、再販売不可などに分け、保管先も記録します。入荷と販売可能在庫への追加は別の操作にします。返品が承認されたという理由だけで、汚れのある衣服を販売在庫に戻してはいけません。Microsoftの文書でも入荷・検品・処置を分け、数量の分割を扱っています。
交換品の出荷と返金結果を別々に追う
交換画面には候補の種類、在庫拠点、取り置きの有無と期限を表示します。返品到着後に確保する運用なら、申請時にその旨を伝えます。在庫切れの場合はサポートが代案を示し、顧客の選択を記録。Shopifyの現行文書では返品処理時に交換品を確保するため、申請だけで取り置き済みとは扱えません。
金銭処理画面では、元の割引後金額、交換の差額、社内方針に従う費用を明細ごとに表示します。経理は計算を確認し、決済サービスの返金番号と成功・失敗を記録。失敗は未処理のまま残し、返金完了通知を出しません。交換品には別の出荷記録と追跡番号を関連付けます。
顧客には進捗、担当者には残っている作業を見せる
顧客ページには申請受付、返送案内、到着した商品、返金処理状況、交換品の出荷、追加で必要な情報を表示できます。社内画面には検品結果、決済の失敗理由、作業担当も表示。店舗の担当者には受付・照合の権限を与え、返金権限は必要に応じて分けます。
一つの受付番号の中に「1点は返金済み、もう1点は返送待ち」があっても扱えるようにします。残る作業で一覧を並べ、数量変更、例外承認、通知の担当者と日時を記録します。商品担当は種類別の返品理由からサイズ説明や包装を見直せます。顧客の写真は必要な担当者だけが閲覧できるようにします。
ネットショップ・POS・倉庫のどこに更新が届くか確認する
Shopifyのコミュニティには、返品・交換の更新がShopifyには反映されてもLightspeed／Vendには反映されないという投稿があります。個別の報告であり、すべての連携に同じ問題があるとは言えません。ただ、一方の成功表示だけでは他方の在庫を確認できないことが分かります。連携画面には送信先、商品対応、拠点、処理結果、再試行できる操作を表示します。
地域と倉庫設定も実際に確認します。Shopify内での返品ラベル作成は、主な拠点と顧客住所の両方が米国にあることが条件です。香港では配送会社との連携やラベルのアップロードを別途確認します。ShipStationの文書では元のShopify出荷拠点に在庫を戻すとされています。別の検品倉庫で受け取る場合は実際の入荷先と移動を記録し、再試行で返金や在庫追加が重複しないようにします。
Shopify Community — Return and exchange stock updates in Lightspeed/Vend · Shopify — Creating returns and exchanges · ShipStation — Restocking returned items with Shopify
衣料品・電子機器・卸売に合わせて検品項目を変える
衣料品ではサイズ、タグ、着用の跡、電子機器では製造番号、付属品、動作確認結果を記録できます。卸売では箱・個数・ロットを分けて受け付け、クレジットノートを発行する場合もあります。商品分類ごとに項目と処置を設定し、毎回サポートが備考に書き直す手間を減らせます。修理が必要なら修理記録を関連付け、元の返品履歴も残します。
ReturnGOの販売店レビューには、セルフサービスでの申請、多言語、写真、業務フローの設定に関する声があり、設定支援が必要だったという意見もあります。実際の利用場面を示す情報ですが、どの会社も作り直すべきだという根拠にはなりません。既存機能を活用し、つながっていない入荷、検品、金銭処理に個別開発を絞れます。
支払い前のデモで、返金と交換を含む申請を試す
ProAppは支払い前にデモを提供します。返品・交換システムでは、匿名の商品データと普段の返品ルールを使い、顧客、サポート、倉庫、経理の操作を順に確認する流れを相談できます。示す画面と例外を整理してから、開発範囲を確認します。
- 1点の返金と1点のサイズ交換を申請し、承認後に顧客の返送案内を確認します。
- 1点だけを受け取り、汚れと整備待ちの保管先を記録。残りが未着で、販売可能在庫が増えていないことを確認します。
- 2点目を受け取り、希望サイズの欠品、差額、顧客による代案選択を試し、交換品と追跡記録を確認します。
- 返金や在庫連携の失敗と再試行を確認。経理は返金番号、サポートは進捗通知を確認し、処理が重複していないか照合します。
まず一つの商品分類と一つの受付拠点をつなぐ
匿名の注文、よくある返品、現在のルール、受付拠点、担当者の権限を用意します。まず一つの商品分類で、申請、承認、入荷、検品、返金または交換を最後までつなぎます。その後に複数店舗、ロット、修理の分岐を追加。サポートは商品の所在、倉庫は保管先、経理は未完了の支払い、顧客は待つべきか情報を送るべきかを確認できれば、一連の業務がつながります。
