주고객과 최우선 제품 가치 미정

문서는 손님, 사장님, 아르바이트생을 사용자로 제시하고, 대기 시간·수수료·주문 실수·단골 관리라는 서로 다른 문제를 함께 다뤄요. 그러나 누구를 먼저 확보할지와 어느 문제를 최우선으로 풀지는 미정이라고 밝혀요. 예를 들어 출근길 손님은 빠른 픽업을 원하고, 사장님은 비용과 주문 실수 감소를 따질 수 있어요. 우선순위가 정해지지 않으면 제품 약속과 기능 범위가 여러 방향으로 갈라져요.

핵심 고객 한 집단과 그 집단의 가장 중요한 문제를 먼저 정리해요. 대기 시간, 주문 실수, 수수료 부담 중 무엇을 우선하는지 근거와 함께 선택하고, 나머지는 후속 가치나 보류 범위로 구분해요.

결정 근거 완결성

과금 방식과 전환 판정 기준 공백

월 구독, 주문 수수료, 손님 멤버십 세 가지 안이 나열돼 있지만 선택 근거는 없고, 초기 무료 제공 뒤에 결정한다고 적혀 있어요. 예를 들어 10개 매장에서 주문이 발생해도 사장님이 어떤 비용 구조를 받아들일지 확인할 기준이 없으면 무료 운영의 성과를 유료 수요로 해석하기 어려워요. 이는 경쟁 구간과 핵심 고객을 정한 뒤 검증할 사업 판단으로 남아 있어요.

고객과 우선 가치, 공략 구간을 먼저 정한 뒤 과금 후보별로 지불 주체·가격 가설·검증 기준을 비교해요. 무료 제공은 유료 전환이나 반복 사용에 대한 어떤 가설을 확인하는 기간인지 함께 정리해요.

비즈니스

결제 완료와 주문 전달 복구 단절

문서에는 사장님이 주문을 접수하지 않을 때 자동 취소 시점이 미정이고, 서버 장애로 주문이 화면에 나타나지 않아도 대응 절차가 없다고 적혀 있어요. 출근 시간에 손님이 결제했지만 매장에는 주문이 도착하지 않는 상황에서 음료 제공이나 환불을 안내할 기준이 없어 손님 신뢰와 매장 운영이 함께 흔들릴 수 있어요.

주문 생성부터 매장 접수, 취소, 환불, 장애 복구까지 상태와 담당 주체를 정하고, 결제 내역과 매장 주문 내역을 대조하는 처리 기준을 마련해요.

전환 + 연결 상태

알레르기 정보 검증 책임 미정

메뉴별 알레르기 정보를 사장님이 직접 입력한다고 되어 있지만, 잘못 입력했을 때 책임이 누구에게 있는지 모른다고 명시돼요. 알레르기가 있는 손님이 주문 전에 이 정보를 믿고 음료를 고르는 순간, 정보 검증과 정정 절차가 없으면 건강 피해와 신뢰 손상으로 이어질 수 있어요.

정보 입력·검토 책임, 손님에게 제공할 주의 안내, 변경 이력과 정정 절차를 정리하고 출시 전 관련 표시·책임 요건을 확인해요.

법적

직원별 환불 권한과 기록 부재

사장님 계정을 아르바이트생과 함께 쓰고 환불 버튼은 누구나 누를 수 있다고 되어 있어요. 바쁜 시간에 잘못된 환불이나 권한 오남용이 생기면 누가 처리했는지 확인하기 어려워 정산과 분쟁 대응의 신뢰가 낮아질 수 있어요.

사장님·매니저·직원별 계정과 권한을 나누고, 환불 승인 범위 및 처리 기록을 정해요.

운영

주문 뒤 연락처 보관·삭제 미정

픽업 알림용 전화번호를 저장한다고 되어 있지만 보관 기간과 삭제 요청 처리는 정하지 않았어요. 손님이 주문을 마친 뒤에도 연락처가 남는다면 정보 이용 범위와 삭제 방법을 알기 어려워 개인정보에 대한 신뢰가 떨어질 수 있어요.

전화번호의 이용 목적, 보관 종료 시점, 삭제 요청 접수·처리 방법을 정의하고 실제 저장·삭제 흐름과 맞춰요.

