OMS 반품 플로우 설계: RMA, 환불 트리거, 재입고 로직을 한 번에 정리하기

환불은 화요일에 나갔다. 박스는 돌아오지 않았다.

올해 3월, 캘리포니아주 온타리오에 있는 생활용품 창고의 시스템을 점검하던 중 재무팀과 고객서비스(CS)가 $120를 놓고 다투는 모습을 봤다. 고객이 반품을 신청했고, 택배사의 스캔에는 "인수됨"으로 표시되어 있어 CS는 회사 방침대로 환불을 진행했다. 그런데 3일 후 그 패키지는 운송 중에 사라졌다. 돈은 사라지고, 재고도 사라지고, 두 부서는 누구 잘못인지 따지느라 오후를 보냈다.

근본 원인은 CS도 재무도 아니었다. 세 가지 기본 질문에 답하지 못한 OMS 반품 모듈이었다. 언제 환불하는가, 무엇을 누가 승인하는가, 박스가 돌아오면 누가 주인인가. 이 세 가지가 정해지기 전까지 반품 플로우는 열린 상처 그대로다.

결론부터 말하겠다. 반품 설계의 80%는 돈이 움직이기 전에 일어난다. 나머지 20%는 박스가 돌아온 뒤에 일어난다. 순서를 바로잡아라.

모든 반품에 쓸 만한 ID를 붙여라

모든 반품에는 RMA, 즉 반품 상품 승인 번호가 필요하다. 반품의 신분증이라고 생각하면 된다. 권장 형식은 접두사 + 날짜 + 일련번호, 예를 들면 RMA-20260314-00427이다. UUID 같은 문자열은 피하자. 창고 직원은 라벨에서 32자 16진수 코드를 읽을 수 없고, 라벨 오기재 박스는 생각보다 자주 발생한다.

번호 규칙이 정해지면 세 가지를 함께 확정한다.

주문당 RMA 몇 건? 고객이 세 개를 사서 두 개를 별도의 박스로 반송한다. 지금 정하자. 박스당 RMA 한 건을 권장한다. 운송장 번호와 실제 박스가 일치하고, CS가 실제로 찾을 수 있게 된다.

셀프서비스 반품 포털을 만들어라. 고객이 사유를 선택하고, 사진을 올리고, 라벨을 출력하는 전 과정을 한 흐름에서 처리한다. 중요한 디테일 하나: 사유는 반드시 드롭다운으로, 자유 입력란은 절대 안 된다. 자유 입력 사유는 리포트로 집계할 수 없고, CS가 매 건을 수작업으로 해석하게 된다. 쓰레기가 들어가면 쓰레기가 나온다.

모든 RMA에 만료일을 붙여라. 반송까지 7일이 합리적인 출발점이다(샘플이며, 카테고리와 평균 주문 금액에 맞게 조정하라). 포털에 명확히 표시한다. 만료일 없는 RMA는 고아 레코드가 된다. 2024년에 반품률 18%에 반년 넘게 방치된 미처리 RMA 2,000건이 넘는 의류 창고를 봤다. 어떤 박스가 아직 "운송 중"인지 아무도 말할 수 없었다.

언제 환불 버튼을 눌러 것인가? 세 가지 타이밍, 세 가지 리스크 프로파일

환불 트리거는 팀이 싸우는 지점이다. 현금 리스크와 고객 경험 사이의 정면 트레이드오프이기 때문이다. 세 가지 모델이 있다.

인수 스캔 시 환불. 택배사가 "인수됨"을 표시하면 환불한다. 경험은 최고, 리스크도 최고. 분실 박스, 빈 박스, 바꿔치기 모두 회사 부담이다.

창고 입고 시 환불. 돈이 움직이기 전에 박스를 받아 등록한다. 리스크는 통제 가능. 고객은 보통 3–5일을 더 기다린다.

검수 후 환불. 박스를 열어 상품을 등급 판정하고 나서야 환불한다. 가장 안전하지만 사이클이 7–10일로 늘어나고 고객은 싫어한다.

내 판단은 이렇다. 전 카탈로그에 하나의 규칙을 적용하지 마라. 저가 상품(예컨든 $30 미만—샘플 기준)의 경우 가끔 분실되는 박스 비용이 CS 왕복 응대 비용보다 작으니, 인수 시 환불은 합리적인 승부다. 스니커즈, 화장품, 전자기기 액세서리처럼 고가에 바꿔치기 쉬운 카테고리는 검수 후 환불로 가라. 트리거는 사이트 전체가 아니라 OMS에서 카테고리별로 설정한다.

승인 규칙도 같은 단계식으로 간다. 예시 구간: $75 미만 자동 승인(샘플이며 자사 평균 주문 금액에 맞게 조정하라), $75에서 $300는 CS 슈퍼바이저 승인, $300 초과는 재무 승인. 그리고 수동 리뷰를 강제하는 레드라인은 OMS 규칙 엔진에 하드코딩하라. 벽 포스터에 붙이는 게 아니라. 같은 계정이 30일 내 3회 이상 반품(샘플), 품질 클레임 기록이 없는데 "불량"을 반복 선택, 교환 요청을 처리 중간에 환불로 전환 등이다.

박스가 돌아왔다. 이제 어떻게?

반송된 박스의 행선지는 딱 세 가지다. 지금 정하고 OMS↔WMS 상태 매핑을 한 번만 만든다.

재판매 가능. 포장 온전, 태그 부착 → 일반 슬롯으로 복귀. OMS 상태 "resellable", WMS는 표준 입고를 수행.

수리 또는 리퍼브. OMS "repair", WMS는 수리 구역으로 이동. 수리가 끝나면 상태를 판매 가능으로 되돌린다. 그리고 그 전환은 OMS에 반드시 기록해야 한다.

폐기. OMS "scrap", WMS는 폐기 구역으로 이동하고 재무가 상각 처리한다. 시스템에서 "pending" 상태로 석 달을 방치하지 마라.

반품 입고 스테이션에서 반품을 처리하는 창고 직원

고전적인 실패는 두 시스템이 별도 장부를 쓰는 것이다. OMS는 "refunded"라는데 박스는 WMS 검수 대기열에 미처리로 쌓여 있거나, 반대로 WMS는 이미 재입고했는데 OMS에서 환불이 "pending inspection"에 묶여 있다. 로스앤젤레스의 한 3PL에서는 두 시스템이 한 번도 정합되지 않고 전부 수작업 스프레드시트로 돌리다 보니 검수 구역에 반품 400+건이 쌓인 현장을 본 적 있다.

해결책은 별게 아니다. OMS가 반품을 "received"로 표시하면 WMS가 입고 태스크를 자동 생성한다. WMS가 "sellable"로 판정하면 OMS가 환불을 해방한다(검수 후 환불 모델인 경우). 상태 변경은 API로 실시간 전송하고, 두 시스템이 어긋난 주문을 모두 플래그하는 야간 정합 잡을 추가한다. API는 다운된다. 정합 잡이 안전망이다. 둘 다 필요하다.