어떤 문제였나요?
웨딩홀의 남은 예식 시간대를 일정·인원·조건·가격과 함께 보여주고, 신청 이후의 운영까지 이어야 했습니다. 공급 정보를 입력하는 도구와 고객이 탐색하는 화면을 같은 제품 범위로 다뤘습니다.
어떻게 풀었나요?
01
시간대를 비교할 수 있는 상품 단위로
단순한 잔여 일정 안내에서 나아가 예식월·지역·인원·가격·혜택으로 비교하고 신청하도록 구성했습니다.
02
고객 접점과 운영을 함께 설계
목록·상세·신청 화면뿐 아니라 슬롯과 가격·혜택의 등록·수정, 신청 관리까지 한 범위로 연결했습니다.
03
후속 운영에서 발견한 반복 작업 보완
초기 구현 이후 일괄등록과 중복 방지 기능을 보완해 공급 정보를 반복 입력하는 상황을 다뤘습니다.
고객 웹
조건 탐색 → 시간대별 가격·혜택 확인 → 신청
API · 운영 도구
슬롯 등록·수정·일괄등록, 신청 확인과 후속 운영 연결
무엇이 남았나요?
고객 웹·신청 API·슬롯 운영 도구를 구축했고, 후속 데이터 확인에서 실제 신청과 사용 근거를 확보했습니다.
- 532
- 신청 기록
- 331
- 고유 계정
- 339
- 신청된 슬롯
반복 신청 포함
계정 기준 중복 제거
신청 기록 내 고유 슬롯
* 10월은 29일까지. 월별 변화에는 공급량·유입·시즌·가격·동시 혜택이 섞여 있습니다.
2026.05.01–10.29 생성·보존 기록, 2026.10.30 조회. 실고객·커플·계약 수와 구분합니다. 내부·테스트 이용은 완전히 식별되지 않았습니다.
역할과 결과를 구분합니다.
- 별도 행동 분석에서는 첫 상세 노출 후 7일 내 신청 추적을 229 / 10,707개 관측 식별자에서 확인했습니다(2.14%). 진입 2026.05.01–10.21, 관찰 10.28까지이며 DB 신청 집계와 단위·기간이 다릅니다.
- 신청의 실제 사용을 보여주는 근거입니다. 유효 방문·계약, 매출 기여나 슬롯 소진율 개선까지 의미하지 않습니다.
- 프로젝트 리드와 확인된 코드의 직접 구현을 담당했습니다. 공급자 계약·가격의 최종 승인과 다른 직군의 기여까지 단독 수행으로 표현하지 않습니다.