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

선상 예약은 전화와 단톡방에서 이뤄졌고, 어떤 배에서 어떤 어종을 얼마에 타는지 한 화면에서 볼 수 없었습니다. 우리 서비스도 예약·쇼핑·커뮤니티가 웹과 앱으로 나뉘어 있어 결제까지 가는 길이 서비스마다 달랐습니다.

통합 출시 일정이 밀리면서 약관 시행일, 딥링크, 스토어 심사 마감도 서로 어긋나 있었습니다.

1. 예약 도메인 신설공급은 자사 선박 대신 외부 선장 입점으로 채웠습니다. 선장이 직접 손님을 모으는 것보다 앱에 올리는 편이 낫도록 예약 알림, 정산 자동화, 조황 연계를 제공했습니다. 선주가 상품·명단·정산을 다루는 앱 48화면도 기획했습니다.
2. 거래액을 세 요소로 나눔순거래액을 결제가 생긴 배, 배 한 척당 결제, 건당 결제액으로 나눴습니다. 배를 늘리는 일은 영업이, 배 한 척당 결제를 늘리는 일은 제품이 맡도록 목표를 나눴습니다.
3. 출시 범위를 세 가지로 축소웹 전환, 앱 게시, 측정 시작만 1차로 남기고 홈페이지 교체와 신규 상품은 2차로 넘겼습니다. 전환 항목 261건은 14개 묶음으로 나눠 한 문서에서 관리했습니다.
4. 되돌림 기준 사전 확정앱은 재심사가 필요해 당일에 되돌릴 수 없었습니다. 그래서 웹을 먼저 되돌리기로 하고 조건 다섯 개를 미리 정했습니다. 검수는 파트별로 기능을 익히는 날로 바꿔 진행했습니다.

2월에 연 예약의 누적 순거래액은 11.9억입니다. 출시 달인 9월 순거래액은 3.39억이었고, 직전 달의 2.1배입니다.

출시 전후 같은 기간을 비교하면 결제 건은 1,608건에서 2,287건으로 늘었습니다. 같은 기간 방문자 대비 결제 비율은 1.31%에서 1.82%로 올랐습니다(GA4, 출시일 속성 변경으로 참고치).

9월은 성수기라 방문자도 늘었습니다(일평균 6,006명 → 7,628명). 이 증가분과 출시 효과는 따로 떼지 않았습니다.

3월부터 8월까지 결제가 생긴 배는 102척에서 160척으로 늘었습니다. 같은 기간 배 한 척당 결제는 5.4건에서 4.6건으로 줄었습니다. 그래서 제품 쪽 목표를 배 한 척당 결제로 잡았습니다. 9월에는 이 값이 8.8건이었습니다(성수기 포함).

나빠진 지표도 같이 봤습니다. 웹 결제를 우선하면서 같은 기간 앱 가입이 42% 줄었고, 이 문제는 4번 케이스의 백로그로 이어졌습니다.

예약 건수 정의가 네 가지, 취소율 정의가 세 가지 함께 쓰이고 있었습니다.

대행사가 제시한 획득 단가는 앱 안 행동 1건 기준이었습니다. 예약 1건 기준으로 원장에서 다시 계산하면 5.2배였습니다.

회의 자료에 기록된 8월 배 한 척당 결제는 7.9건이었지만, 원장으로 다시 세면 그 절반을 조금 넘는 수준이었습니다. 목표를 세운 숫자부터 맞지 않았습니다.

