<div id="readability-page-1" class="page"><div><article><div><div><p id="fab1">안녕하세요. <br>무신사 커머스코어실 주문서비스팀에서 주문과 클레임 영역을 담당하는 PM으로 일하고 있는 이관호입니다.</p><p id="279f">여러분께서는 혹시 ‘클레임(claim)’이라는 단어를 들어보셨나요? E-commerce 도메인에서는 일반적으로 취소/교환/환불을 클레임이라고 칭하는데요.</p><p id="92fa">무신사에서는 지금 이 순간에도 다양한 종류의 클레임이 접수되고 있습니다. 이에 CX, 물류, 재무 등 다양한 부서와 협업을 하게 되는데요. 이로 인해 클레임 도메인 PM은 정책에 대한 이해, 원활한 소통 능력, 다각도의 문제 해결력이 필요합니다.</p><p id="608a">저는 무신사에서 약 3년 동안 주문, 결제, 클레임의 프로젝트를 진행해왔는데요. 이 과정에서 커머스 서비스, 특히 클레임에 대한 이해가 깊고 넓어지는 경험을 하였습니다. 오늘 이 글을 통해서, 클레임, 그 중에서도 환불을 중심으로 커머스코어 PM으로서 문제를 발견하고 해결하는 과정을 공유하고자 합니다.</p></div><div><h2 id="e544"><strong>1. 클레임은 무엇이고 어떤 특성을 가지고 있는가?</strong></h2><p id="61e0">클레임은 단순 변심, 상품불량 등 다양한 사유로 인해 거래 조건이 변경되고, 이를 조정하기 위한 일련의 과정을 의미합니다.</p><p id="bd4d">이커머스 도메인에서는<strong> 일반적으로 취소/교환/반품(환불) 서비스</strong>가 클레임 도메인에 포함되어있습니다. 저는 무신사에서 주문, 결제, 클레임 과제를 주로 진행했는데요. 제가 경험해 본 클레임 도메인은 다른 도메인 대비 복잡도가 높고, 운영 업무에 대한 이해가 필요하다는 특성이 있습니다.</p><p id="563d">클레임 도메인이 복잡한 데는 3가지 이유를 꼽을 수 있습니다.</p><p id="2979"><strong><em>첫번째는 클레임이 고객 경험의 최종 단계에 있기 때문</em></strong><em>입니다. </em>일반적으로 클레임 서비스는 상품 탐색 &gt; 주문&gt; 결제 &gt; 배송 &gt; 환불(교환)의 고객 여정중에 마지막에 위치합니다. 이는 환불 서비스가 상품, 주문, 세일, 배송, 결제, 정산, 파트너 등 다양한 서비스의 영향을 받는 것을 의미하며 클레임은 앞에서 처리되는 정책과 정보를 반영해야 합니다.</p><p id="03a3"><strong>두 번째로, 클레임 문제의 해결은 단방향적인 처리가 아닌 고객, 플랫폼, 파트너 간의 양방향적인 처리를 요구하고, 이 때문에 클레임 프로세스에서 정보는 계속 변화하는 속성</strong>을 가지게 됩니다. 클레임은 변화하는 각 속성에 따른 상태가 필요하고 그로 인해 복잡도가 증가합니다.</p><p id="85bb"><strong>세 번째로 클레임 업무는 온라인에서 끝나는 것이 아니라 오프라인 활동까지 이어지는 특성을 가지고 있습니다</strong>. CS, 배송(회수), 검수, 정산 등 내부 구성원과 파트너의 업무에 대한 이해가 필요하며 이를 온라인 서비스에 반영할 수 있어야 하죠.</p><p id="a245">이러한 세 가지 특성으로 인해 클레임 도메인은 복잡하며, 클레임을 담당하는 PM에게는 창의성보다는 정책에 대한 이해, 논리력이 요구됩니다.</p></div><div><h2 id="0cba"><strong>2. 클레임 영역의 문제 : 환불 구조를 개선하다</strong></h2><p id="3997">무신사가 성장하면서 다양한 영역의 서비스들이 고도화되고 있습니다. 앞으로 다양한 주문/배송/할인/클레임 서비스들이 제공되겠죠. 예를 들어 새로운 결제 수단, 할인 정책, 티켓과 같은 새로운 상품군이 추가될 때마다 클레임은 대응해야 합니다.</p><p id="2dc9">환불 구조 개선은 장기적으로 무신사 서비스가 발전할 방향을 그려보고, 이를 준비하기 위해 진행한 과제였습니다. 그리고 예상한 것보다 많은 문제를 해결할 수 있는 작업이었습니다.</p><p id="4e72">환불 금액은 어떤 특성을 가지는 정보일까요? 환불은 모든 구매 프로세스의 종료 후에 추가적으로 일어나는 것으로, 기본적으로 고객이 결제를 통해 입력한 정보를 토대로 처리됩니다. 지금 이 글을 읽는 분들도, 온라인 쇼핑을 하다 환불한 경험이 한 번쯤은 있으실 것입니다. 혹시 일정 금액 이상을 충족하면 할인해주는 쿠폰을 적용한 후에, 부분 환불을 해보신 경험이 있으신가요? 이럴 때 돌려받을 금액은 얼마가 되어야 할까요? 기존의 무신사의 환불 구조 개선을 통해 부분 환불과 관련된 문제를 해결한 사례를 공유합니다.</p><p id="cf2e">환불구조의 개선 전(As-is)과 개선 후(To-Be)를 비교해놓은 [그림1] 이미지를 통해 문제 발견 과정을 설명드릴게요.</p><p id="ffc9">이미지의 왼쪽은 기존 무신사 환불 금액 구조입니다. A, B, C 상품을 함께 구매할 경우, 주문 번호 하나에 결제 정보가 저장되며, 환불 또한 하나의 주문번호를 기준으로 처리됩니다. 이 구조에서 할인이 적용되는 경우, 주문 번호에 할인이 적용되므로, 할인은 전체 주문에 각 상품이 차지하는 비율만큼 할당되어 계산됩니다. 5,000원 짜리 상품을 2개 주문한 후 1,000원 할인을 받았다면, 각각 상품은 4,500원이 됩니다.</p><figure><figcaption>[그림1] 환불구조 As-is/ To-be</figcaption></figure><p id="2aa8">이러한 구조는 정해진 금액을 결제하고 환불해주는 기본적인 환불 서비스에서는 문제가 없습니다. 하지만 추후에 10만 원 이상 구매 시 5천 원 할인과 같은 장바구니 할인이 생기게 되면 어떻게 될까요? 구매 금액에 따라 할인이 적용/취소되어 재계산되는 서비스가 아닌 할인 금액이 상품별로 저장되고 저장된 금액을 제외한 금액을 환불하는 서비스를 제공하게 됩니다. 이러한 환불 서비스는 구매 금액 조건에 충족하지 않음에도 일부 금액을 할인 받거나, 구매금액 조건을 충족하더라도 할인을 일부만 받는 문제가 발생합니다.</p></div><div><h2 id="0572">3. 환불 구조 개선 전과 후</h2><p id="d565">10만원 이상 구매 시 5천원 할인이 있는 상태에서 15만원을 결제하고 부분 환불하는 경우(각각 10,000원, 60,000원 부분 환불)를 예로, 개선 전과 후를 비교해서 설명해 보겠습니다.</p><p id="bff6"><strong>1)환불 구조 개선 전 기존 로직(주문 기준 환불금액을 한 개만 관리)<br></strong>기존의 상태에서는 부분 환불을 할 경우, 각 상품별로 쿠폰의 할인율이 적용되고 남은 금액이 환불됩니다.</p><p id="4950">a. 10,000원 상품을 부분 환불하는 경우<br>고객은 5,000원의 전체 할인 금액 중 상품별로 계산된 할인 금액인 333을 제외한 9,667원을 환불받게 됩니다. 즉 구매 금액 조건을 충족함에도 333원의 손해를 보게 됩니다.</p><figure><figcaption>[그림2] 10만원 이상 구매 시 5천원 할인 적용 → 1만원 환불했을 경우, 금액 정보</figcaption></figure><ul><li id="90f5"><em>환불금액 9,667원 =10,000원(주문금액) — 해당 상품의 쿠폰할인금액(333원)</em></li><li id="c9ba"><em>333원은 전체 할인금액 5,000원을 전체금액에서 해당상품이 차지하는 비율만큼 나눠서 나온금액(5000/150000*10000)</em></li></ul><p id="7a08">b. 60,000원 상품을 부분 환불하는 경우<br>고객은 58,002원할인 받게 되며, 구매금액 조건을 미충족함에도 3,002원 할인을 받게됩니다.</p><figure><figcaption>[그림3] 10만원 이상 구매 시 5천원 할인 적용 → 6만원 환불했을 경우, 금액 정보</figcaption></figure><p id="c31f"><em>- 환불금액 58,002원 = 60,000원(주문금액) — 해당 상품의 쿠폰 할인금액(1,998원)<br>- 1,998원은 전체 할인금액 5,000원을 전체금액에서 해당 상품이 차지하는 비율만큼 나눠서 나온 금액 (5000/150000*60000)</em></p><p id="f08c">기존 환불구조는 주문번호 별 하나의 환불 금액만 관리하기 때문에 장바구니 할인 정책이 명확하지 않은 문제점이 있었습니다.</p><p id="2761">이를 해결하기 위해 상품단위 별 환불금액을 관리할 수 있도록 환불 구조를 개선했습니다. 다시 위의 [그림1]의 오른쪽 이미지를 통해 확인할 수 있듯이, 상품 A, B, C를 한번에 주문하더라도<strong> 환불금액과 잔액을 상품별로 관리</strong>하도록 변경하였고, 이러한 개선을 통해 부분환불에 대한 합리적인 정책의 서비스를 제공할 수 있게 되었습니다. 이해를 돕기 위해 이제는 개선된 구조에서 같은 시나리오로 부분환불이 일어나는 상황을 설명드리겠습니다.</p><p id="3783"><strong>2) 환불 구조 개선 후 재계산 로직(상품 단위로 환불금액 관리)</strong></p><p id="9edd">a. 10,000원 상품을 부분 환불 하는 경우<br>고객은 10,000원을 환불받게되고 구매금액 조건 할인은 적용됩니다.<br>- 상품 금액을 재계산 해서 상품 A에 할인금액 5,000원 적용</p><p id="60e4">b. 환불금액 60,000원 상품을 부분환불하면 구매금액 충족시 할인(5,000원)은 미적용되고, 할인 받았던 5,000원을 제외하고 55,000원을 환불받게 됩니다.<br>- 금액조건이 깨짐으로 할인금액 제외하고 환불</p><p id="330c">장바구니 할인은 고객들에게 익숙한 할인이고, 비즈니스 환경에 따라 제공할 여지가 있는 서비스이기 때문에 미리 환불 구조를 개선할 필요가 있었습니다. 또한 클레임 서비스 내에서도 상품 단위로 환불 금액을 관리하지 않기 때문에 환불 서비스를 고도화 하는 데 어려움이 있었습니다. 예를 들어 검수 결과에 따른 자동 환불 금액 계산은 검수 결과에 따른 환불차감액을 상품 단위로 관리되어야 하며, 부분 수량 환불은 상품단위로 환불액과 환불 잔액을 관리해야 합니다. 예시의 서비스를 제공하고자 했지만 구조 한계로 서비스를 제공하는 데 어려움을 겪고 있기 때문에 팀 내에서는 무신사 클레임 서비스의 발전을 위해 필수적으로 진행해야 하는 과제로 인식하고 있었습니다.</p></div><div><h2 id="461c">4. <strong>필요하지만 성과를 바로 확인할 수 없는 과제는 어떻게 추진하는가?</strong></h2><p id="fd5a">플랫폼 서비스에 대한 장기적인 관점과 팀 내부의 인식에서는 환불 구조 개선은 필수적인 과제였습니다. 다만 단기적인 관점에서는 환불 구조 개선은 투입되는 리소스에 비해 얻을 수 있는 성과가 부족했습니다. 임팩트 있는 서비스에 포함해서 구조 개선을 진행하는 것도 방안이었지만, 주어진 리소스가 한정적이기 때문에 과제의 범위는 가능한 한 축소되어야 할 필요가 있었기 때문입니다.</p><p id="576a">장기적으로는 큰 임팩트가 있지만 단일과제로는 임팩트가 부족한 환불 구조 개선을 진행하기 위해서는 내외부 관계자들에게 과제를 설명하고 설득하는 과정이 더 필요했습니다. 이를 위해서 클레임 서비스에 대한 로드맵을 세우고 앞으로 만들어갈 서비스와 이 서비스들을 만들기 위한 사전 작업을 정의하고 공유했습니다. 특히 실제 서비스를 운영하는 운영 부서에는 지속적으로 해당 과제의 필요성을 인지시키고 공유하여, 과제에 대해 같은 온도로 공감할 수 있도록 유도하였습니다.</p><p id="0bad">사실 무엇보다 중요한 것은 진행하고자 하는 의지였습니다. 단기간의 성과를 담보할 수 없고 긴급하지 않은 과제이기 때문에 충분히 나중에 할 수 있는 과제의 특성상 미루고자 한다면 충분히 미룰 수 있습니다. 하지만 도메인 담당자들이 개선 필요성을 공감했으며, 다음 기회가 언제 생길지 모른다는 생각에 의지를 가지고 프로젝트를 진행하게 되었습니다. 따라서 촉박한 일정임에도 불구하고 과제를 진행하기로 했고 성공적으로 작업을 마칠 수 있었습니다.</p></div><div><h2 id="4855">5. <strong>환불 구조 개선을 통해 얻은 것</strong></h2><p id="06fc">환불 구조 개선을 통해 무신사 클레임 서비스는 구조적 한계로 기존에 시작하지 못한 과제들을 진행할 수 있게 되었고, 클레임 서비스가 다음 단계로 나아갈 수 있는 토대가 마련되었습니다.(Ex. 반품비 차감 환불, 검수 결과에 따른 환불액 자동 계산, 부분 수량 환불)</p><p id="220a">클레임 서비스뿐만 아니라 장바구니 할인 같은 타 도메인에서 제공하는 서비스도 대응이 가능해졌고, 내부적으로 문제의식을 가지고 있던 클레임 정책들도 개선할 수 있었습니다.</p><blockquote><p id="177d">제가 생각하기에 가장 크게 얻은 것은 도메인의 관점에서 문제점과 개선점을 스스로 도출하고, 준비하였으며, 그를 통해 결과물을 낸 경험입니다. <strong>이 경험이 중요한 이유는 이런 경험이 차곡차곡 쌓여 더 나은 조직이 되고, 더 나은 서비스가 될 것이라고 생각하기 때문입니다.</strong></p></blockquote><p id="0284">도메인 특성상 유관부서 요구사항만 진행해도 1년의 과제는 충분합니다. 하지만 그 요청사항만 진행하다 보면 눈앞의 문제들만 해결할 뿐 장기적으로 발전할 수 있는 준비를 하지 못하는 경우가 많습니다. 이번 환불 구조 개선은 그런 의미에서 도메인 구성원이 함께 문제를 이해하고 공감하여 결과물을 만들어낸 성공적인 케이스였습니다.</p><p id="ce38">환불구조개선은 더 좋은 업무 방식과 서비스를 만드는데 있어 좋은 레퍼런스가 되었다고 생각하며, 앞으로도 이런 경험을 하나하나 쌓아 올려 더 좋은 서비스를 만들도록 하겠습니다.</p><p id="b978"><strong>We Are Hiring! </strong><br>무신사 커머스코어실에서 일하며, 무신사 서비스를 함께 개선하고 싶은 미래의 동료를 기다립니다. <a href="https://musinsa.wd3.myworkdayjobs.com/ko-KR/MUSINSA_Careers/details/Product-Manager---_JR0000000103?jobFamilyGroup=b420f29168e710016d87fdff57be0000" rel="noopener ugc nofollow" target="_blank">여기</a>에서 공고를 확인해주세요.</p><p id="290b">긴 글 읽어주셔서 감사합니다.</p></div></div></article></div></div>

