A WhatsApp check-in bot that never invents a link is one where the AI is not allowed to write links at all. In ours, every portal link, door code and gate pass is produced by ordinary code from the booking record; the AI only decides which prepared answer to send, and when it has no fact to stand on it says nothing and hands over to a person.
That is the whole idea. The rest of this article is how we got there running 100+ homestay units in Johor Bahru and Desaru on AntlerChat, including the day our own bot made up a URL.
Why is an invented link the worst thing a check-in bot can do?
Because the guest is standing at a gate at 11 pm with luggage, and a link that goes nowhere is worse than no reply. A wrong price can be refunded. A wrong link means the guest cannot get in, calls you, leaves a one-star review, and tells the next guest.
It is also not a theoretical risk. In 2024 a Canadian tribunal held Air Canada liable after its support chatbot described a bereavement refund policy that did not exist; the airline argued the chatbot was "a separate legal entity" and lost. A language model that is asked to be helpful will fill a gap with something that looks right. A URL is the easiest thing in the world to make look right.
We learned this ourselves. Early on, our general-purpose AI was allowed to answer guests whose chat thread was already bound to a booking. The one time it was let loose, it invented a guest-portal URL that did not exist and then asked the guest for a booking reference we already had. We switched it off for bound threads the same week, and that decision is still written at the top of the code that runs reception today.
What does "automation" actually mean in a homestay check-in?
Most articles about Airbnb or homestay WhatsApp automation are really about scheduled templates: booking confirmed → message, day before → message, check-out morning → message. That is useful, and we do it too. But templates are the easy half. The hard half is the guest who replies.
| Moment | Who starts it | What ours does |
|---|---|---|
| Booking lands | System | Welcome template with two buttons: continue on the portal, or do it here in chat |
| 7 days / 1 day before | System (optional, per operator) | Reminder with the guest's current step, sent inside the operator's own hours in Malaysia time |
| Guest replies "how to check in?" | Guest | Reads the booking's portal step and nudges the next real step, once |
| Guest taps Check in | Guest | Sends the arrival guide step by step, then the unit details and door code last |
| Guest asks "where is the pool?" | Guest | Answers from the unit's own facts, or hands to a colleague |
| Guest says "the door can't open" | Guest | Never answered by AI. Goes straight to a human |
The scheduled messages are off by default for every new operator, because turning them on means messaging real people who did not write to you. The replies to a guest who did write are on by default. That split sounds small; it is most of the trust.
Where do the links actually come from?
From the booking, through code, never from the model.
When a guest messages us on WhatsApp from the phone number on their booking, they have already proven that number. So instead of sending them a login code to the same handset, the system mints the guest portal's normal short-lived session token and wraps it in the portal's existing login callback. The guest taps and lands on their booking already logged in.
Three safety rules sit around that, and they are rules in code, not in a prompt:
- Auto-login only into a passwordless account. If the email on the booking already belongs to someone who set a real password, a booking reference is not proof of ownership. Those guests get a plain link and log in themselves.
- "Phone verified" is only stamped when the number messaging us matches the booking. A thread that staff bound manually, or a reference the guest typed, must never silently verify a stranger's number.
- Links are short-lived and never stored. The token lasts as long as the portal's own session (12 hours by default). If the system cannot read how long that is, it says nothing about timing rather than quote a number it invented.
The AI never sees any of this. It cannot produce a link because the function that produces links is not something it can call.
How does the bot know what step the guest is on?
It does not keep its own idea. The website portal and the WhatsApp chat are two front doors onto one state column on the booking: contact → identity (eKYC) → deposit/payment → unit ready → checked in → checked out. Both sides read that column every turn.
So a guest who did half the steps on the website, then opened WhatsApp, is not asked to start over. And a guest who answered two questions in chat and then opened the portal finds it waiting at the right step. Two rules the code obeys without exception: it never moves the step forward on its own initiative (only because the guest just did the thing that step was waiting for), and it never moves the step while a colleague is previewing in the test studio, because crossing into "unit ready" is what registers the guest with the building's real security system and issues a real gate pass.
There is a small human touch in here too. A nudge toward the next step is sent once per step. A guest who replies "thanks 🙂" does not get the same nudge again.
What does the AI do, if it is not writing the replies?
It does three narrow jobs, and each one is fenced.
Job 1: understand a sentence the rules did not catch. A table of patterns runs first: "check in", a menu digit, a booking reference, a stored session. Only when every rule returns nothing does a model get asked to classify the sentence into one of four labels. It has to return the words from the guest's message that decided it, and those words must actually appear in the message. A model that invents its evidence has invented its answer, and the whole reply is dropped. Below a confidence floor, it does not route at all and the default runs. Each judgement is cached by exact sentence, so the second guest to type it costs nothing.
Job 2: answer a factual question about the unit. "Where is the pool?", "what floor is the gym?" This model is handed the unit's recorded facts and the operator's FAQ, and nothing else. Its instructions include: never invent a floor, a time, a price, an address or a phone number; never give out a link of any kind; never tell the guest to "check the manual"; and if the guest is reporting something broken, leaking, locked or unsafe, give no answer so a person picks it up. If the facts do not contain the answer, it replies with a fixed no-answer token and a colleague is paged.
Job 3: nothing else. Prices, dates, refunds, extensions and cancellations are never generated. They come from the booking or they do not get said.
When does the bot give out the door code, and when does it refuse?
A door code, a wifi password and a mailbox code are the guest's own. Refusing to give them at eleven at night is not security, it is bad service. But the person asking has to actually be checked in.
So the codes sit behind the same question every other part of the system asks: has this guest completed check-in? Before that, they are masked, exactly as the printed guide masks them. After that, they are given on request, in the guest's language.
Operators also get a per-capability switch: give the door passcode, open the door remotely, send the deposit link, and so on. "Off" never means silence, and it never means "the operator disabled this." It means a colleague answers instead, and the guest is never told a switch was involved. Every switch is enforced inside the one function that produces that thing, not at the nine places that call it, because a guard you have to remember nine times is not a guard.
What goes out when the guest taps "Check in"?
In this order: photo 1, instruction 1 (auto-translated into the guest's language), photo 2, instruction 2, and so on, with the unit's listing details and door password last, so the guest reads the route before they get the key.
If the listing has two arrival guides, the bot sends the one matching how the guest said they are arriving (driving or Grab). If it only has one, everyone gets that one. We added that second rule after realising that sending nothing because the guest ticked "Grab" and the only guide was labelled "driving" would be the rule outranking the point of the rule.
We wrote recently about a guest who could not open a smart lock even after receiving all of this. Automation delivers the instructions. It does not guarantee anyone reads them. That is the honest limit of this whole category of software.
Does any of this work without AntlerHub?
AntlerChat runs on its own for any business: WhatsApp Cloud API, Instagram, Messenger, TikTok and a website widget in one inbox, with AI replies in the language the customer wrote in. The booking-aware behaviour described above (steps, door codes, gate passes, guides) needs the booking record, which is what AntlerHub provides. Operators on AntlerHub get it linked out of the box.
Pricing as listed on our pricing page today: RM 450 a month with no commitment, RM 405 a month on a one-year plan, RM 360 a month on two years, each including one WhatsApp Web number; every additional WhatsApp Web number is RM 200 a month. Prices are before SST.
What should you ask any vendor before letting a bot talk to your guests?
Not "does it have AI". Ask these instead:
- Can the AI write a URL into a message? If yes, how was that tested?
- What happens when it does not know? Does it say so and page a human, or does it try?
- Where is the "current step" stored, and does the website agree with the chat?
- Is the door code given before check-in is complete?
- Do messages respect Malaysian hours, or the server's clock?
- Can I turn one capability off without the guest being told a robot refused?
If a vendor cannot answer those from their own architecture, the honest answer to "will it ever invent a link" is "we hope not."
If you run homestays in Malaysia and want to see this on your own WhatsApp number, with your own listings connected, start at /chat.