법적

주문 재입력이 매장 편의 약화

서비스 개요는 사장님이 주문을 한 화면에서 받는다고 설명하지만, 대부분의 카페가 POS에 픽업온 주문을 다시 입력해야 하고 연동은 2단계 검토라고 적혀 있어요. 이미 POS로 주문을 관리하는 매장은 주문을 옮겨 적는 시간이 생겨 바쁜 시간의 실수 감소라는 가치가 약해질 수 있어요.

초기 대상 매장의 POS 사용 흐름을 확인하고, 1단계에서 수기 재입력을 감당할 수 있는 조건과 연동 전 임시 처리 방식을 정리해요.

가치 전달

손님 반복 사용 가치 측정 공백

성공 지표는 가입 매장 수와 월 주문 수로 제시됐지만, 손님 재주문율은 측정 방법을 정하지 않았어요. 출시 후 주문이 늘어도 같은 손님이 계속 가치를 얻는지 확인할 수 없어 서비스의 지속 사용 가능성을 판단하기 어려워져요.

핵심 고객과 제품 약속을 좁힌 뒤, 해당 약속이 실제로 전달되는지 보여주는 재주문 지표와 관찰 기간·집계 기준을 정해요.

품질 퇴화

피크 주문량의 허용 성능 기준 부재

문서는 오전 8~9시에 주문이 몰릴 수 있다고 짚지만 성능 기준을 두지 않았어요. 출근 시간에 주문이 늘어난 순간 화면 지연이나 접수 누락이 생기면, 가장 중요한 이용 시간대에 주문 경험이 흔들릴 수 있어요.

초기 매장 수와 예상 동시 주문량을 기준으로 응답 시간·주문 누락 허용 기준을 정하고, 출시 전 부하 확인과 장애 감지 방법을 마련해요.

의존성 + 인프라 건전성

추천 실패 시 일반 주문 대안 부재

문서에는 날씨·시간대·주문 이력으로 메뉴를 추천한다고 되어 있지만, 틀린 추천이나 품절 추천을 받았을 때의 처리 방법은 정해지지 않았어요. 예를 들어 출근길 손님이 품절 음료를 추천받으면 주문을 진행할 수 있는지, 다른 메뉴를 안내받는지 알기 어려워 추천 기능에 대한 신뢰가 떨어질 수 있어요. 추천은 2단계 계획이므로 출시 범위와 실패 시 대체 동작을 함께 정리하면 돼요.

추천 대상의 판매 가능 여부를 확인하는 기준과, 품절·추천 불가 시 추천을 숨기거나 다른 메뉴를 안내하는 대체 동작을 문서에 정리해요.

모델 행동

AI 호출 비용 상한과 초과 동작 미정

기술 구성에는 외부 LLM API를 사용한다고 적혀 있지만 비용 상한은 정하지 않았고, AI 추천은 2단계에 포함돼 있어요. 예를 들어 여러 매장에서 아침 시간대 추천 요청이 늘면 호출 비용이 예상보다 커질 수 있어요. 가격 모델이 아직 선택되지 않은 것과는 별개로, 기능 운영에 필요한 비용 한도와 초과 시 동작을 마련할 필요가 있어요.

추천 요청량이나 월 비용의 허용 상한을 정하고, 한도에 가까워지거나 초과했을 때 추천 빈도를 줄이거나 기능을 임시 중단하는 기준을 정리해요.

비즈니스

혜택 조건 변경과 기존 적립 분리

문서에는 10잔 적립 후 1잔 무료, 매장별 적립이라고 적혀 있지만 사장님이 조건을 바꿀 때 이미 쌓인 스탬프를 어떻게 처리할지는 미정이에요. 예를 들어 손님이 9잔을 적립한 뒤 매장이 적립 조건을 바꾸면 기존 혜택이 유지되는지 알 수 없어 불만이나 매장 문의로 이어질 수 있어요. 조건 변경의 적용 시점과 기존 적립분의 처리를 분리해 정하면 돼요.

스탬프 조건 변경이 신규 적립분에만 적용되는지, 기존 적립분에도 적용되는지와 변경 전 손님에게 알리는 방법을 정리해요.

전환 + 연결 상태

매장 등록에서 첫 주문까지 준비 경로 누락

