예약에서 결제까지,이탈 구간을 고칩니다.

오픈 일정이 밀리면서 약관 시행일, 딥링크, 스토어 심사 마감이 서로 어긋났습니다. 남은 일이 무엇인지도 사람마다 다르게 알고 있었습니다.

1. 전환 항목을 한 문서로 관리전환 항목 261건을 14개 묶음으로 나누고 결정과 리스크를 같은 문서에 실었습니다. 담당·상태·메모를 고치면 다른 사람 화면에도 바로 반영되게 했습니다.
2. 1차 범위를 세 가지로 축소웹 전환, 앱 게시, 측정 시작만 1차로 남기고 홈페이지 교체와 신규 상품은 2차로 넘겼습니다.
3. 출시 직전 이슈 점수화사내 채팅 745건에서 제보 65건을 추리고 거래액 영향, 심각도, 프론트엔드·백엔드 공수로 점수를 매겼습니다. 그 주 프론트엔드 요청 5.0일 가운데 가용 2.5일에 들어가는 것만 남겼습니다. 결제를 막는 이슈는 P2에서 P0로 올렸습니다.
4. 전사 검수일 제안검수 전담 한 명으로는 앱을 다 볼 수 없어 파트별로 기능을 익히는 날을 제안했고 14명이 참여했습니다. 미션 양은 개발팀이 고칠 수 있는 공수에 맞춰 정했습니다.
5. 되돌림 기준 사전 확정앱은 재심사가 필요해 당일에 되돌릴 수 없었습니다. 그래서 웹을 먼저 되돌리기로 하고, 되돌릴 조건 다섯 개를 미리 정했습니다.

방문자 대비 결제 비율과 웹 상세 조회 후 결제 비율이 함께 올랐고, 검색으로 들어와 결제한 건수도 하루 평균 두 배 넘게 늘었습니다.

GA4를 쓰지 않는 원장 기준으로도 같은 기간 결제 건이 1,608건에서 2,287건으로 늘었습니다(대회 제외, 이후 취소 포함). 출시 달인 9월 순거래액은 8월의 2.1배였습니다. 9월은 성수기라 이 증가를 모두 출시 효과로 보지는 않습니다.

앱 품질도 함께 확인했습니다. Android 비정상 종료율은 0.17%에서 0.09%로 내려갔고, 앱 지도 이용률은 13.5%에서 23.3%로 올랐습니다.

웹 결제를 우선하면서 같은 기간 앱 가입은 42% 줄었습니다. 이 문제는 2차 범위로 분리해 따로 추적하고 있습니다.

어떤 배에서 어떤 어종을 얼마에 타는지 한 화면에서 볼 수 없으니 사용자는 단톡방과 전화로 돌아갔습니다. 수요는 있었지만 공급 정보가 한곳에 모여 있지 않았습니다.

1. 선장 입점 혜택 설계직접 모객하는 것보다 앱에 올리는 편이 낫도록 예약 알림, 정산 자동화, 조황 연계를 묶었습니다.
2. 옵션 단계 이탈 개선옵션 단계의 이탈이 가장 컸습니다. 어종·인원·승선일이 가격에 어떻게 반영되는지 한 화면에 보여 줬습니다.
3. 공급자(선주) 앱 기획선주가 상품 등록, 일괄 수정, 예약 명단, 정산을 직접 다루는 앱 48화면을 기획했습니다. 배포 전 검수에서 출시를 막을 결함 2건(잔여석 고정값으로 생기는 초과 예약, 주말·소인 요금 미계산)을 찾았습니다.
4. 거래액 증가 요인 분리순거래액을 결제가 생긴 배, 배 한 척당 결제, 건당 결제액으로 나눠 봤습니다. 이후 목표도 이 식으로 세워 필요한 선박 수를 먼저 계산합니다.

2월에 연 도메인의 순거래액은 10월 11일까지 11.9억입니다. 출시 달인 9월은 3.39억으로 8월의 2.1배였습니다.

3월부터 8월까지 결제가 생긴 배는 102척에서 160척으로 늘었지만, 배 한 척당 결제는 5.4건에서 4.6건으로 줄었습니다. 배를 늘리는 것만으로는 거래가 따라오지 않는다고 보고, 제품 쪽 목표를 배 한 척당 결제로 잡았습니다. 9월에는 이 값이 8.8건이었습니다(성수기 포함).

리포트마다 취소를 반영하는 방식이 달라 같은 달 거래액이 여러 값으로 나왔습니다. 먼저 거래액 정의를 "그달 결제일 기준 신청에서 그달에 생긴 모든 취소를 뺀 값"으로 고정했습니다.

같은 정의로 다시 보니 건당 결제액은 15만~18만원대로 거의 그대로였고, 차이는 대부분 취소에서 나왔습니다. 3월부터 9월까지 달마다 결제 신청의 42~50%가 취소됐고, 취소 금액의 절반 이상이 결제한 날 바로 생겼습니다.

