예약/티켓 주문서, 분리할까 합칠까
PM의 프로덕트 런칭 회고
들어가면서
올해 초부터 준비한 카페24 예약서비스를 런칭했습니다. 예약서비스는 숙박, 티켓처럼 배송이 필요 없고 시간의 흐름에 따라 재고가 소멸하는 상품으로 이해하면 됩니다. 이런 예약서비스에서 장바구니, 주문서, 주문완료와 관련된 영역을 맡아서 진행했습니다.
초기 제품이라 기능 자체가 지나치게 신박하다거나, 혹은 머신러닝 같은 하드테크 기술을 접목한 높은 난이도의 작업은 아니었습니다. 그럼에도 이전과 달라진 조직에서 첫 프로덕트를 런칭하면서 느낀 점, 특히나 기획에서의 고민이나 저의 실수에 대해 회고할 가치가 있다 생각하고 글을 적어보겠습니다.
예약 서비스를
시작하게 된 배경
네이버 서비스 거래액으로 알 수 있는 시장의 잠재성모두가 아는 것처럼 코로나 이후, 이커머스의 성장세는 둔화되었습니다. 그 성장세보다 높은 쿠팡의 성장세를 볼 때, 다른 기업들은 제한된 파이 안에서 수익성과 성장성을 높이기 위한 고민이 필요해졌습니다. 그런 가운데 눈에 띄는 지표가 있었으니, 바로 서비스 관련 영역입니다. 네이버가 분기마다 발표하는 실적을 보면, 여행/예약을 통한 서비스 거래액은 상품 거래액보다 2배 높은 성장성을 보여주고 있습니다.
커머스도 예약 서비스가 필요하다더 나아가, 고객 경험을 위해 오프라인 경험을 활용하는 기업들도 증가하고 있습니다. 예를 들어, 스포츠 의류/용품을 판매하는 기업이 스포츠 행사를 주최하는 일이나, 기업이 팝업스토어나 오프라인 경험공간을 제공하는 것들을 심심치 않게 찾아볼 수 있습니다. 혹은 공연 등 예약 서비스를 제공하는 곳에서 굿즈를 판매하는 등의 사례도 있습니다.
그렇다 보니 꼭 숙박 업체 사장님이 아니더라도, 기존 이커머스 고객들에게 제공할 수 있는 기회가 많아진다고 생각했습니다. 사이트를 따로 개설하지 않을 수 있다면 트래픽을 한 곳으로 모아줄 수 있을 것이며, 온오프라인 데이터의 통합을 더 용이하게 지원한다면 그것만으로도 의미 있는 변화를 만들 수 있습니다. 이런 배경에서 예약서비스 앱을 준비하게 되었습니다.
예약 서비스 주문,
주문서를 분리했어야 했나
프로덕트 기획을 시작할 때, 초기 버전의 서비스 제공 범위를 협의했습니다. 우선 제품 단위 팀끼리 협의가 필요했습니다. 예를 들면, 상품팀이 예약 서비스로 새롭게 추가하는 필드(ex. 예약서비스 이용일, 이용기간, 예약 특화 옵션 등)가 있다면, 해당 내용을 잘 받아와야 합니다. 주문생성에서 잘 받아야 취소/교환/반품을 담당하는 주문관리에서 이를 잘 처리할 수 있기 때문입니다.
Source : 카페24이번 초기 버전에서는 이용일 지정 상품, 숙박상품, 사용자 옵션형 상품으로 분리했다. 똑같은 예약상품이라 생각할 수 있지만, 각 상품은 차이가 존재한다. 재고를 어떻게 처리할지, 사용 여부와 환불 규정을 어떻게 설정할지와 관련해서 차이를 가집니다. 예를 들면, 숙박형 상품으로 등록된 4/27 상품은 4/27이 지나면 판매를 할 수 없도록 변경됩니다. 반면 에버랜드 이용권과 같은 사용자 옵션형 상품은 특정 기간 내에 이용하면 되는 상품이라 그런 점에서 차이가 존재합니다.
Source : 자체 제작다음으로 작업범위 최소화에 대한 고민을 했습니다. 프로덕트 매니저는 한정된 자원으로 가장 효과적인 결과를 내야 합니다. 이번 초기 버전에서 가장 고민했던 지점은 주문서를 어떻게 제공할 것인가였습니다.
이전 아티클에서 다룬 것처럼, 여행/예약서비스 중 장바구니를 따로 제공하지 않는 케이스(예약상품 단독 주문)도 다수 존재합니다. 제작 단계를 겪으면서 느낀 점은 예약 서비스를 제공하는 업체에서 일반 상품을 함께 판매하는 케이스가 많을지도 의문이지만, 그것보다 서비스의 안정적인 제작을 위해서는 분리하는 것이 훨씬 낫기 때문입니다.
https://brunch.co.kr/@kkmd/130
예약 서비스가 추가될 경우, 제공하는 필드값은 정말 다양(=복잡)해집니다. 기존에 제작되는 주문서 역시, 다양한 할인, 배송, 결제 관련 요소가 포함된 복잡한 프로덕트이기 때문에 여기에 다른 변수가 추가되는 상황은 조금 더 프로덕트 운영에 대한 리스크는 높아질 수밖에 없습니다. 실제 QA를 진행하면서, 고려하지 못했던 1+N 사은품, 지역별 배송비 등 커머스와 연관된 요소가 예약 주문 생성단계에서 이슈로 작용했습니다.
그럼에도 제작은 예약서비스 상품과 일반 상품을 함께 주문하는 것이 가능하도록 제공했습니다. 의사결정에서 가장 중요한 근거가 된 것은 자사의 '업'이었습니다. 온라인에서 사업을 하는 사람들에게 편의성을 제공하는 것이 중요하기에 최대한 자율성을 높여주는 것이 중요했습니다. 그래서 예약서비스 상품만 주문이 진행될 때와 예약서비스 상품과 일반상품이 함께 주문될 때, 각각에 대해 다른 사양의 주문서가 나타나도록 분기처리해서 제공했습니다.
예를 들면, 숙박상품만 주문할 경우 배송지 정보나 배송비 항목 등은 적용되지 않고, 상품 수령자의 필드 텍스트를 '방문자'로 변경해서 제공합니다. 또한 예약서비스가 포함될 경우, 상품에 등록된 환불규정 등 약관을 제공하는 등 예약 상품 판매에 필요한 기본적인 요소를 모두 제공하게 되었습니다.
끝으로
이번 프로젝트를 통해 기획 단계와 제작 단계에서 가져야 할 PM의 태도에 대한 부분입니다. 기획 단계에서는 컨셉은 간결하고, 작업 범위는 최소화하는 것이 필요합니다. 작업에 대한 Why와 업무의 방향성이 명확해야 다른 구성원의 참여 수준을 더 높일 수 있습니다.
하지만 제작 단계는 조금 다른 것 같습니다. 해당 프로덕트에 영향을 미칠 수 있는 요소들을 최대한 꼼꼼하게 살펴보는 것이 필요합니다. 특히 저희처럼 역사가 오래된 프로덕트일수록 각각의 기능이 미치는 사양을 꼼꼼히 파악하고, 발생가능한 이슈를 최소화하기 위해 고민해야 합니다.
남은 2분기는 상반기 내내 준비하는 프로덕트와 관련한 준비를 진행할 예정입니다. 이 시기동안 예약서비스와 관련하여 축적된 데이터와 로그를 토대로, 다음에는 조금 더 의미 있는 문제를 해결할 수 있도록 시도해봐야 할 것 같습니다. :)