손님이 매장을 고르고 메뉴를 주문하려면 매장이 먼저 등록되고, 메뉴와 가격 및 주문 가능 상태가 준비돼 있어야 해요. 문서는 손님 주문 흐름과 사장님 주문 화면, 첫 단계의 카페 10곳을 제시하지만 매장이 이 상태에 도달하는 절차는 설명하지 않아요. 따라서 초기 매장 운영자가 실제로 손님 주문을 받을 수 있는 시점이 불분명해져요. 기존 주문 흐름은 유지하면서 매장 등록부터 첫 주문 수신까지의 준비 단계를 정리하면 이 연결을 확인할 수 있어요.

매장 등록, 메뉴·가격 입력, 주문 접수 설정, 고객 화면 공개, 첫 주문 확인까지의 준비 흐름과 각 단계의 담당자를 정리해요.

일반

영업 종료 후 주문 차단과 안내 기준 부재

손님이 매장을 선택하고 결제하는 흐름은 제시돼 있지만, 매장 영업시간이나 주문 접수 가능 여부를 언제 확인하는지는 정해지지 않았어요. 영업 종료 후에도 주문 경로가 열리는 경우 손님은 지금 받을 수 없는 주문을 진행한다고 오해할 수 있어요. 영업시간과 주문 접수 상태를 매장 선택 및 결제 전에 확인하는 기준을 정하고, 영업 종료 시 표시할 안내와 다음 주문 가능 시점을 설계하면 이 경계가 명확해져요.

매장별 영업시간과 임시 주문 중지 상태를 정의하고, 주문 가능 여부 확인 시점과 영업 종료 시 손님에게 보여줄 안내를 정리해요.

엣지

다점포 주문 확인의 계정 전환 부담

문서는 여러 매장을 가진 사장님이 매장별 계정을 따로 만든다고 적고, 여러 매장 지원은 후속 단계로 미뤄요. 매장이 늘어난 사장님이 매번 계정을 바꿔 주문을 확인해야 한다면 주문 누락 가능성과 운영 부담이 함께 커져요. 개인 카페의 운영을 더 쉽게 하려는 가치가 확장 과정에서 약해질 수 있어요.

다점포 사장님이 한 계정에서 매장별 주문을 확인하고 전환할 수 있는지 정리해요. 매장별 권한·알림·주문 구분은 확장 전에 간단한 운영 흐름으로 확인해 두면 좋아요.

규모

푸시 실패 뒤 주문 확인 대체 경로 부재

기술 구성에는 푸시 알림으로 FCM을 사용한다고 적혀 있지만, 알림 전달이 실패했을 때 매장이 주문을 확인하는 대체 경로는 설명되지 않아요. 손님은 결제를 마쳤는데 매장 화면에서 주문을 발견하지 못하면, 이미 확인된 결제 후 주문 누락 문제와는 별도로 알림 전달 실패만으로도 제조가 늦어질 수 있어요.

푸시 알림만으로 주문 발견을 보장하지 않도록, 매장 화면의 주문 갱신·미확인 주문 표시·필요 시 재알림 등 대체 경로를 정리해요. 알림 전달 여부와 주문 확인 여부도 구분해 확인할 수 있게 해요.

실패

시장 수치의 조사 근거와 최신성 미확인

문서에는 출근 시간 대기 줄이 10분 이상이고 배달앱 수수료가 15~20%라고 적혀 있지만, 대상 매장·조사 시점·출처는 제시되지 않아요. 이 수치가 현재 고객의 실제 상황과 다르면 대기 시간 단축이나 수수료 부담을 제품 가치의 근거로 삼는 판단이 빗나갈 수 있어요. 경쟁 구도 누락과는 별개로, 제시된 문제 근거 자체가 지금도 유효한지 확인할 필요가 있어요.

초기 대상 지역과 매장을 기준으로 대기 시간과 실제 부담 수수료를 확인하고, 각 수치에 출처와 확인 날짜를 기록해요. 검증 결과에 따라 우선 문제와 제품 약속이 여전히 맞는지 다시 살펴봐요.

시간적 유효성

추천 선택을 뒷받침할 설명 단서 부재

