두 개의 비즈니스 종류가 이 예약 시스템을 함께 씁니다. service와 clinic입니다. 같은 코드가 돌아갑니다 — 서비스, 예약, 담당자 배정, 패키지 — 그리고 clinic 종류는 인터페이스의 이름표를 예약·환자·치료 코스로 바꿉니다. 치과와 네일숍은 같은 예약 문제를 다른 단어로 갖고 있기 때문입니다. 종류를 고르는 것은 어휘를 바꿀 뿐 구조를 바꾸지 않습니다. 의원용 제품을 따로 만들었다면 두 번의 릴리스 안에 서비스 쪽과 어긋났을 것입니다.
서비스는 가게가 정하는 시간과 가격입니다
카탈로그는 서비스의 목록이고, 각각 소요 시간과 가격을 갖습니다. 소요 시간은 장식이 아닙니다. 90분짜리 시술과 15분짜리 커트는 같은 하루의 서로 다른 크기를 차지하기 때문에, 그것이 있어야 예약표가 의미를 갖습니다. 손님은 가게의 공개 페이지에서 서비스를 골라 예약합니다. 그 페이지 구획은 서비스 모듈이 직접 기여하는 것이고, 다른 모듈과 같은 공용 UI 키트로 만들어져서 덧붙인 위젯이 아니라 앱의 일부처럼 보입니다.
예약, 그리고 가게가 직접 누르는 확정
예약 요청은 이름, 전화번호, 날짜, 시간, 메모를 갖고 대기 상태로 도착하며 가게가 확인합니다. 대기 건수는 콘솔 대시보드의 실시간 배지 중 하나로, 진행 중 주문·직원을 호출한 테이블·대기 중 휴가와 나란히 몇 초마다 갱신됩니다. 여러 모듈을 함께 쓰는 가게라면 사람의 손을 기다리는 모든 것이 한 곳에서 세어집니다.
확인 단계는 절차를 위한 절차가 아닙니다. 달력에 자리만 있으면 자동으로 받아들이는 예약 시스템은, 담당 기술자가 출근하지 않는 날의 예약을 받고, 10시가 일찍 끝나야만 성립하는 11시를 받습니다. 수락을 사람의 행위로 두면 가게가 아는 것이 흐름에 남고, 손님은 조용히 옮겨질 자리 대신 확실한 답을 받습니다.
예약마다 담당 직원을 배정할 수 있습니다. 그 필드 하나가 예약 목록을 실제 근무 일정으로 바꿉니다. 이건 누가 하는가에 답하고, 다시 온 손님을 같은 사람에게 되돌려 줄 수 있게 하며, 고객 이력에 반영되어 단골이 누구를 보고 오는지 가게가 알게 합니다.
패키지와 선불 코스: N일 동안 N회
선불 거래는 보통의 판매가 아니라 자기 모델을 갖습니다. 패키지는 N일 동안 유효한 N회 코스이거나, N일 동안 유효한 멤버십입니다. 손님이 사서 한 회씩 차감하고, 「내 패키지」 탭에서 무엇을 갖고 있고 몇 회가 남았는지 봅니다. 남은 횟수는 지갑 속 도장 카드가 아니라, 그것을 소모하는 예약과 같은 백엔드에 놓인 기록입니다.
패키지 구매는 리뷰 자격 뷰의 조건 중 하나이기도 해서, 코스를 산 손님은 첫 회차를 쓰기 전에도 그 가게에 리뷰를 쓸 수 있습니다.
SMS 알림이 없습니다. SMS 자체가 없기 때문입니다. 전화번호 인증과 SMS 발송은 만들어져 있지 않고, 엔드포인트가 501로 그렇게 답합니다. 알림은 앱 안에서 손님에게 도착하고, 이메일은 확인된 주소로만 나갑니다.
clinic 종류는 이름표를 바꾸는 것이지 의무기록 시스템이 아닙니다. 예약을 환자와 치료 코스로 바꿔 부를 뿐, 진료 기록이나 처방 등 EMR에 있어야 할 것은 저장하지 않으며 그렇게 만들어지지도 않았습니다.
그 둘레에 주인이 받는 것: 리포트, 고객 관리, 인사
서비스나 의원 비즈니스는 예약·서비스·패키지 세 개의 모듈 타일에, 모든 비즈니스 종류가 받는 것을 더해 받습니다. 리포트는 매출, 주문 수, 객단가, 현금·PromptPay·기타 비중, 판매 상위 다섯 개, 7일 매출 그래프, 오늘·7일·30일·전체 기간을 덮고 영수증 재출력과 공유용 영수증 문구를 만듭니다. 다만 세금계산서는 발행할 수 없습니다 — 부가세 등록 사업자만 발행할 수 있는데, 이 시스템은 아직 어느 가게의 등록도 기록하고 있지 않기 때문입니다. 서비스 가게에서 상위 다섯 개 목록은 실제로 돈이 되는 시술이 무엇인지로 읽히는데, 대개 포스터에 붙은 그것이 아닙니다.
CRM은 판매 원장에서 고객 명단을 만들어 메모와 태그, 구매 이력, 가게가 자체 화폐 기준으로 정한 비율의 적립 포인트, 그리고 직접 정한 최소 결제액과 보상을 붙입니다. HR은 직원 쪽을 다룹니다. GPS와 메모가 붙는 출퇴근, 휴가 신청, 근무표와 급여 — 근무 분, 하루 8시간 초과분, 시급 또는 월급 — 공지와 배정 가능한 업무. 급여는 범위가 나뉘어 있어 일반 멤버는 자기 급여만 보고 소유자와 매니저가 전체를 봅니다.
접근은 권한 행렬 위에서 돕니다. 13개의 핵심 권한에 설치된 모듈이 선언하는 권한, 소유자·매니저·홀·주방·직원 프리셋, 그리고 사람별 예외. 권한이 없으면 타일이 사라지고, 아직 아무 권한도 없는 멤버는 버그처럼 보이는 빈 목록 대신 정확히 그렇게 적힌 화면을 봅니다. 안드로이드 앱에서 이 검사는 클라이언트에서 돌고, 같은 행렬이 데이터베이스에 has_capability(business_id, capability)로 존재하며 행 수준 보안 정책을 위해 서버에서 펼쳐집니다.
밑에 깔린 모듈 시스템과 설치할 수 있는 확장
서비스는 Food, Stay, Retail과 함께 네 개의 핵심 모듈 중 하나입니다. 비즈니스 종류가 곧 모듈입니다. 모듈은 id, 자기가 맡는 비즈니스 종류, 라벨, 카탈로그 제목, 기본 CTA, 카탈로그 뷰를 선언하고, 선택적으로 권한, 콘솔 타일, 콘솔 화면, 손님용 페이지 구획을 선언합니다. 설치된 모듈이 선언한 권한만으로 권한 편집기를 자동으로 만들 수 있는 것은 이 계약 덕분입니다.
그 위에는 비즈니스 종류를 가리지 않는 일곱 개의 설치형 애드온이 콘솔의 플러그인 스토어에 있습니다. 팀 권한, 결제 채널, 멤버십·구독, 갱신 알림, 프로젝트·업무, 자재·생산, 자동화. 멤버십과 갱신 알림은 서비스 업종과 자연스럽게 맞습니다. 손님이 가게 페이지에서 사는 플랜과, 만료 전의 알림. 삭제는 데이터가 지워지지 않는다고 분명히 적은 확인 창 뒤에 있고, 삭제된 애드온은 타일도 권한도 손님용 구획도 기여하지 않습니다. 서드파티 플러그인은 아직 열려 있지 않고, 스토어가 스스로 그렇게 적고 있습니다. 오늘 존재하는 것은 자체 제작 애드온이 붙은 모듈형 구조이며, 외부 제출을 여는 것이 다음 단계입니다.
예약이 끝난 뒤의 리뷰
서비스 이용은 리뷰 자격 뷰에 들어 있는 조건 중 하나이므로 실제로 받은 손님만 리뷰를 쓸 수 있고, 나머지에게는 왜 버튼이 없는지 설명하는 잠금 카드가 보입니다. 별점은 데이터베이스 트리거가 리뷰 행에서 다시 계산하지 누가 입력하지 않습니다. 리뷰에는 사진, 5→1 분포 요약, 최신 리뷰의 수정과 삭제, 재방문 시 예전 것을 남긴 채 새로 쓰기, 그리고 주인의 공개 답글이 있습니다.
그날 와서 시간을 정하지 않는 손님에게는 줄서기가 더 맞습니다. QR로 번호표를 뽑고 지금 몇 번째인지가 보이므로, 시간대를 먼저 고를 필요가 없습니다.
배정된 담당자가 오늘 출근인지 휴가인지는 내 직장의 같은 근무표에서 옵니다. 이 뒷단을 처음 여는 이야기는 비즈니스 페이지입니다.