MUSINSA tech - Medium

무신사 주문/클레임 PM의 환불구조 개선 이야기
안녕하세요. 
무신사 커머스코어실 주문서비스팀에서 주문과 클레임 영역을 담당하는 PM으로 일하고 있는 이관호입니다.
여러분께서는 혹시 ‘클레임(claim)’이라는 단어를 들어보셨나요? E-commerce 도메인에서는 일반적으로 취소/교환/환불을 클레임이라고 칭하는데요.
무신사에서는 지금 이 순간에도 다양한 종류의 클레임이 접수되고 있습니다. 이에 CX, 물류, 재무 등 다양한 부서와 협업을 하게 되는데요. 이로 인해 클레임 도메인 PM은 정책에 대한 이해, 원활한 소통 능력, 다각도의 문제 해결력이 필요합니다.
저는 무신사에서 약 3년 동안 주문, 결제, 클레임의 프로젝트를 진행해왔는데요. 이 과정에서 커머스 서비스, 특히 클레임에 대한 이해가 깊고 넓어지는 경험을 하였습니다. 오늘 이 글을 통해서, 클레임, 그 중에서도 환불을 중심으로 커머스코어 PM으로서 문제를 발견하고 해결하는 과정을 공유하고자 합니다.
1. 클레임은 무엇이고 어떤 특성을 가지고 있는가?
클레임은 단순 변심, 상품불량 등 다양한 사유로 인해 거래 조건이 변경되고, 이를 조정하기 위한 일련의 과정을 의미합니다.
이커머스 도메인에서는 일반적으로 취소/교환/반품(환불) 서비스가 클레임 도메인에 포함되어있습니다. 저는 무신사에서 주문, 결제, 클레임 과제를 주로 진행했는데요. 제가 경험해 본 클레임 도메인은 다른 도메인 대비 복잡도가 높고, 운영 업무에 대한 이해가 필요하다는 특성이 있습니다.
클레임 도메인이 복잡한 데는 3가지 이유를 꼽을 수 있습니다.
첫번째는 클레임이 고객 경험의 최종 단계에 있기 때문입니다. 일반적으로 클레임 서비스는 상품 탐색 > 주문> 결제 > 배송 > 환불(교환)의 고객 여정중에 마지막에 위치합니다. 이는 환불 서비스가 상품, 주문, 세일, 배송, 결제, 정산, 파트너 등 다양한 서비스의 영향을 받는 것을 의미하며 클레임은 앞에서 처리되는 정책과 정보를 반영해야 합니다.
두 번째로, 클레임 문제의 해결은 단방향적인 처리가 아닌 고객, 플랫폼, 파트너 간의 양방향적인 처리를 요구하고, 이 때문에 클레임 프로세스에서 정보는 계속 변화하는 속성을 가지게 됩니다. 클레임은 변화하는 각 속성에 따른 상태가 필요하고 그로 인해 복잡도가 증가합니다.
세 번째로 클레임 업무는 온라인에서 끝나는 것이 아니라 오프라인 활동까지 이어지는 특성을 가지고 있습니다. CS, 배송(회수), 검수, 정산 등 내부 구성원과 파트너의 업무에 대한 이해가 필요하며 이를 온라인 서비스에 반영할 수 있어야 하죠.
이러한 세 가지 특성으로 인해 클레임 도메인은 복잡하며, 클레임을 담당하는 PM에게는 창의성보다는 정책에 대한 이해, 논리력이 요구됩니다.
2. 클레임 영역의 문제 : 환불 구조를 개선하다
무신사가 성장하면서 다양한 영역의 서비스들이 고도화되고 있습니다. 앞으로 다양한 주문/배송/할인/클레임 서비스들이 제공되겠죠. 예를 들어 새로운 결제 수단, 할인 정책, 티켓과 같은 새로운 상품군이 추가될 때마다 클레임은 대응해야 합니다.
환불 구조 개선은 장기적으로 무신사 서비스가 발전할 방향을 그려보고, 이를 준비하기 위해 진행한 과제였습니다. 그리고 예상한 것보다 많은 문제를 해결할 수 있는 작업이었습니다.
환불 금액은 어떤 특성을 가지는 정보일까요? 환불은 모든 구매 프로세스의 종료 후에 추가적으로 일어나는 것으로, 기본적으로 고객이 결제를 통해 입력한 정보를 토대로 처리됩니다. 지금 이 글을 읽는 분들도, 온라인 쇼핑을 하다 환불한 경험이 한 번쯤은 있으실 것입니다. 혹시 일정 금액 이상을 충족하면 할인해주는 쿠폰을 적용한 후에, 부분 환불을 해보신 경험이 있으신가요? 이럴 때 돌려받을 금액은 얼마가 되어야 할까요? 기존의 무신사의 환불 구조 개선을 통해 부분 환불과 관련된 문제를 해결한 사례를 공유합니다.
환불구조의 개선 전(As-is)과 개선 후(To-Be)를 비교해놓은 [그림1] 이미지를 통해 문제 발견 과정을 설명드릴게요.
이미지의 왼쪽은 기존 무신사 환불 금액 구조입니다. A, B, C 상품을 함께 구매할 경우, 주문 번호 하나에 결제 정보가 저장되며, 환불 또한 하나의 주문번호를 기준으로 처리됩니다. 이 구조에서 할인이 적용되는 경우, 주문 번호에 할인이 적용되므로, 할인은 전체 주문에 각 상품이 차지하는 비율만큼 할당되어 계산됩니다. 5,000원 짜리 상품을 2개 주문한 후 1,000원 할인을 받았다면, 각각 상품은 4,500원이 됩니다.
이러한 구조는 정해진 금액을 결제하고 환불해주는 기본적인 환불 서비스에서는 문제가 없습니다. 하지만 추후에 10만 원 이상 구매 시 5천 원 할인과 같은 장바구니 할인이 생기게 되면 어떻게 될까요? 구매 금액에 따라 할인이 적용/취소되어 재계산되는 서비스가 아닌 할인 금액이 상품별로 저장되고 저장된 금액을 제외한 금액을 환불하는 서비스를 제공하게 됩니다. 이러한 환불 서비스는 구매 금액 조건에 충족하지 않음에도 일부 금액을 할인 받거나, 구매금액 조건을 충족하더라도 할인을 일부만 받는 문제가 발생합니다.
3. 환불 구조 개선 전과 후
10만원 이상 구매 시 5천원 할인이 있는 상태에서 15만원을 결제하고 부분 환불하는 경우(각각 10,000원, 60,000원 부분 환불)를 예로, 개선 전과 후를 비교해서 설명해 보겠습니다.
1)환불 구조 개선 전 기존 로직(주문 기준 환불금액을 한 개만 관리)
기존의 상태에서는 부분 환불을 할 경우, 각 상품별로 쿠폰의 할인율이 적용되고 남은 금액이 환불됩니다.
a. 10,000원 상품을 부분 환불하는 경우
고객은 5,000원의 전체 할인 금액 중 상품별로 계산된 할인 금액인 333을 제외한 9,667원을 환불받게 됩니다. 즉 구매 금액 조건을 충족함에도 333원의 손해를 보게 됩니다.
환불금액 9,667원 =10,000원(주문금액) — 해당 상품의 쿠폰할인금액(333원)
333원은 전체 할인금액 5,000원을 전체금액에서 해당상품이 차지하는 비율만큼 나눠서 나온금액(5000/150000*10000)
b. 60,000원 상품을 부분 환불하는 경우
고객은 58,002원할인 받게 되며, 구매금액 조건을 미충족함에도 3,002원 할인을 받게됩니다.
- 환불금액 58,002원 = 60,000원(주문금액) — 해당 상품의 쿠폰 할인금액(1,998원)
- 1,998원은 전체 할인금액 5,000원을 전체금액에서 해당 상품이 차지하는 비율만큼 나눠서 나온 금액 (5000/150000*60000)
기존 환불구조는 주문번호 별 하나의 환불 금액만 관리하기 때문에 장바구니 할인 정책이 명확하지 않은 문제점이 있었습니다.
이를 해결하기 위해 상품단위 별 환불금액을 관리할 수 있도록 환불 구조를 개선했습니다. 다시 위의 [그림1]의 오른쪽 이미지를 통해 확인할 수 있듯이, 상품 A, B, C를 한번에 주문하더라도 환불금액과 잔액을 상품별로 관리하도록 변경하였고, 이러한 개선을 통해 부분환불에 대한 합리적인 정책의 서비스를 제공할 수 있게 되었습니다. 이해를 돕기 위해 이제는 개선된 구조에서 같은 시나리오로 부분환불이 일어나는 상황을 설명드리겠습니다.
2) 환불 구조 개선 후 재계산 로직(상품 단위로 환불금액 관리)
a. 10,000원 상품을 부분 환불 하는 경우
고객은 10,000원을 환불받게되고 구매금액 조건 할인은 적용됩니다.
- 상품 금액을 재계산 해서 상품 A에 할인금액 5,000원 적용
b. 환불금액 60,000원 상품을 부분환불하면 구매금액 충족시 할인(5,000원)은 미적용되고, 할인 받았던 5,000원을 제외하고 55,000원을 환불받게 됩니다.
- 금액조건이 깨짐으로 할인금액 제외하고 환불
장바구니 할인은 고객들에게 익숙한 할인이고, 비즈니스 환경에 따라 제공할 여지가 있는 서비스이기 때문에 미리 환불 구조를 개선할 필요가 있었습니다. 또한 클레임 서비스 내에서도 상품 단위로 환불 금액을 관리하지 않기 때문에 환불 서비스를 고도화 하는 데 어려움이 있었습니다. 예를 들어 검수 결과에 따른 자동 환불 금액 계산은 검수 결과에 따른 환불차감액을 상품 단위로 관리되어야 하며, 부분 수량 환불은 상품단위로 환불액과 환불 잔액을 관리해야 합니다. 예시의 서비스를 제공하고자 했지만 구조 한계로 서비스를 제공하는 데 어려움을 겪고 있기 때문에 팀 내에서는 무신사 클레임 서비스의 발전을 위해 필수적으로 진행해야 하는 과제로 인식하고 있었습니다.
4. 필요하지만 성과를 바로 확인할 수 없는 과제는 어떻게 추진하는가?
플랫폼 서비스에 대한 장기적인 관점과 팀 내부의 인식에서는 환불 구조 개선은 필수적인 과제였습니다. 다만 단기적인 관점에서는 환불 구조 개선은 투입되는 리소스에 비해 얻을 수 있는 성과가 부족했습니다. 임팩트 있는 서비스에 포함해서 구조 개선을 진행하는 것도 방안이었지만, 주어진 리소스가 한정적이기 때문에 과제의 범위는 가능한 한 축소되어야 할 필요가 있었기 때문입니다.
장기적으로는 큰 임팩트가 있지만 단일과제로는 임팩트가 부족한 환불 구조 개선을 진행하기 위해서는 내외부 관계자들에게 과제를 설명하고 설득하는 과정이 더 필요했습니다. 이를 위해서 클레임 서비스에 대한 로드맵을 세우고 앞으로 만들어갈 서비스와 이 서비스들을 만들기 위한 사전 작업을 정의하고 공유했습니다. 특히 실제 서비스를 운영하는 운영 부서에는 지속적으로 해당 과제의 필요성을 인지시키고 공유하여, 과제에 대해 같은 온도로 공감할 수 있도록 유도하였습니다.
사실 무엇보다 중요한 것은 진행하고자 하는 의지였습니다. 단기간의 성과를 담보할 수 없고 긴급하지 않은 과제이기 때문에 충분히 나중에 할 수 있는 과제의 특성상 미루고자 한다면 충분히 미룰 수 있습니다. 하지만 도메인 담당자들이 개선 필요성을 공감했으며, 다음 기회가 언제 생길지 모른다는 생각에 의지를 가지고 프로젝트를 진행하게 되었습니다. 따라서 촉박한 일정임에도 불구하고 과제를 진행하기로 했고 성공적으로 작업을 마칠 수 있었습니다.
5. 환불 구조 개선을 통해 얻은 것
환불 구조 개선을 통해 무신사 클레임 서비스는 구조적 한계로 기존에 시작하지 못한 과제들을 진행할 수 있게 되었고, 클레임 서비스가 다음 단계로 나아갈 수 있는 토대가 마련되었습니다.(Ex. 반품비 차감 환불, 검수 결과에 따른 환불액 자동 계산, 부분 수량 환불)
클레임 서비스뿐만 아니라 장바구니 할인 같은 타 도메인에서 제공하는 서비스도 대응이 가능해졌고, 내부적으로 문제의식을 가지고 있던 클레임 정책들도 개선할 수 있었습니다.
제가 생각하기에 가장 크게 얻은 것은 도메인의 관점에서 문제점과 개선점을 스스로 도출하고, 준비하였으며, 그를 통해 결과물을 낸 경험입니다. 이 경험이 중요한 이유는 이런 경험이 차곡차곡 쌓여 더 나은 조직이 되고, 더 나은 서비스가 될 것이라고 생각하기 때문입니다.
도메인 특성상 유관부서 요구사항만 진행해도 1년의 과제는 충분합니다. 하지만 그 요청사항만 진행하다 보면 눈앞의 문제들만 해결할 뿐 장기적으로 발전할 수 있는 준비를 하지 못하는 경우가 많습니다. 이번 환불 구조 개선은 그런 의미에서 도메인 구성원이 함께 문제를 이해하고 공감하여 결과물을 만들어낸 성공적인 케이스였습니다.
환불구조개선은 더 좋은 업무 방식과 서비스를 만드는데 있어 좋은 레퍼런스가 되었다고 생각하며, 앞으로도 이런 경험을 하나하나 쌓아 올려 더 좋은 서비스를 만들도록 하겠습니다.
We Are Hiring! 
무신사 커머스코어실에서 일하며, 무신사 서비스를 함께 개선하고 싶은 미래의 동료를 기다립니다. 여기에서 공고를 확인해주세요.
긴 글 읽어주셔서 감사합니다.
무신사 주문/클레임 PM의 환불서비스 개선 이야기 was originally published in MUSINSA tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

무신사 주문/클레임 PM의 환불서비스 개선 이야기

댓글