출근길 손님이 처음 방문한 카페에서 추천 메뉴를 보더라도, 문서는 추천 이유를 보여주지 않기로 해요. 추천이 자신의 취향이나 상황에 맞는지 판단할 단서가 없으면 손님은 추천을 무시하거나 주문 선택을 망설일 수 있어요. 기존에 확인된 추천 오류·품절 대응과는 다른 문제로, 추천 근거를 짧게 설명할지와 설명이 어려울 때 일반 메뉴 선택으로 자연스럽게 이어질지를 정리하면 좋아요.

추천에 사용한 손님 친화적 이유를 한 줄로 제시할지 검토하고, 설명 근거가 충분하지 않을 때 추천을 선택 사항으로 두는 흐름을 설계해요.

모델 행동

주문 상태별 취소·환불 안내 불명확

손님이 미리 결제한 뒤 매장이 음료 준비를 시작하는 상황에서, 문서는 제조 중 전까지 취소할 수 있다고만 하고 우유를 데운 경우의 처리를 미정으로 남겨요. 주문 상태가 실제 준비 진행과 어긋나거나 환불 조건이 사전에 보이지 않으면 손님과 매장이 취소 가능 여부와 금액을 다르게 이해할 수 있어요. 장애로 결제가 됐지만 주문이 전달되지 않는 기존 문제와는 별개로, 정상 주문을 취소할 때 적용되는 조건과 손님 안내를 구체화해요.

주문 접수·준비 시작·완료 상태별 취소 가능 여부, 환불 기준, 손님에게 고지할 시점을 정리하고 실제 매장 준비 절차와 일치하는지 확인해요.

법적

픽업 시각의 약속 의미 불분명

문서에는 손님이 5분 단위로 픽업 희망 시간을 고른다고만 적혀 있고, 그 시각이 음료 준비 완료 시각인지 픽업 가능 구간인지 설명돼 있지 않아요. 출근길 손님이 8시 10분을 골랐는데 매장은 8시 10분부터 만들기 시작한다면, 손님은 약속된 시각에 음료를 받을 수 있다고 기대해 기다리게 돼요. 선택 시각의 의미와 화면 안내를 함께 정하면 기대와 실제 경험의 차이를 줄일 수 있어요.

픽업 시각이 준비 완료 예정 시각인지 수령 가능 시간대인지 정하고, 주문 전 확인 화면과 주문 상태에 같은 의미로 안내해요.

인지

주문 전달 이상을 사전에 감지할 신호 부재

문서에는 서버 장애로 주문이 매장 화면에 나타나지 않을 수 있다고 적혀 있지만, 운영자가 결제·주문 전달·매장 화면 표시가 정상인지 확인할 지표나 경보는 제시되지 않아요. 바쁜 시간에 주문 전달이 멈춰도 손님 문의가 들어오기 전까지 팀이 알아차리지 못할 수 있어요. 주문 단계별 성공 여부와 지연을 관찰하는 기준을 정하면 문제를 더 일찍 발견하고 원인을 좁힐 수 있어요.

결제 완료부터 매장 화면 표시까지 단계별 성공·실패·지연을 기록하고, 평소 범위를 벗어나면 담당자가 확인할 경보와 점검 화면을 정의해요.

관측

가입 수와 완료 주문 성과 정의 부족

성공 지표로 가입 매장 수와 월 주문 수를 제시하지만, 실제 운영을 시작한 매장과 가입만 한 매장을 어떻게 구분하는지, 취소·실패 주문을 주문 수에 포함하는지는 정해져 있지 않아요. 예를 들어 가입 매장은 늘어도 첫 주문을 받지 않은 매장이 대부분이면, 숫자만 보고 서비스가 매장에 정착했다고 판단할 수 있어요. 활성 매장과 성공적으로 완료된 주문의 정의를 정하면 지표가 제품 가치와 더 가까워져요.

활성 매장의 기준과 완료 주문의 집계 규칙을 정하고, 가입·첫 주문·완료 주문을 구분해 추적해요.

품질 퇴화

메뉴 옵션 가격과 제공 조건 미표시

