동네 필라테스 예약 앱미리보기
동네 스튜디오 수업을 고르고 잔여 횟수로 자리를 잡는다.
동네 필라테스 예약 앱
PRD
문제
- 회원은 걸어서 갈 수 있는 동네 스튜디오의 리포머 잔여석을 한곳에서 보기 어렵고, 빈 시간을 확인하기 어렵다.
- 그룹·개인 수업을 각각 다른 채널에서 잡아 당일 취소와 노쇼가 생긴다.
- 횟수권·기간권 차감이 예약과 따로 놀아 회원이 다음 수업을 스스로 잡기 어렵다.
- 가정: 초기 범위는 한 동네 스튜디오 5곳이다.
목표
- 회원이 5곳의 리포머 잔여석을 한 화면에서 보고 그룹 또는 개인 수업을 직접 예약한다.
- 예약 확정 시 횟수권 또는 기간권을 차감하고, 취소·노쇼 시 차감 규칙을 같은 기록에 남긴다.
- 수업 전 리마인드로 당일 취소와 노쇼를 줄여 공석이 줄어드는지 본다.
- 성공 판단은 공석 수(개설 좌석 대비 미예약·노쇼)와 회원이 직접 잡은 다음 수업 예약 건수로 측정한다. 목표 수치는 확정 필요.
출시 범위
- 포함: 동네 5곳 스튜디오의 실시간 잔여석 조회, 그룹·개인 예약, 횟수권·기간권 차감, 예약 변경·취소, 리마인드 알림, 회원 가입·로그인, 스튜디오 운영자의 일정·예약·이용권·회원 처리.
- 포함: 리포머 수업만. 다른 기구 수업은 확정 필요하며 이번 출시에서는 다루지 않는다.
- 제외: 복잡한 정산, 카드 결제·환불 대금 흐름, 스튜디오 간 수익 배분.
- 제외: 범위 밖·다음 단계로 마케팅 캠페인, 후기·배너 운영, 다지역 확장을 둔다.
역할과 권한
- 회원(수강생): 본인 계정으로 잔여석 조회, 그룹·개인 예약, 본인 횟수권·기간권 확인, 본인 예약 취소, 리마인드 수신 여부 설정.
- 스튜디오 운영자: 자기 스튜디오의 수업 일정·정원·잔여석, 예약 목록·상세·출석/노쇼/취소 처리, 소속 회원의 이용권 지급·차감 정정, 자기 스튜디오 회원 목록만 처리한다.
- 가정: 플랫폼 운영자 계정·권한 관리와 스튜디오 간 통합 정산 화면은 이번 출시에 두지 않는다. 스튜디오 5곳 등록은 배포 시 운영 데이터로 넣는다.
- 회원은 다른 회원의 예약과 이용권을 볼 수 없다. 운영자는 다른 스튜디오 데이터를 볼 수 없다.
사용자 시나리오
- 회원은 로그인 후 걸어서 갈 수 있는 스튜디오의 리포머 잔여석을 보고, 그룹 또는 개인 수업을 고른 뒤 보유 이용권으로 예약한다.
- 잔여석이 없으면 예약은 거절되고, 확정되면 횟수권은 1회 차감되거나 기간권은 이용 기간 안에서만 확정된다.
- 회원은 수업 전 리마인드를 받고, 허용된 시점까지 취소할 수 있다. 운영자는 예약 상세에서 출석, 당일 취소, 노쇼를 기록한다.
- 운영자는 하루 일정을 열어 정원과 잔여석을 맞추고, 잘못 차감된 이용권만 자기 스튜디오 안에서 정정한다.
핵심 기능
- 실시간 잔여석: 스튜디오·날짜·그룹/개인 구분으로 리포머 남은 자리를 보여 주고, 예약·취소 시 같은 좌석 수를 즉시 반영한다.
- 예약: 회원 1명이 빈 자리에 그룹 또는 개인 수업 1건을 잡는다. 개인 수업은 정원 1명으로 둔다.
- 이용권 차감: 횟수권은 확정 시 1회 차감, 기간권은 유효 기간 안의 예약만 허용한다. 취소 가능 시점의 복원 여부는 가정이며 스튜디오별 규칙으로 확정 필요하다.
- 리마인드: 예약 1건당 수업 전 알림 1회를 보낸다. 발송 시각은 확정 필요.
기술 스택과 아키텍처
- 권장안: 회원·운영자 모두 모바일 웹 한 벌. 서버는 예약·이용권·알림을 처리하는 API와 관계형 데이터베이스로 구성한다.
- 잔여석 차감과 이용권 차감은 한 예약 확정 transaction에서 처리해 동시 예약의 초과 확정을 막는다.
- 리마인드는 예약 시각 기준으로 발송 대기열에 넣고, 발송 성공·실패만 기록한다.
- 스튜디오 5곳의 일정은 운영자가 직접 등록한다. 외부 예약 채널 동기화는 범위 밖이다.
전체 IA와 화면 흐름
- 회원: 로그인/가입 → 동네 스튜디오 잔여석 목록 → 수업 상세(그룹·개인, 잔여석) → 이용권 선택 → 예약 확정 → 내 예약 목록·상세(취소) → 내 이용권. 알림 수신 설정은 내 정보 안에 둔다.
- 운영자 짝: 잔여석 목록의 짝은 수업 일정 목록·등록·수정. 예약 확정·내 예약의 짝은 예약 목록·상세·출석/취소/노쇼 처리. 이용권 화면의 짝은 이용권 지급·잔여 횟수·기간 수정. 가입·로그인의 짝은 자기 스튜디오 회원 목록·상세.
- 공지·FAQ·이벤트·배너·후기 화면은 없다. 해당 콘텐츠의 관리자 화면 없음. 이유: 이번 출시는 정보형 콘텐츠를 올리지 않고 예약·이용권·알림만 다룬다.
- 결제 화면과 주문·결제 관리 화면 없음. 이유: 결제는 하지 않고 이미 가진 횟수권·기간권만 차감한다. 복잡한 정산 화면 없음.
데이터 모델
- 회원: 계정 식별자, 이름, 연락 채널, 알림 수신 여부. 스튜디오 소속은 이용권 보유로 연결한다.
- 스튜디오·수업: 스튜디오 5곳, 수업 일시, 그룹/개인, 정원, 잔여석, 리포머 여부. 잔여석은 확정 예약 수로 계산한다.
- 예약: 회원, 수업, 상태(확정·취소·출석·노쇼), 사용한 이용권, 취소 시각.
- 이용권: 종류(횟수·기간), 남은 횟수 또는 시작·종료일, 지급 스튜디오, 차감·복원 이력.
API와 외부 연동
- 회원 API: 잔여석 조회, 예약 생성, 예약 취소, 내 예약·내 이용권 조회, 알림 수신 변경.
- 운영자 API: 자기 스튜디오 수업 등록·수정, 예약 상태 변경, 이용권 지급·정정, 소속 회원 조회.
- 외부 연동은 리마인드 발송 채널 하나. 가정: 앱 푸시 또는 문자 중 하나로 확정 필요. 결제대행·정산 연동은 제외.
- 연동 실패 시 예약 확정은 유지하고 알림만 실패로 남긴다. 발송 재시도 횟수는 확정 필요.
UI·UX 요구사항
- 잔여석 목록은 스튜디오, 시간, 그룹/개인, 남은 자리를 한 줄에 보여 준다. 0석이면 예약 버튼을 막는다.
- 예약 전에 차감될 이용권(횟수 1회 또는 기간권 유효)을 보여 주고, 확정 결과를 같은 화면에 남긴다.
- 운영자 예약 상세는 출석·당일 취소·노쇼를 한 동작으로 기록하고, 이용권 복원 여부를 함께 보여 준다.
- 회원·운영자 화면은 모바일 세로 폭에서 목록과 상세가 이어지게 한다. 데스크톱 전용 레이아웃은 범위 밖이다.
보안과 개인정보
- 가입 시 예약·이용권·리마인드에 필요한 최소 항목과 수집 동의를 받는다. 마케팅 수신은 서비스 알림과 분리하고 수신거부할 수 있다.
- 연락처와 예약 이력은 회원 본인과 해당 스튜디오 운영자만 조회한다. 보관 기간과 탈퇴 시 파기 시점은 확정 필요.
- 운영자 계정은 자기 스튜디오 데이터만 수정한다. 이용권 정정은 누가 언제 바꿨는지 남긴다.
- 비밀번호 또는 동등한 로그인 비밀은 저장 시 보호하고, 알림 채널에는 예약에 필요한 최소 정보만 담는다.
비기능 요구사항
- 같은 좌석에 대한 동시 예약은 정원 초과 확정이 한 건도 생기지 않아야 한다.
- 잔여석 목록은 예약·취소 반영 후 회원이 다시 열었을 때 바뀐 좌석 수를 보여 준다. 허용 지연 시간은 확정 필요.
- 리마인드 실패는 예약 상태와 분리해 재발송할 수 있어야 한다.
- 품질 지표는 예약 확정 실패 건수, 정원 초과 건수, 알림 실패 건수, 공석 수, 회원 직접 예약 건수로 센다. 목표 수치는 확정 필요.
구현 계획
- 1단계: 회원 가입·로그인, 스튜디오 5곳, 수업·잔여석, 그룹·개인 예약과 취소.
- 2단계: 횟수권·기간권 지급과 예약 시 차감, 취소 시 복원 규칙, 차감 이력.
- 3단계: 운영자의 예약 처리(출석·당일 취소·노쇼)와 회원·이용권 관리 화면.
- 4단계: 리마인드 발송과 실패 기록. 정산·결제는 구현하지 않는다.
수용 기준과 QA
- 잔여석이 1인 수업에 두 회원이 동시에 예약하면 한 명만 확정되고 이용권도 그 예약에만 차감된다.
- 횟수권 0회 또는 기간 밖 기간권으로는 예약이 확정되지 않는다. 규칙상 복원되는 취소는 횟수를 되돌린다.
- 운영자는 다른 스튜디오 예약·회원·이용권을 열 수 없다. 회원은 본인 예약만 취소할 수 있다.
- 리마인드가 실패해도 예약은 확정 상태로 남고, 운영자 예약 상세에 실패가 보인다. 결제·정산 화면은 없어야 한다.
배포와 운영
- 배포 단위는 회원 웹, 운영자 웹, API, 알림 발송이다. 스튜디오 5곳과 운영자 계정은 배포 후 초기 데이터로 등록한다.
- 운영 확인 항목은 예약 실패, 정원 초과, 알림 실패, 이용권 정정 이력이다. 정산 배치는 두지 않는다.
- 장애 시 예약 생성만 막고 이미 확정된 예약·이용권 조회는 유지하는 것을 가정으로 둔다. 세부 복구 절차는 확정 필요.
- 취소 가능 시점, 노쇼 시 횟수 복원 여부, 리마인드 채널과 발송 시각은 출시 전에 스튜디오와 확정한다.