Homestay & Chalet Booking System: Count Nights, Not Time Slots

A two-unit homestay in a kampung. A family messages to check in on 1 August and out on 4 August. The owner writes it in the book: "1–4 Aug, Unit A". Two days later somebody else asks whether 4 August is free. The owner looks at the book, sees "1–4", and replies "sorry, fully booked". But 4 August is the departure day — after noon that unit is empty. One sellable night, lost to a dash in a notebook.

A six-unit chalet by the beach. Everything fills up during the school holidays, and the owner runs it from a WhatsApp group with two staff. Some guests have paid a deposit; others said "I'll bank in later". On Friday night two families arrive at once, both holding chat threads that look equally confirmed. One unit, two families, and the owner refunds one of them — plus the reputation.

A guesthouse in town with eight daily-rate rooms. Guests often arrive late because flights slip, so the owner sends the door code early to save them waiting. The problem is that the code goes out when the guest first asks — before paying. Some never show up and never pay, but the code is already in their hands.

Why this keeps happening

The root of it: accommodation is not an appointment. A salon sells a 45-minute slot. A homestay sells nights. An ordinary booking system asks "what time?" — a question that means nothing to a guest staying three days. When an owner forces a homestay into an appointment system, every stay becomes a single 3 p.m. "appointment", and the system knows nothing at all about the second and third nights.

Second: the check-out day is almost always counted wrong. In on 1 August, out on 4 August is three nights — the 1st, 2nd and 3rd. Nobody ever sleeps there on the night of the 4th. If the system (or the notebook) treats 4 August as part of the booking, every booking eats one night that should have been for sale. Six units, averaging eight bookings a month each, and that is close to 50 lost nights a year per unit.

Third: "full" is not one answer — it is an answer per night. Two units free on Monday does not mean two units free all week. When an owner works it out in their head they compare date ranges, and ranges overlap other ranges even when no single night is actually sold out.

Fourth: proof of payment is scattered. Deposits arrive as screenshots in a private chat, a group chat, and sometimes email. When two staff are answering the same thread, there is no single place anyone can trust to say who has paid.

What owners try instead

Most common: a notebook or a wall calendar, one row per unit. Clear to the eye, impossible to check from anywhere else, and the check-out day stays permanently ambiguous — which is exactly what caused the first story above.

One step up is a spreadsheet: a column per date, a row per unit, yellow for deposit paid and green for confirmed. This genuinely works — until peak season. Once there are twenty enquiries a day, colouring cells one by one becomes a full-time job, and nobody notices the cell that got missed.

Others lean on a rental platform's calendar. Fine for bookings that come through that platform, but repeat guests and direct WhatsApp bookings never appear there — and direct bookings are the ones with no commission taken out.

The riskiest version: keeping it all in your head. Workable at two units. It collapses at the sixth, or on the first day the owner is ill and staff have to answer the messages.

How night-based booking should work

First principle: the system has to count nights, not hours. In TempahKu, choosing an accommodation business type when you sign up — homestay, chalet, resort, villa, guest house, room rental — puts your account straight onto the night-based engine. Your booking page asks for a check-in and a check-out date instead of a time. You do not have to ask anyone to switch a setting afterwards.

Second principle: the check-out day is not a night. This is enforced in code rather than left to the owner's memory. A booking from 1 to 4 August takes three nights, and 4 August stays open for the next guest. The rate you set is the rate per night, and the system multiplies it by the number of nights itself — so a three-night stay is never accidentally charged as one.

Third principle: availability is decided by the busiest night. This is the easiest part to get wrong, so here is a real case. You have two units of the same type. You already have bookings for 1–3 August and 5–7 August. Now somebody wants 2–6 August. That new range overlaps both existing bookings, so a rough check says "full". But count night by night and no single night ever has both units occupied — so the booking should be accepted, and TempahKu accepts it. The system expands the range into individual nights and lets the busiest one decide.

Fourth principle: the door code is not public information. In TempahKu, your check-in instructions — usually a door code or where the key is — are only sent in the confirmation email on the settled-booking path. Never on the public booking page, and never before payment. Staff who do not have permission to see them cannot see them either. The failure in the third story simply cannot happen by accident.

Fifth principle: an owner must be able to answer "who is in the units tonight?" in three seconds. For accommodation businesses, the TempahKu dashboard shows an occupancy panel: occupancy percentage, how many unit-nights sold against available, and the list of guests currently staying today. Not a list of 3 p.m. appointments — a picture of who is inside, tonight.

One more piece that closes the deposit gap: you can require a deposit at booking time, and guests pay it by QR straight into your account. The payment and its receipt are stored against that booking, not in a chat thread.

When it helps most

The difference is sharpest for owners with more than one unit. A single unit fits in your head. From three units up, with overlapping stays and staggered departure dates, busiest-night counting is what rescues the bookings that used to be turned away for no reason.

It also matters for seasonal homestays — school holidays, festive weeks, event weekends — when enquiries arrive faster than anyone can update a calendar. If the system decides availability, staff never have to judge it themselves.

And for self check-in properties with no one at a front desk. There, when the door code is released is not a convenience question. It is a question about the security of your house.

If you have one unit, every guest comes by word of mouth, and you take fewer than five bookings a month, a wall calendar honestly still does the job. The sign that it is time to change is when you start hesitating to answer "is it free?" without opening the book first.

In short

The difference between an appointment system and an accommodation system is not vocabulary. It is what the thing counts. A system that treats a stay as a single "see you at 3 p.m." will miscount every night after the first, miscount the check-out day, and answer "is it free?" wrongly — three mistakes that each cost you a sellable night.

TempahKu runs a night-based engine for homestays, chalets, resorts, villas and room rentals: per-night pricing, a check-out day that stays sellable, availability decided by the busiest night, check-in instructions released only after payment settles, and an occupancy panel so you know who is inside tonight. If you have ever turned a guest away for a night that was actually free, that alone makes it worth trying.