KoratHotel and rental management software usually splits at the nightly/monthly line: a hotel PMS on one side, a rental ledger on the other, and an owner who runs both keeping two systems in step by hand. Korat's Stay module refuses that split. Hotel, resort, apartment, condo, village or house, and guesthouse are one business type with one room-type catalogue underneath. A property can take a booking for two nights and a tenancy for a year from the same room grid, and the month-end reports cover both.
Room types are the unit, not individual rooms
A property is described as a set of room types — each with photos, a nightly rate, a quantity, a description and amenities — rather than as a list of individually configured rooms. That is the shape the pricing and the availability actually take: eight identical superior doubles are one product with a count of eight, and treating them as eight products means eight places to change a rate and eight chances to miss one. Browsing shows a grid or a list with a "from" price, the rating and a type badge, so a guesthouse and a condo are distinguishable before the tap.
The rating on the card comes from guests who provably stayed
The rating on that card is not a number the owner set. Like every rating in Korat it is recomputed by a database trigger from the review rows, and only a guest the platform can prove stayed there may write one — staying is one of the qualifying kinds in the review-eligibility view.
Seasonal and promotional pricing, computed once and used twice
Rates change: Songkran (Thailand's mid-April new-year holiday, when travel spikes), long weekends, low season, a promotion the owner runs for a fortnight. So a room type carries pricing rules, each a date range plus an adjustment expressed as a percentage or a flat baht amount. The important part is not that the rules exist — every booking system has some version of them — it is that the number on the browse list and the number the booking is charged at come out of the same helper. There is no separate display-price calculation to fall behind the real one.
The classic failure in this feature is a search result priced by one code path and a checkout priced by another: the guest is shown a price the property never agreed to and then charged a different one. Sharing the helper makes that disagreement structurally impossible rather than something to test for. When a promotional rule applies, the card shows the struck-through base rate with a badge, so the guest sees the size of the adjustment and not just a lower number.
A booking is a request the property confirms
Online booking collects check-in and check-out dates, the guest and a phone number, and lands in the property's bookings inbox. The owner confirms it. The pending count sits on the business console dashboard as a live badge that refreshes every few seconds, alongside the other things a business is expected to answer, so it is not a queue anyone has to remember to open.
Room service requests land in the same console
Mid-stay, a guest can send room service requests from the app; they arrive in the same console. A spa or treatment room inside the property is booked through the services module instead, which is where a duration, a staff assignment and a prepaid course live. Room service itself is a small feature with an outsized effect on how a small property runs, because the alternative is a phone in a room nobody answers or a walk to reception.
A booking is a reservation, not a prepayment. The flow collects dates, guest and phone, and the property confirms. Korat does not take a card at booking, hold a deposit, or process the room charge — settlement happens with the property.
The same applies to a monthly bill: it is generated, shown to the tenant and carries a paid flag the owner sets. The flag records that money arrived; it does not move it.
The owner's room grid and console
The console gives a property four tiles: a room grid with check-in and check-out, a room-type manager including the season rules, the bookings inbox, and monthly rentals. The grid is the screen a receptionist lives in — occupancy at a glance, and the two actions that change it — while the room-type manager is where rates, quantities, amenities and pricing rules are edited once.
Reports, CRM and HR — the tiles every business type gets
Around those sit the tiles every business type gets. Reports cover revenue, order count, average ticket, a split across cash, PromptPay and other, the top five best sellers, a seven-day revenue chart, and periods of today, seven days, thirty days or all time, with receipt reprint and shareable receipt text — a tax invoice cannot be issued, because only a VAT registrant may issue one and nothing in this system records any shop's registration yet. CRM builds a customer list from the sales ledger with notes, tags, history, loyalty points earned at a rate the shop sets in its own currency — for a property serving returning weekday business guests, that history is the useful part. HR covers clock in and out with GPS and a note, leave requests, shifts and payroll with worked minutes and overtime past eight hours a day, announcements and tasks.
Monthly tenancies: meter readings become a bill
The monthly rental side is where the module stops resembling a hotel system. Renting out things that are not rooms — a car, a costume, a piece of equipment — is a different module again: rentals. A room type carries its own rent and utility configuration; a room carries a tenant and a deposit; and each month the owner enters water and electricity meter readings. The bill is generated from those readings — the reading is the input, the bill is the output, and the arithmetic is not done on paper and then typed in as a total nobody can check later. Each generated bill carries a paid flag, so the outstanding list is a query rather than a memory.
This is the part of running a small apartment block that produces the most disputes, precisely because it is usually done in a notebook. Keeping the readings alongside the tenancy means a bill can be traced back to the two numbers it came from — a better answer to "why is it higher this month" than a recalculation from scratch.
Staff permissions, and what the guest never sees
Console access runs on a permission matrix: thirteen core capabilities plus whatever installed modules add, role presets — owner, manager, waiter, kitchen, staff — and per-person overrides. Tiles are hidden when a member lacks the capability, and a member with nothing sees an explicit "you have no permissions yet" state rather than a blank screen that reads as breakage. None of these tiles carry a monthly fee; what a shop package and the add-on plugins each include is set out on the plans page.
In the Android app those checks run on the client. The same matrix exists in the database as has_capability(business_id, capability), used by row-level security policies and expanded server-side so the server never trusts the client's idea of a role — but it would be overstating things to say the entire console is server-enforced today, so it is not said.