호텔과 펜션, 월세 세입자를 한 화면에서

숙박 관리 소프트웨어는 보통 「1박」과 「한 달」 사이에서 갈라집니다. 한쪽에는 호텔 PMS가, 다른 쪽에는 임대 장부가 있고, 둘 다 하는 주인은 두 시스템을 손으로 맞춰 둡니다. Korat의 숙박 모듈은 그 분할을 거부합니다. 호텔, 리조트, 아파트, 콘도, 주택, 게스트하우스는 하나의 비즈니스 종류이고 그 아래에 하나의 객실 타입 목록이 있습니다. 같은 객실 현황판에서 2박 예약과 1년 임대를 함께 받고, 월말 리포트는 둘 다 덮습니다.

단위는 개별 객실이 아니라 객실 타입입니다

숙소는 개별 객실의 목록이 아니라 객실 타입의 묶음으로 기술됩니다. 각 타입은 사진, 1박 요금, 수량, 설명, 편의시설을 갖습니다. 요금과 재고가 실제로 취하는 형태가 그렇기 때문입니다. 똑같은 슈페리어 더블 여덟 개는 수량이 여덟인 하나의 상품이고, 그것을 여덟 개의 상품으로 다루면 요금을 고칠 자리가 여덟 곳이 되고 하나를 빠뜨릴 기회도 여덟 번이 됩니다. 목록은 격자나 리스트로 「최저」 가격과 평점, 종류 배지를 보여주므로 게스트하우스와 콘도가 누르기 전에 구분됩니다.

평점은 투숙이 증명된 손님에게서만 나옵니다

그 카드의 평점은 주인이 적어 넣은 숫자가 아닙니다. Korat의 모든 평점과 마찬가지로 데이터베이스 트리거가 리뷰 행에서 다시 계산하며, 실제로 묵었다는 것을 플랫폼이 증명할 수 있는 손님만 리뷰를 쓸 수 있습니다. 숙박은 리뷰 자격 뷰에 들어 있는 조건 중 하나입니다.

시즌 요금과 프로모션은 한 번 계산되어 두 곳에 쓰입니다

요금은 움직입니다. 송끄란(태국의 4월 중순 새해 명절로 여행 수요가 몰립니다), 연휴, 비수기, 주인이 2주 동안 돌리는 프로모션. 그래서 객실 타입은 가격 규칙을 갖습니다. 각 규칙은 기간 하나와 조정값 하나(퍼센트 또는 가게 자체 화폐 기준 고정액)입니다. 중요한 것은 규칙이 있다는 사실이 아닙니다 — 예약 시스템이면 어떤 형태로든 갖고 있습니다. 중요한 것은 목록에 뜨는 숫자와 예약에 청구되는 숫자가 같은 함수에서 나온다는 것입니다. 실제 가격보다 뒤처질 수 있는 별도의 표시용 계산이 존재하지 않습니다.

이 기능의 고전적인 실패는 검색 결과를 계산하는 코드와 결제를 계산하는 코드가 다른 것입니다. 손님은 숙소가 동의한 적 없는 가격을 보고, 그와 다른 금액을 청구받습니다. 함수를 공유하면 그 불일치가 테스트로 잡아야 할 것이 아니라 구조적으로 불가능한 것이 됩니다. 프로모션 규칙이 걸리면 카드에 취소선이 그어진 기본 요금과 배지가 함께 보여서, 손님은 그저 낮아진 숫자가 아니라 조정의 크기를 봅니다.

예약은 숙소가 승인하는 요청입니다

온라인 예약은 체크인·체크아웃 날짜, 투숙객, 전화번호를 받아 숙소의 예약 수신함에 들어갑니다. 주인이 확인합니다. 대기 건수는 콘솔 대시보드에 몇 초마다 갱신되는 실시간 배지로, 비즈니스가 응답해야 할 다른 것들과 나란히 놓입니다. 누군가 열어보기를 기억해야 하는 대기열이 아닙니다.

룸서비스 요청도 같은 콘솔로 들어옵니다

묵는 도중에는 앱에서 룸서비스 요청을 보낼 수 있고, 같은 콘솔로 도착합니다. 작은 기능이지만 작은 숙소의 운영에는 영향이 큽니다. 대안이 아무도 받지 않는 객실 전화이거나 프런트까지 걸어가는 일이기 때문입니다.