설계에는 샷 추가와 우유 변경 같은 선택지가 있지만, 각각의 추가 금액이나 제공 가능 조건은 확인되지 않아요. 출근길 손님이 옵션을 고르고 결제한 뒤 예상보다 높은 금액을 보거나 매장에서 해당 변경을 제공할 수 없다고 안내받으면, 빠르고 믿을 수 있는 주문 경험이 흔들려요. 옵션별 가격·가능 조건을 메뉴 선택과 결제 요약에 연결하면 혼란을 줄일 수 있어요.

옵션별 추가 금액, 선택 가능 조합, 품절·제공 불가 시 처리 기준을 정하고 결제 직전 요약에 반영해요.

도메인

픽업 예약과 매장 처리 용량 미연결

손님은 5분 단위로 픽업 희망 시간을 고를 수 있지만, 시간대별 주문 한도나 제조 여력에 따라 선택지를 조정하는 기준은 제시되지 않았어요. 점심시간에 여러 손님이 같은 시간대를 선택하면 앱은 주문을 받더라도 매장은 그 약속을 맞추기 어려울 수 있어요. 픽업 시간 선택을 실제 처리 용량과 연결해야 대기 감소라는 가치가 지켜져요.

메뉴별 준비 시간과 시간대별 수용량을 정하고, 한도에 도달한 픽업 시간은 선택 불가 또는 대체 시간 안내로 처리해요.

미시 시간

파일럿 종료와 확장 판정 기준 부재

문서는 첫 단계에서 지역 카페 10곳으로 시작한 뒤 AI 추천·POS 연동과 전국 확장을 계획하지만, 파일럿에서 어떤 고객 가치나 운영 성과를 확인해야 다음 단계로 넘어가는지 정하지 않았어요. 예를 들어 주문 수가 늘어도 매장이 주문을 처리하기 어려워하거나 손님이 다시 이용하지 않으면, 다음 단계 투자가 핵심 가치가 검증됐다는 뜻이 되지 않아요. 파일럿 종료 시점에 확인할 신호와 확장·보류 기준을 정리하면 기능 투자와 시장 확대가 실제 가치 검증에 연결돼요.

10개 매장 파일럿이 검증할 핵심 가치를 먼저 정하고, 매장 활성화·주문 완료·손님 재이용·매장 업무 부담 등 관찰 신호와 단계별 확장 또는 보류 기준을 합의해요. 그 기준을 충족하기 전에는 AI 추천·POS 연동·전국 확장을 별도의 검증 가설로 다뤄요.

GTM-검증 정합

결제 사업자와 개발 검증 범위 미정

문서에는 카드·간편결제를 지원한다고 적혀 있지만 PG사가 미정이라 어떤 연동을 구현하고 검증할지 착수 기준이 부족해요. 예를 들어 개발자가 첫 결제 화면을 만들 때 사업자별 결제 방식과 테스트 환경을 확인할 근거가 없어 일정과 구현 범위가 달라질 수 있어요. 이는 주문 누락 복구나 취소·환불 기준 자체와는 별개인 구현 인수 공백이에요.

결제 사업자 선정 여부와 선택 기준, 지원할 결제 방식, 테스트·운영 환경, 연동 완료 기준을 한곳에 정리해요. 사업자 선정 전에는 해당 항목을 미확정 결정으로 표시하고 결제 구현 착수 조건과 연결해요.

핸드오프 수신

추천용 주문 정보 외부 전달 경계 미정

문서는 AI가 주문 이력을 바탕으로 메뉴를 추천하고 외부 LLM API를 사용한다고 적지만, 주문 이력 중 어떤 정보를 전달하는지, 외부 제공 사실을 손님에게 어떻게 알리는지, 최소한의 정보만 사용하는지 확인할 수 없어요. 예를 들어 손님이 자주 주문하는 음료를 바탕으로 추천을 받을 때, 그 주문 정보가 외부 사업자에게 전달되는지 알 수 없다면 서비스 이용에 대한 신뢰가 낮아질 수 있어요. 처리 범위와 고지·동의·보관 기준을 정리하면 추천 기능의 데이터 경계가 명확해져요.

추천에 실제 필요한 입력 항목과 외부 AI 사업자에게 전달되는 정보를 구분하고, 정보 최소화·고지·동의·보관 및 삭제 기준을 함께 정리해요.

법적

픽업 수령 확인과 완료 상태 연결 부족

