AI for Hotel Guest Emails: Why Every Reply Still Gets Approved

Most hotel inboxes are not full of difficult emails. They are full of the same questions, asked slightly differently, every day of the week.

We built an email assistant for an apartment hotel in South East Queensland that does something deliberately limited. It reads incoming guest emails, finds the relevant answer in the property's own knowledge, and drafts a reply. Then a member of staff approves it. Nothing is sent without a person saying yes.

Client details are omitted — the work belongs to them.

The problem

The property receives a lot of guest email. We do not have a precise count, and we are not going to invent one. What was clear from the start was that most of it asked the same common questions.

The typical mix for an apartment hotel will be familiar to anyone who has worked a front desk. What time is check-in, and can we arrive early? Is late checkout available? Is there parking, and what is the height limit? Are pets allowed? How do I change or cancel my booking? Can I get a tax invoice for a corporate stay? Is there a long-stay rate? Is there a laundry, how often is housekeeping, can we leave our luggage after checkout, can you supply a cot, and how do we get there?

None of those questions is hard. Each needs a correct, specific answer, and that answer almost always exists already — in a policy, an FAQ, or a reply someone sent last week. High volume and a known set of answers is exactly the profile of work that suits automation.

What we built

Incoming emails are matched against the property's own knowledge. FAQs, policies and previous replies are stored in a vector database, which searches by meaning rather than exact wording. "Can we bring the dog?", "are pets OK?" and "we're travelling with a small cavoodle" should all find the same pet policy.

A reply is drafted from what was retrieved. An AI model writes the draft using the retrieved material as its source. Facts are retrieved, not generated. If the answer is not in the property's knowledge, the right draft says so and leaves it to a person rather than filling the gap with something plausible.

Every draft goes to staff for approval. A person reviews the proposed reply against the guest's email and approves it, edits it, or writes their own. Nothing goes out automatically.

That last step was the owner's request, made for reasons of trust. In our view it is the right way to introduce AI to any inbox that customers write to.

Why approval comes first

A reply to a guest is a commitment in writing. If an email says early check-in is available, or that a cancellation will not be charged, the guest will reasonably hold the property to it. A live inbox is the wrong place to find out how often a system gets things wrong.

Approval changes the cost of a mistake. While a person approves every reply, a bad draft costs a staff member a moment to fix. The guest never sees it.

It changes how staff relate to the system. Software that emails guests without anyone seeing it is something done to the front desk. A ready draft you can send, fix or discard is something the front desk uses.

It produces the evidence for the next step. Every approval and every edit is a record of how reliable the drafts actually are. Without that record, letting the system send on its own would be a guess.

Phase out with trust, not switch on and hope

The intent is to relax the approval step gradually, as the drafts prove themselves. That has not happened yet, and it is not designed to happen all at once.

The alternative is to switch automatic sending on from day one and fix problems as they surface. The trouble is who finds the problems: guests. A confidently wrong answer, once it is in a guest's inbox, is hard to take back.

How trust gets measured. The useful figure is how often a draft is approved without edits, broken down by question category. A single overall rate hides what matters: a system can be reliable on check-in times and unreliable on cancellations, and a blended average conceals exactly the category that should not be trusted.

Edits deserve reading, not just counting. A reworded greeting is style. A changed time, fee or policy is a substantive miss, and usually points to a gap in the knowledge rather than the writing.

How approval gets relaxed. Category by category, never for the whole inbox. When a category such as parking has a long run of drafts approved unchanged, it becomes a candidate for sending without approval while everything else still goes to a person. That decision belongs to the owner, and it should be reversible. Even then, a sample of sent replies should still be reviewed, so the evidence keeps accumulating.

Where it goes wrong

The hard part is not writing a good reply. It is recognising when an email should not get a drafted reply at all.

Questions that look like FAQs but are not. "What is your cancellation policy?" is an FAQ. "My father has gone into hospital and we need to cancel — can you waive the fee?" uses many of the same words and is a completely different email. It is a request for discretion from someone having a hard time, and a correctly quoted policy is the wrong response. Semantic search is very good at finding the cancellation policy for that email, which is precisely the risk.

Complaints and refund disputes. An unhappy guest needs a person. A polished, policy-shaped reply reads as being processed.

Special requests. An anniversary, an accessibility need, a very late arrival. Often answerable, but the answer depends on the specific booking and what the property can arrange that week, and neither is in an FAQ.

Payment details and personal circumstances. Guests sometimes include card details in an email, or explain a medical or family situation. Those belong with a person, not a drafting system.

These are the kinds of email a system like this should route to staff, flagged rather than drafted. Being over-cautious costs a staff member a few minutes. Being under-cautious costs a guest's goodwill.

Stale knowledge. The quietest failure. If the late-checkout fee changes and the knowledge base is not updated, the system will draft the old answer confidently — and accurately, according to its sources. While every reply is approved, staff catch this. Once approval is relaxed for a category, keeping its knowledge current has to become someone's job, not something done when someone remembers.

Privacy

Guest emails contain personal information — names, contact details, stay dates, and sometimes far more — so the Australian Privacy Principles apply. In practice that means using guest emails only to answer guests, restricting who can see emails and drafts, setting how long they are kept, and knowing where the data is processed, because under APP 8 a business remains accountable for personal information it sends overseas.

One point is specific to this design. Previous replies are a valuable source because they capture how staff actually answer, but they also contain other guests' details. Anything guest-specific has to be stripped before a past reply becomes part of the knowledge, so one guest's information can never surface in a reply to another.

Whether this applies to your property

The test is not whether you receive a lot of email. It is whether a large share of it asks questions you have already answered, and whether those answers are written down or could be.

If both are true, an approval-first assistant is a low-risk place to start. It does not replace the front desk — the complaint, the special occasion and the guest with a problem still reach a person. Staff keep control of every reply from the first day, and the property builds its own evidence, one category at a time, for how far to trust it.

If most of your email is bespoke — group bookings, events, negotiated corporate rates — the case is weaker, and we would rather establish that in a discovery conversation than after a build.