Planning · PM/서비스 기획

테넌트 온보딩 설계, 가입부터 첫 예약까지의 길

예약 시스템을 기획하면서 한동안은 예약을 하는 고객의 화면만 열심히 그렸던 것 같아요.그런데 고객이 예약할 수 있으려면 그 전에 업장이 먼저 서비스에 들어와서 준비를 마쳐야 합니다.이 준비 과정을 온보딩이라고 부르는데, 테넌트 구조의 서비스에서는 이 길이 생각보다 훨씬 중요하더라고요.업장이 가입만 해 놓고 아무 설정도 못 한 채 떠나면, 그 테넌트에게는 예약이 영원히 생기지 않기 때문입니다.오늘은 업장이 가입해서 첫 예약을 받기까지의 길을 어떻게 설계하면 좋을지 정리해 보려고 합니다.아래 예시는 모두 설명을 위해 가정한 것이고, 실제 수치나 사례가 아닙니다. 온보딩 설계의 첫 단계는 목적지를 정하는 일이라고 생각해요.저는 목적지를 "가입 완료"가 아니라 "첫 예약이 실제로 들어온 순간"으로 잡았습니다.가..

예약 시스템의 정산과 환불 정책, 테넌트에게 돈이 흐르는 길

예약 서비스를 기획하다 보면 결제 화면까지는 금방 그려집니다.그런데 그 돈이 그 뒤에 어디로 가는지 묻는 순간부터는 이야기가 갑자기 어려워집니다.플랫폼이 받는 돈은 얼마이고, 업장은 언제 얼마를 받는지, 고객이 취소하면 누구 몫에서 빠지는지를 정해야 하거든요.테넌트 구조의 예약 시스템에서는 이 질문이 더 무거워요.업장마다 취소 규정이 다르고, 정산을 받고 싶은 주기도 다르기 때문입니다.세금, 법률, 결제대행사(PG)의 세부 규정은 제가 단정할 수 있는 영역이 아니라서, 그런 부분은 "확인 필요"로 따로 표시해두었습니다.본문의 금액과 비율은 모두 설명을 위한 가정 예시이고, 실제 서비스의 수치가 아닙니다. 가장 단순하게 그리면 돈은 고객의 결제, 플랫폼의 수수료 차감, 테넌트로의 정산이라는 세 정류장을 지..

예약 데이터에서 놓치기 쉬운 것, 시간대·중복 예약·동시성

예약 시스템 기획서를 쓰다 보면 정상 흐름은 꽤 매끈하게 정리됩니다.고객이 시간을 고르고, 예약이 생성되고, 알림이 나가고, 방문하면 끝나는 흐름이에요.그런데 개발자와 이야기를 하다 보면 "그럼 두 명이 동시에 같은 시간을 누르면요?" 같은 질문이 나오고, 그제야 기획서에 비어 있던 부분이 보이곤 합니다.이 글은 제가 예약 데이터를 기획하면서 놓치기 쉽다고 느낀 세 가지인 동시성, 시간대, 이력 보관을 정리한 기록입니다. 가장 먼저 만나는 문제가 동시성입니다.가정 예시를 들어볼게요.미용실 디자이너 한 분의 오후 3시 슬롯이 하나 남아 있습니다.고객 A와 B가 거의 같은 순간에 이 슬롯을 보고 예약 버튼을 누릅니다.두 사람 모두 화면에서는 "예약 가능"으로 보였기 때문에, 시스템이 아무 장치 없이 둘 다 ..

예약 알림 설계, 알림톡·문자·푸시 선택 기준

예약 시스템을 기획하면서 처음에는 알림을 "나중에 붙이는 부가 기능" 정도로 생각했습니다.그런데 예약 흐름을 한 줄로 그려보니, 알림이 빠지면 흐름이 이어지지 않는 지점이 생각보다 많더라고요.예약이 잘 됐는지 고객이 믿을 수 있는 것도, 노쇼가 줄어드는 것도, 운영하시는 분이 새 예약을 놓치지 않는 것도 결국 알림이 맡는 일이었습니다.이번 글에서는 알림을 언제, 어떤 채널로, 어떤 문구로 보낼지 정리하면서 세운 기준을 기록해봅니다. 채널을 고르기 전에 "언제 알려야 하는가"부터 적는 게 순서가 맞다고 느꼈습니다.채널은 나중에 바꿀 수 있지만, 시점이 빠져 있으면 서비스 경험에 구멍이 나기 때문이에요.예약 한 건의 생애주기를 따라가며 적어보면 대략 이런 목록이 나옵니다.예약 완료 직후에는 "예약이 접수되었..