주인의 객실 현황판과 콘솔

콘솔은 숙소에 네 개의 타일을 줍니다. 체크인과 체크아웃이 있는 객실 현황판, 시즌 규칙을 포함한 객실 타입 관리, 예약 수신함, 그리고 월세 임대. 현황판은 프런트 담당자가 하루를 보내는 화면입니다. 한눈에 보이는 점유 상태와, 그것을 바꾸는 두 개의 동작. 객실 타입 관리는 요금과 수량과 편의시설과 가격 규칙을 한 번에 고치는 곳입니다.

리포트, 고객 관리, 인사 — 모든 업종이 받는 타일

그 주위에는 모든 비즈니스 종류가 받는 타일이 놓입니다. 리포트는 매출, 주문 수, 객단가, 현금·PromptPay·기타 비중, 판매 상위 다섯 개, 7일 매출 그래프, 그리고 오늘·7일·30일·전체 기간을 덮고 영수증 재출력과 공유용 영수증 문구를 만듭니다. 다만 세금계산서는 발행할 수 없습니다 — 부가세 등록 사업자만 발행할 수 있는데, 이 시스템은 아직 어느 가게의 등록도 기록하고 있지 않기 때문입니다. CRM은 판매 원장에서 고객 명단을 만들어 메모, 태그, 이력, 가게가 자체 화폐 기준으로 정한 비율의 적립 포인트를 붙입니다. 주중에 다시 오는 출장 손님을 받는 숙소라면 그 이력이 쓸모 있는 부분입니다. HR은 GPS와 메모가 붙는 출퇴근, 휴가 신청, 근무표와 급여, 근무 분과 하루 8시간 초과분, 공지와 업무를 다룹니다.

월세 임대: 검침이 청구서가 됩니다

월세 쪽이 이 모듈이 더는 호텔 시스템처럼 보이지 않는 지점입니다. 객실 타입은 자기 임대료와 공과금 설정을 갖고, 객실은 세입자와 보증금을 갖고, 매달 주인이 수도와 전기 검침값을 입력합니다. 청구서는 그 검침에서 생성됩니다. 검침이 입력이고 청구서가 출력이며, 산수를 종이에서 한 다음 나중에 아무도 검증할 수 없는 합계로 옮겨 적지 않습니다. 생성된 청구서마다 납부 여부 표시가 붙으므로 미납 목록은 기억이 아니라 조회입니다.

작은 아파트 운영에서 분쟁이 가장 많이 생기는 부분이 바로 여기이고, 그 이유는 대개 이 일이 공책에서 처리되기 때문입니다. 검침값을 임대 기록 옆에 함께 두면 청구서를 그것이 나온 두 개의 숫자까지 되짚을 수 있습니다. 「이번 달은 왜 더 나왔나요」에 대해 처음부터 다시 계산해 보는 것보다 나은 대답입니다.

직원 권한, 그리고 손님에게 보이지 않는 것

콘솔 접근은 권한 행렬 위에서 돌아갑니다. 13개의 핵심 권한에 설치된 모듈이 더하는 권한, 소유자·매니저·홀·주방·직원의 역할 프리셋, 그리고 사람별 예외. 권한이 없는 멤버에게는 타일이 비활성이 아니라 아예 보이지 않고, 아무 권한도 없는 멤버는 고장처럼 읽히는 빈 화면 대신 「아직 권한이 없습니다」라는 명시적인 상태를 봅니다.

안드로이드 앱에서는 그 검사가 클라이언트에서 돕니다. 같은 행렬이 데이터베이스에도 has_capability(business_id, capability)로 존재하고, 행 수준 보안 정책이 그것을 쓰며 서버에서 프리셋을 펼치므로 서버는 역할에 대한 클라이언트의 주장을 믿지 않습니다. 다만 오늘 콘솔 전체가 서버에서 강제된다고 말하면 과장이므로, 그렇게 말하지 않습니다.

박 단위의 객실은 이 페이지, 월 단위의 임대인·임차인 계약은 대여입니다. 같은 건물이어도 같은 전표가 되지는 않습니다.

도착한 뒤에 잡는 마사지나 픽업, 가이드는 서비스의 예약이고, 객실 말고 물건도 판다면 리테일 쪽이 됩니다.