An upcountry hotel goes digital, part 3: let the front desk catch phone/LINE bookings and leave a trace

This series follows an upcountry Thai hotel, step by step, into digital. The story comes from our real implementation experience in hospitality — if you run a small accommodation in the provinces, you should see your own front desk in every chapter. Each chapter explains: what was built, what was deliberately not built, and what evidence earned the right to move on.

The traffic came in, but the front desk was still a fog

The map and website pulled direct enquiries in. A guest reads the room pages, then calls or messages on LINE asking “is room X free this Wednesday?” The front desk takes the order as usual — but after taking it, where does that booking land?

• on a piece of paper;
• in the LINE chat history;
• or, more often, in memory.

So the familiar scene appears: the owner asks “this month, how many rooms did phone and LINE actually book, which type is hottest, where did they all come from?” — the front desk can’t answer, and the owner can’t say either. The traffic came in, but the data didn’t stay. This chapter solves exactly that one thing.

What phase one actually did: turn direct enquiries into one record

No backend system, no CRM, no PMS was built here — just one unified enquiry record that the front desk fills in naturally while taking orders. Every direct enquiry records four things:

1. Source — phone, LINE, or a call that started from a Google Maps click into the website;
2. Room type — which room was asked about;
3. Dates — which nights they wanted;
4. Outcome — booked, still deciding, didn’t book, cancelled.

The record lives somewhere the front desk already uses and can update easily — maybe a shared spreadsheet, maybe the bookings book. The tool doesn’t matter; what matters is that the front desk jots one line while taking the order, so the direct channel has visible data for the first time.

Why the front desk would do it, instead of seeing it as one more chore

This is where things fail most easily: if the record becomes “extra homework”, the front desk will cope first and give up later. So the design held three lines:

• Jot it while taking the order, not after. Before the call ends, the room type and dates the guest has just said are already the content to record — no recalling after the shift.
• Only record what drives decisions. No personal profiles of guests, no long notes required — four columns are enough. The record exists so the owner can see direction, not to produce a pretty report.
• The owner actually reads it. Flipping through once a week, and asking the front desk “which source booked more this week?” — only then does the front desk know someone really looks at this, and it isn’t fill-and-forget.

If the front desk thinks this is paperwork for the owner, it won’t survive two weeks. The record becomes part of the workflow only when the owner actually makes decisions from it.

And handle the most common exceptions along the way

Provincial hotel bookings are rougher than what the Booking dashboard shows. The front desk handled these exceptions in the record too:

• Same-day stays. A guest books the same night late in the day — human confirmation takes it on the spot, no system rules needed;
• Passers-through. One night, park and sleep, leave — book whichever room is free;
• Cancellations and date changes. No online cancel button; the front desk confirms by word of mouth and updates the outcome to “cancelled”;
• Deposits. The deposit that should be collected is collected as before, noted in the record.

These exceptions are not “flaws the system hasn’t handled” — they are evidence that the manual process is still reliable at this stage. And they also tell you: if you ever build online booking, the rules must define all of these cases.

What this phase was deliberately not

• No PMS (front-desk management system). No availability board, no channel calendar, no occupancy reports — a twenty-room hotel doesn’t need a system to support it yet;
• No CRM. No guest profiles, no membership, no automated marketing;
• No online booking. The record shows the owner direction; it isn’t for guests to book online;
• No Agoda integration. The direct channel and the OTA each keep their own records; this phase does not connect them.

What entering the next phase requires

After the record had run for a while, the hotel could finally answer these questions:

• how many rooms phone/LINE booked directly, and what share of all bookings;
• which room type is hottest, which nights are hardest to sell;
• whether enquiries from the map, phone, or LINE are actually growing by source;
• where cancellations and date changes cluster.

Those numbers are what Part 4 is about — using phase-one data to judge whether a second phase is worth it.

---

Boundary matters: the shared spreadsheet or bookings book the front desk uses is a simple data tool the hotel maintains itself. The self-booking, PMS, CRM, online deposit payment, and channel-integration systems in this series are separate projects with their own scope — they are not part of a standard website package.