1. 정의 먼저 고정정의가 갈리는 지표 여섯 개의 채택값과 제외 조건을 정하고, 모든 카드에 정의와 출처를 같이 적었습니다. 거래액은 "결제일 기준 신청에서 그 기간에 생긴 취소를 뺀 값" 하나로 정했습니다.
2. 원천 데이터 연결어드민 결제 원장, GA4, 광고 대행사 시트와 매체 데이터, 선박 공급 현황을 연결했습니다. 이름과 전화번호는 불러올 때 버리고, 회원은 해시 키로만 셉니다.
3. 질문하면 답하는 입력창자연어 질문을 AI가 조회 조건으로 바꾸고, 계산은 브라우저가 원장으로 직접 합니다. 원장 원본은 밖으로 나가지 않고, 답한 숫자는 화면의 표와 대조할 수 있습니다.
4. 매체 판정 규칙매체 → 캠페인 → 광고그룹 → 소재 순으로 광고비 대비 매출을 판정하게 했습니다. 브랜드 키워드를 빼면 검색광고 ROAS가 376%에서 222%로 내려갔습니다.
5. 산식 오류 정정기여이익 산식이 선주에게 갈 몫까지 회사 매출로 세고 있던 것을 찾아 고쳤습니다.

매체를 같은 기준으로 다시 판정해 10월 광고 집행을 월 1,192만원 줄이기로 결정했습니다.

8월 노출 중인 배 911척 가운데 상품까지 올린 배는 436척이었습니다. 공급 목표를 입점 등록 대신 상품 등록을 기준으로 세우자고 제안했습니다.

재결제 간격은 회차가 쌓일수록 20일, 14일, 8일로 짧아졌습니다. 그래서 재예약 알림 시점을 첫 결제 뒤 6~20일로 제안했습니다.

회원이 직접 취소한 건의 35.7%가 24시간 안에 다시 결제한다는 것도 이 원장에서 찾았습니다. 이 발견이 3번 케이스로 이어졌습니다.

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

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

출시 직후 채팅방에 쌓인 메시지는 745건이었고, 제보와 단순 대화와 중복이 섞여 있었습니다. 그 주 프론트엔드에 들어온 요청은 5.0일 분량이었지만 가용은 2.5일이었습니다.

목록을 점수로 다시 세워 보니 기획팀이 그 주에 고르려던 항목 가운데 결제 구간을 다루는 것이 하나도 없었습니다.

1. 제보 자동 접수채팅을 매일 모아 "제보로 볼 말"과 "화면·기능 이야기"가 함께 있는 것만 남겼습니다. 745건이 65건이 됐고, 이슈와 개선을 나눠 기존 시트 형식 그대로 쌓았습니다.
2. 점수와 처리 구분앱 배포가 필요한 것, 이번 주 프론트엔드, 백엔드 병행, 다음 주로 처리 구분을 나눴습니다. 가용을 넘는 건을 숨기지 않고 적어야 무엇을 뺄지 고를 수 있어, 70점 이상인 건은 가용을 넘어도 넣고 근거에 표시했습니다.
3. 앱 가입 감소 대응: 재방문 기능웹 중심으로 출시하면서 앱 가입이 42% 줄었고, 웹으로 온 고객은 다시 들어올 길이 마땅치 않았습니다. 홈 화면에 두기, 알림 받기, 앱 받기를 서로 다른 자리로 나눠 기획했고(추정 공수 약 21MD) 서비스에 반영했습니다.
4. 결제 직전 이탈 대응: 주문서 단계 축소상품 선택에서 결제 시작으로 넘어가는 구간의 이탈이 가장 컸습니다. 주문서 단계를 줄이는 안을 개발 의견에 맞춰 공수를 줄인 안(프론트엔드 7.5 → 5.0MD)으로 바꿨고, 개발 순서를 기다리고 있습니다.

점수표는 평일 아침마다 다시 계산되도록 만들어, 그 주 개발 범위를 정할 때 씁니다.

홈 화면에 두기와 알림 받기의 재방문 효과는 아직 확인하지 못했습니다. 출시일에 GA4 속성이 바뀌어 이전 재방문율과 바로 비교할 수 없기 때문입니다. 반영일 전후를 새 속성 안에서 비교할 계획입니다.

주문서 단계 축소는 출시 후 출조 탭 진입 대비 결제 완료율과 결제 당일 취소율을 함께 볼 계획입니다.

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

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

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

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

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

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

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