Korat태국의 가게 대부분은 서로 말이 통하지 않는 세 개의 시스템을 돌리고 있습니다. 계산대의 POS, 배달 앱이 준 주문용 태블릿, 그리고 근무표가 오가는 단체 대화. 세 곳 모두에서 손님은 낯선 사람입니다. Korat이 존재하는 이유는 이것이 세 개의 문제가 아니기 때문입니다. 하나의 주문을 서로 다른 의자에서 본 것입니다.
가게를 여는 데 1분쯤 걸립니다
비즈니스를 만들고 이름과 주소와 전화번호를 넣고 종류를 고릅니다. 종류가 어떤 모듈이 올라올지 정합니다. 앉아서 통과해야 하는 설정 마법사도 없고, 첫 주문을 받기 전에 맞춰 두어야 할 것도 없습니다. 중요한 설정 — 영업시간, 배달, PromptPay, 분류 — 은 나중에 다시 와서 보면 되는 탭이기 때문입니다.
비즈니스 삭제는 일부러 두 번의 확인을 거칩니다. 이름과 주소, 전화번호, 설명을 고치는 것은 시트 하나이고, 변경은 즉시 공개 페이지에 반영됩니다.
식당: QR이 곧 보안 모델 전체입니다
직원이 테이블을 엽니다. 그 순간 그 한 번의 착석에만 속하는 토큰이 발급되고 QR이 그것을 싣습니다. 손님이 찍어 세션에 들어와 주문합니다. 테이블이 닫히면 토큰도 함께 죽습니다. 찍어 둔 QR이나 저 아래 친구에게 전달한 QR이 쓸모없는 이유가 이것입니다.
주문은 곧장 주방으로 가지 않습니다. 주방 화면의 확인 대기열에 들어가고 사람이 하나씩 확인하거나 거절합니다. 그 한 단계가 QR 메뉴판과, 바쁜 금요일에 켜 두고 맡길 수 있는 시스템 사이의 차이입니다. 영업시간에는 라스트오더 여유가 붙어서 앱이 테이블에 주방이 닫힌다고 알리고, 그다음에는 주문을 아예 받지 않습니다.
식당 모듈의 나머지는 평범한 일들입니다. 사진과 분류, 판매 여부, 재고, 가격 차이가 붙는 옵션 그룹, 세트가 있는 메뉴. 카운트다운과 잔반 요금이 있는 뷔페 패키지. 직원 연령 확인이 붙는 주류 게이트. 테이블 예약. 배달비와 예약 픽업 시각이 있는 배달. 그리고 라벨이 붙은 할인, 받은 금액과 거스름돈, 금액에 맞춘 PromptPay QR이 있는 결제.
리테일과 숙박과 의원도 같은 대접을 받습니다
- 리테일
- 카운터용 계산대, 대기 → 확인 → 포장 → 발송 → 완료의 다섯 단계 흐름이 있는 온라인 주문 콘솔, 송장 번호, 사유가 붙는 거절, 속성과 옵션 조합이 있는 상품, 그리고 부족 재고 경고가 있는 재고.
- 숙박
- 격자에서 체크인·체크아웃하는 객실, 사진과 1박 요금이 있는 객실 타입, 기간별 시즌·프로모션 요금 규칙, 예약 수신함, 룸서비스 요청, 그리고 보증금과 수도전기 검침, 생성 청구서가 있는 월세 임대.
- 서비스와 의원
- 소요 시간과 가격이 있는 서비스, 담당자가 배정되는 예약, 그리고 손님이 사서 한 회씩 쓰는 코스나 멤버십. 의원 종류는 인터페이스를 예약·환자·치료 코스로 바꿔 부릅니다.
리포트와 고객, 적립은 모든 종류에 딸려 옵니다
오늘·최근 7일·최근 30일·전체 기간의 매출과 주문 수와 객단가. 현금·PromptPay·기타의 결제 비중. 판매 상위 다섯 개와 7일 매출 막대 그래프. 어떤 영수증이든 다시 출력하거나 문구로 공유할 수 있습니다. 세금계산서는 발행할 수 없습니다: 태국 조세법전 86/13조는 부가세 등록 사업자에게만 발행을 허용하는데 이 시스템은 아직 어느 가게의 등록도 기록하지 않으므로, 모든 문서는 부가세 줄이 없는 평범한 영수증입니다.
고객 명단은 판매 원장에서 스스로 만들어집니다. 손님을 직접 입력하지 않습니다. 각 고객은 구매 이력과 가게가 쓴 메모와 태그, 가게가 자체 화폐 기준으로 정한 비율의 적립 포인트, 직접 정한 최소 결제액과 보상, 그리고 사용 버튼을 갖습니다. 배달 플랫폼이 구조적으로 줄 수 없는 부분이 이것입니다. 플랫폼이 손님을 갖고, 가게는 주문 하나를 받습니다.
직원: GPS 출퇴근, 초과근무, 그리고 누가 무엇을 볼 수 있는가
모든 업종이 같은 HR 모듈을 받습니다. 직원은 GPS와 선택적 메모를 붙여 출퇴근을 찍습니다. 휴가 신청은 콘솔에서 승인하거나 반려합니다. 근무표는 근무 분과 하루 8시간을 넘긴 초과근무가 되고, 시급이나 월급을 적용해 사람별 급여가 계산됩니다. 일반 직원은 자기 급여만 보고, 소유자와 매니저가 전원을 봅니다.
권한은 스위치가 아니라 행렬입니다. 13개의 핵심 권한에 설치된 모듈이 더하는 것, 소유자·매니저·홀·주방·일반 직원 프리셋, 그리고 그 위의 사람별 예외. 멤버가 쓸 수 없는 타일은 흐리게 표시되는 것이 아니라 거기 없습니다. 아직 아무 권한도 없는 멤버는 고장처럼 보이는 빈 콘솔 대신 「아직 권한이 없습니다」라는 평범한 화면을 봅니다.
어디서 강제되는지 분명히 해 둡니다. 앱에서 타일을 감추는 권한 검사는 기기에서 돕니다. 같은 권한 행렬이 데이터베이스에도 has_capability(business_id, capability)로 존재하고 행 수준 보안 정책이 그것을 씁니다. 그래서 역할 프리셋은 서버에서 펼쳐지고, 데이터베이스는 누가 매니저인지에 대한 앱의 주장을 믿지 않습니다. 콘솔의 모든 화면을 서버에서 완전히 강제하는 작업은 아직 진행 중입니다. 어디까지 왔는지는 보안 페이지에 정확히 적혀 있습니다.
공개 페이지도 제품의 일부입니다
모든 비즈니스는 페이지를 갖습니다. 커버와 로고, 갤러리, 지금 열려 있는지 닫혀 있는지가 보이는 영업시간, 주소, 전화번호, 길찾기, 팔로우 버튼, 가게에 채팅하기 버튼, 그리고 종류에 따라 달라지는 행동 유도 — 주문, 상품 보기, 객실 예약, 진료 예약. 피드에 가게로 글을 올릴 수 있고, 그 글은 항상 전체 공개입니다.
그 페이지의 리뷰는 손님이었다는 것을 데이터베이스가 증명할 수 있는 사람만 쓸 수 있습니다. 매장에서 먹었거나, 배달을 시켰거나, 묵었거나, 서비스를 받았거나, 패키지를 샀거나. 그 외의 사람에게는 왜 쓰기 버튼이 없는지 설명하는 잠금 카드가 보입니다. 별점은 데이터베이스 트리거가 리뷰 행에서 다시 계산하며, 우리를 포함해 누구도 입력할 수 없습니다. 어떤 리뷰에든 답글을 달 수 있습니다.