문서는 주문 상태가 '픽업 대기'에서 '완료'로 바뀐다고 설명하지만, 매장에서 주문자나 주문 내용을 확인하고 전달을 완료하는 절차는 제시하지 않아요. 점심시간에 여러 주문이 동시에 준비되면 직원이 비슷한 음료를 다른 손님에게 건넬 수 있고, 완료 상태도 실제 수령 여부와 어긋날 수 있어요. 수령 확인의 최소 절차를 정하면 주문 상태와 매장 인계가 더 믿을 만해져요.

주문 번호·픽업 코드·화면 확인 등 매장 환경에 맞는 수령 확인 방식을 정하고, 누가 어떤 시점에 완료 상태로 바꾸는지도 함께 정의해요.

신뢰

일반 메뉴 판매 상태 갱신 책임 부재

문서는 손님이 매장을 고르고 메뉴와 옵션을 선택해 결제한다고 설명하지만, 매장이 메뉴를 등록·수정하거나 품절 메뉴를 판매 중지하는 흐름은 확인되지 않아요. 아침에 재료가 먼저 떨어진 메뉴가 앱에 계속 남아 있다면 손님은 결제 후 매장에서 주문을 처리할 수 없다는 안내를 받을 수 있어요. 메뉴 정보와 판매 가능 상태를 누가 언제 갱신하는지 정하면 일반 주문 흐름의 완결성이 높아져요. 이는 AI가 품절 메뉴를 추천하는 별도 문제와 달리 전체 메뉴 주문에 적용되는 관리 공백이에요.

메뉴·가격·옵션·판매 가능 상태의 관리 주체와 갱신 방법을 정하고, 품절 처리 전후 손님 화면과 이미 결제된 주문의 처리 기준을 연결해요.

도메인

고객 문의 담당과 부재 대체 경로 부재

설계 패키지는 고객센터를 창업자 개인 카카오톡으로 운영한다고 밝혀요. 손님이 출근길 주문 문제를 문의했을 때 창업자가 확인하지 못하면, 문의 접수와 후속 조치가 함께 멈출 수 있지만 대체 담당자나 인계 기준은 확인되지 않아요. 문의 책임과 부재 시 대체 경로를 정리하면 고객 지원이 한 사람의 가용성에만 의존하지 않게 돼요.

문의 유형별 담당자와 확인·응답 기준을 정하고, 창업자가 부재할 때 이어받을 담당자와 문의 기록 방식을 함께 마련해요.

운영

제조 역할과 주문 상태 변경 책임 불일치

문서에는 아르바이트생이 음료를 만든다고 적혀 있고 주문 상태는 접수부터 완료까지 제시돼요. 하지만 사장님이 접수한 뒤 누가 제조 중·픽업 대기·완료 상태로 바꾸는지는 구체화되지 않았어요. 예를 들어 바쁜 시간에 직원이 음료를 만들었어도 상태 변경 담당이 불명확하면 손님 화면의 안내가 실제 제조 진행과 어긋날 수 있어요. 역할별 상태 변경 책임과 완료 기준을 정리하면 매장 업무와 손님 안내가 더 일관돼요.

아르바이트생과 사장님이 주문을 접수·제조·픽업 대기·완료 단계에서 각각 맡는 행동을 정하고, 각 상태 변경의 담당자와 완료 기준을 주문 흐름에 연결해요.

일반

매장 운영 권한을 확인할 절차 부재

문서는 손님이 매장을 골라 결제하고 사장님이 주문을 받는 흐름을 설명하지만, 매장이 누구에 의해 등록되고 실제 운영 권한이 어떻게 확인되는지는 제시하지 않아요. 예를 들어 출근길 손님이 앱에서 동네 카페를 골라 결제했는데 매장 정보가 잘못 등록됐거나 운영 권한이 없는 계정에 연결돼 있다면, 주문을 처리할 주체를 믿기 어려워져요. 제공된 자료만으로 확인된 공백이며, 별도 매장 등록·검증 절차가 이미 존재한다면 판단은 달라질 수 있어요.

매장 등록 때 확인할 정보와 운영 권한을 검증하는 기준을 정리하고, 손님에게 표시할 매장 정보와 변경·분쟁 시 처리 담당자를 함께 연결해요.

신뢰