配送中の破損を記録する｜荷物・商品・連絡履歴をまとめる

報告内容と確認できた事実を分ける

顧客が「箱が潰れていた」と伝えたこと、写真で角の損傷を確認したこと、中の商品が使えるかは別の情報です。報告日時、顧客の説明、写真で分かる状態、未確認事項を分けます。配送中の破損か、梱包時の問題かを最初から決めつけず、必要な確認を進めます。顧客へは何をいつ確認するかを伝え、社内の推測を事実として案内しません。

注文・荷物・商品の参照をそろえる

破損案件ID、注文ID、発送ID、SKU、数量、到着日、報告日、写真の参照先、担当者を記録します。分割発送ならどの荷物かを特定します。架空案件D-114で一つの箱に商品が3点あり、破損が1点なら、その対象と残りの状態を分けます。写真のファイル名だけに頼らず、何を写しているかを短く説明します。

必要な写真と保管の案内を絞る

外箱全体、損傷箇所、緩衝材、対象商品の状態など、判断に必要なものを具体的に依頼します。配送ラベルには個人情報があるため、共有先や保存場所を限定します。危険な破片や漏れがある場合は、写真のために無理な作業を求めません。保管や廃棄については利用する配送会社や自店の対応方針を確認して案内します。

交換・返送・返金の判断を別に管理する

確認待ち、対応方針確認、交換手配、返送待ち、完了などの状態を決めます。交換する判断と交換品を発送した状態は分けます。顧客への案内、社内承認、配送会社への照会が並行しても、一つの担当窓口で履歴をまとめます。補償や対応可否を断定する前に、対象の取引と各条件を担当者が確認します。

追加の写真や再送が発生したとき

追加資料は元の案件へ紐付け、新しい破損案件を自動で作らないようにします。再送品には別の発送IDを付け、元の荷物の調査は必要に応じて残します。顧客へ二つの担当から同じ資料を求めたり、交換品を二重に送ったりしないよう、依頼と実行結果を確認します。対応が途中で変わった理由も残します。

顧客対応と原因の振り返りを分ける

交換が届いた、返金が確認できたなど、顧客対応の完了条件を定義します。原因が未確定でも対応を終える場合は、調査の残件を別に残します。振り返りでは商品、梱包方法、配送経路、発生数を見ますが、少数の写真だけで原因を断定しません。改善した梱包を使った後も、同じ条件で結果を確認します。

D-114：交換後に調査だけが残る例

確認用のD-114では、破損の報告を受けて交換品を送り、顧客が到着を確認したとします。顧客対応は完了にできますが、配送会社への照会が残るなら調査の担当と確認日を残します。交換品の発送IDは元の荷物と分け、届いた写真ややりとりは同じ破損案件へ紐付けます。後から原因が分かった場合は、その結論と根拠を加えます。原因不明の間は写真だけで梱包が悪い、配送が悪いと断定しません。顧客への対応速度と原因を調べる時間は異なるため、どちらか一方の状態で全部を表さないことが要点です。

写真を受け取る際は、どの角度を追加してほしいかを具体的に示します。ただし判断に必要のない背景や個人情報まで撮らせないようにします。提出された写真の保存場所と閲覧できる人をそろえ、担当者の個人端末だけへ残さないことも大切です。顧客の説明が追加された場合は、最初の報告と分けて記録し、内容が変わった理由を確認します。社内で同じ案件の説明が複数作られると対応方針がずれるため、外部へ伝える内容は担当窓口がまとめます。交換や返送を進める前に、送り先と対象商品をもう一度照合します。

道具と費用を増やす前に確認する

発生が少なければ、管理番号を付けたフォルダと共有表で始められます。費用には交換品、送料、返送、写真確認、顧客対応の時間を含めます。フォームを使う場合は必要な画像容量と閲覧権限を確認し、Makeなどの連携は資料の転記が繰り返す部分だけに追加します。件数削減のために受付を難しくするより、必要な確認を短くそろえる方が運用しやすくなります。

• Tallyでファイル提出フォームを作る｜容量・形式・共有リンクの管理
• MakeとShopifyを連携する方法｜注文の記録と担当者への通知
• Makeで納品ファイルの送付を管理する｜承認版・宛先・再送の確認