1. 원인 세 가지 분리공급자 쪽 초과 예약, 결제 직후 취소, 회원의 날짜·선박 변경은 대응 방법이 다릅니다. 섞어서 보면 원인별 대책을 세울 수 없어 따로 다뤘습니다.
2. 공급자 원인: 재고 대조 재가동초과 예약으로 생긴 취소가 한 달 사이 3.9배로 늘었습니다. 외부 예약 채널과 우리 재고를 자동으로 대조하는 작업을 다시 가동하기로 했습니다.
3. 회원 원인: 재예약 모듈 설계취소 완료 화면에 "같은 날짜 다른 선박"과 "같은 선박 다른 날짜"를 보여 주는 재예약 모듈을 설계했습니다. 추천 달력은 모든 날짜를 열고, 자리가 없는 날을 고르면 가까운 다른 선박을 보여 줍니다.
4. 부분취소 정책인원만 줄이는 부분환불은 2명 이상, 최소 1명 남김, 증원 불가로 정하고, 쿠폰 조건 재판정과 차액 환불, 정산 재계산까지 정책으로 고정했습니다.
5. 주지표 변경취소율 대신 14일 유효 재결제율을 주지표로 봅니다. 취소한 회원이 다시 결제하도록 만드는 것이 목표입니다.

첫 기획서는 쿠폰 방식, 다운로드 쿠폰, 영수증 인증을 모두 새로 만드는 것으로 잡혀 있었습니다. 그대로면 전담 인원 다섯 명 이상이 필요한 양이었습니다.

1. 이미 기획된 화면을 다시 확인"정률에 상한이 붙은 쿠폰"과 "다운로드형 쿠폰"은 이미 화면에 있었습니다. 실제로 새로 만들 기능은 대상 선박 목록 하나였습니다.
2. 영수증 기능은 구글폼으로 대체영수증 스캔 기능 대신 이미지 첨부가 되는 구글폼으로 받았습니다. 그 때문에 생기는 운영 제약 네 가지(구글 로그인 필요, 선착순 마감 불가, 중복 제출 표시, 자동 승인 금지)는 운영 규칙에 적었습니다.
3. 3단계 순차 오픈이벤트 안내 한 장을 먼저 열고, 쿠폰 발급과 페이백을 뒤에 붙이는 일정으로 다시 짰습니다.
4. 버튼 상태 8가지비로그인, 발급 처리 중 잠금, 소진, 종료, 통신 실패 시 수량을 깎지 않는 것까지 버튼 상태를 하나씩 정의했습니다.

쿠폰 사용이 열린 9월 30일부터 10월 11일까지 쿠폰 507장이 발급됐고, 그중 45장이 결제에 쓰였습니다. 이 45건은 아직 한 건도 취소되지 않았습니다.

결제한 회원 가운데 9명은 이 쿠폰으로 처음 결제했습니다. 결제가 일어난 배는 34척입니다. 발급 대비 사용 비율이 낮아 발급한 회원에게 사용 기한을 알리는 알림을 다음 과제로 두었습니다.

예약 건수는 네 가지, 취소율은 세 가지 정의가 함께 쓰이고 있었습니다. 대행사가 제시한 획득 단가는 자사 데이터로 다시 계산하면 5.2배 차이가 났고, 매체가 보고하는 전환과 실제 결제 건수도 달랐습니다.

1. 지표 정의 먼저 고정정의가 갈리는 지표 여섯 개의 채택값과 제외 조건을 문서로 정하고, 원천 데이터와 전부 대조한 뒤에 대시보드를 만들었습니다.
2. 매체 판정 규칙매체별 성과를 GA4 기준 광고비 대비 매출(ROAS) 하나로 보고, 매체 → 캠페인 → 광고그룹 → 소재 순으로 판정하는 규칙을 만들어 축소 결정 세 건을 냈습니다. 검색광고는 브랜드 키워드를 빼면 ROAS가 376%에서 222%로 내려갔습니다. 이미 우리 이름을 검색해 들어온 결제가 성과에 섞여 있었다는 뜻이라, 최소 운영으로 바꿨습니다.
3. 재결제 분석을 제품 제안으로 연결재결제 간격은 회차가 쌓일수록 20일 → 14일 → 8일로 짧아졌습니다. 그래서 재예약 알림 시점을 첫 결제 뒤 6~20일로 제안했습니다. 앞뒤 결제에 모두 쿠폰을 쓴 비율은 51% → 63% → 73%여서, 쿠폰을 줄인다면 첫 재결제 쿠폰부터 검토하자고 제안했습니다.
4. 공급 단계별 이탈 확인8월 기준 앱에 노출 중인 배 911척 중 상품까지 올린 배는 436척으로 절반에 못 미쳤습니다. 공급 쪽 목표도 "입점 등록"보다 "상품 등록" 기준으로 세우자고 제안했습니다.

청구와 지급이 전부 수작업이라 매달 6명이 매달렸고, 종이와 엑셀로 처리한 돈은 데이터로 남지 않았습니다. 전체 범위를 한 번에 만들면 1년이 걸리는 규모였습니다.

1. 청구·지급만 먼저 개발이 영역만 떼어 2주 주기로 운영팀과 검증하고, 맞는지 확인한 뒤에 나머지를 붙였습니다.
2. 한 화면에서 처리실수령, 청구 자동 생성, 지급 결재, 정산을 한 화면에 놓았습니다. 청구·지급 처리는 100% 시스템에 기록되도록 바꿨습니다.
3. 청구서 공통 양식 합의부서마다 다르던 청구서를 같은 표로 묶고 부서별 고유 항목은 접어 두었습니다. 이 합의가 시스템을 만드는 일보다 어려웠습니다.

청구·지급에 매달 들어가던 인원이 6인에서 3인으로 줄었고, 남은 3인은 감원 없이 영업·재고 업무로 옮겼습니다. 청구·지급 데이터는 전부 시스템으로 옮겨졌고, 다음 단계인 공급망 시스템의 범위와 순서도 이 결과를 보고 정했습니다.