권한 모델 기획, 테넌트 관리자·직원·고객의 역할 나누기

예약 시스템에는 생각보다 다양한 종류의 사람이 들어옵니다.업장을 운영하는 사장님, 현장에서 일하는 직원, 예약하는 고객, 그리고 서비스 전체를 관리하는 플랫폼 운영자까지요.이들이 한 시스템을 같이 쓰기 때문에 "누가 무엇을 볼 수 있고, 무엇을 바꿀 수 있는가"를 정리하는 권한 모델이 꼭 필요해집니다.기획 초반에는 "사장님은 다 되고 직원은 일부만 되고"처럼 감으로 정리하기 쉬운데, 막상 화면과 데이터를 하나씩 따져보면 이야기가 복잡해져요.이번 글은 권한 모델을 기획하면서 제가 정리해 본 순서를 기록한 것입니다. 권한을 사람마다 하나하나 부여하면 관리가 금방 무너집니다.그래서 많은 서비스가 쓰는 방식이 역할 기반 접근 제어, 줄여서 RBAC예요.사람에게 직접 권한을 주는 대신 "역할"을 만들고, 역할에 ..

예약 노쇼를 줄이는 정책 설계, 보증금·리마인드·취소 규정

예약 서비스를 기획하면서 운영하시는 분들 이야기를 들어보면, 거의 빠지지 않고 나오는 하소연이 노쇼입니다.예약해 놓고 아무 연락 없이 오지 않는 고객 때문에 빈 시간이 생기고, 그 시간은 되돌릴 수 없으니까요.예약 시스템이 단순히 "예약을 받는 도구"를 넘어서려면, 이 문제를 어떻게 줄여줄 수 있는지가 중요한 기능이라는 생각이 들었어요.이번 글은 노쇼를 줄이기 위한 정책 선택지를 정리하고, 고객 경험과 어떻게 균형을 잡을지 고민한 내용입니다.숫자는 모두 설명을 위한 가정입니다. 노쇼의 비용은 "그 시간의 매출이 사라진다"에서 끝나지 않는다고 느꼈어요.가상의 예를 들어볼게요.커트와 염색을 하는 작은 미용실에서 염색 예약 한 건이 노쇼가 났다고 해보겠습니다.염색은 두세 시간짜리라서, 그 시간 동안 직원은 대..

예약 가능 시간 계산 로직 기획하기, 영업시간·휴무·버퍼타임

예약 서비스에서 고객이 가장 먼저 보는 화면은 "오늘 몇 시에 예약할 수 있나요?"에 대한 시간 목록입니다.화면만 보면 버튼 몇 개가 나열된 단순한 UI인데, 그 버튼이 어떻게 만들어지는지 따져보면 꽤 많은 규칙이 숨어 있어요.예약 시스템 기획을 하면서 이 부분을 정리하다 보니, 기획서에서 가장 자주 수정되는 곳이 바로 여기였습니다.그래서 이번 글에서는 예약 가능 시간을 계산할 때 어떤 입력 값이 필요하고, 어떤 예외가 생기는지 제가 정리한 순서대로 적어보려고 합니다. 예약 가능 시간을 계산할 때 저는 "열려 있는 시간을 찾는다"보다 "닫혀 있는 시간을 하나씩 빼나간다"로 생각하는 쪽이 편했어요.하루 24시간에서 시작해서, 영업하지 않는 시간, 쉬는 시간, 이미 예약된 시간, 휴무일을 차례로 지워나가면 ..

예약 시스템의 핵심 도메인 모델, 업장, 서비스, 자원, 슬롯

예약 시스템은 겉으로 보면 "날짜와 시간을 고르는 화면"이지만, 그 뒤에는 몇 가지 개념이 서로 연결된 구조가 있습니다.이 연결을 처음부터 제대로 잡아두지 않으면, 나중에 요구사항이 하나 추가될 때마다 구조 전체를 흔들게 돼요.오늘은 제가 정리한 핵심 도메인 모델을 미용실 예시로 줄글로 풀어보려고 합니다.엔티티 관계도를 그릴 수도 있지만, 먼저 말로 설명할 수 있는지 확인하는 편이 이해가 빨랐어요. 가상의 미용실을 하나 떠올려볼게요.이름은 그냥 "A 미용실"이라고 하고, 디자이너 두 분과 샴푸실 하나가 있다고 합니다.메뉴는 커트, 염색, 펌 세 가지예요.손님이 앱에서 "토요일 오후 2시 커트"를 예약하려고 합니다.이 한 문장 안에 개념이 줄줄이 들어 있어요.미용실이라는 장소, 커트라는 메뉴, 담당 디자이..