An AI Inbox That Answers Everything Will Draft a Reply to a Shipping Notification

Most "AI inbox" pitches lead with the reply: the software reads an email and answers it in seconds, tone right, details right, done. What nobody demos is the eighth message in that same inbox, the one from a courier confirming a parcel is two stops away. An inbox built to be helpful about everything will draft a warm, professional reply to that delivery notification too, because nothing told it not to. Multiply that by every SaaS renewal, every HR reminder, every bank notice a staff mailbox happens to receive, and "AI answers your inbox" quietly turns into AI drafting earnest replies to things that were never meant for a guest, let alone a reply. The real engineering problem in a hotel email inbox sits earlier than the reply: deciding, before any drafting happens, whether a message deserves one at all.

What an AI assistant for hotel email actually has to decide first

A naive AI assistant for hotel email would treat every unread message the same way: read it, judge whether it deserves an answer, write one. That single-judgment-call design is exactly where it breaks, because "does this deserve an answer" is really three separate questions bundled into one: is the sender known to us, does the content genuinely read as hotel business, and if the model can't confidently tell, what should happen instead of guessing either way. GuestMaker's inbox splits every inbound email onto one of four paths before a single reply gets drafted, and only some of those paths end with AI writing anything at all.

The four-path decision behind every inbound email

A message from a known contact, someone already sitting in the guest record, or a message that arrived from an OTA, gets the full AI treatment automatically. There's no ambiguity to resolve here: the system already has a reason to trust that the sender matters before a single word of the email gets read.

For an unknown sender, the AI is asked to judge relevance directly. If it's confident the message clearly isn't hotel business, the system skips AI handling entirely and no reply gets drafted. If it judges the opposite, hotel business from someone not yet on file, that message gets the same full treatment as a known contact. The fourth path is the one most inboxes don't bother building: an unknown sender the AI is genuinely uncertain about. Rather than guess and risk answering something irrelevant, or guess and risk ignoring an actual guest, the system drafts one specific fallback: a verification email asking the sender for their reservation number or stay dates before anything else proceeds. That single question resolves the ambiguity a model can't talk itself out of, a real guest can answer it in one line, and someone who was never a guest usually just goes quiet. Uncertainty gets a question, not a coin flip.

Why hotel email triage software runs three layers deep

That relevance judgment is only the first of three layers behind the AI's "is this hotel business" call, run in a fixed priority order, each one built to catch what the layer above it might miss, rather than a single model call trusted blindly. First comes the AI's own explicit read on relevance. Underneath that sits regex pattern matching tuned to the handful of non-hotel email types that show up in a shared mailbox again and again: bank notices, shipping and delivery notifications, SaaS product emails, HR emails, insurance emails, matched in both English and Spanish. If the AI's judgment and the pattern layer still leave something unresolved, a keyword-based heuristic runs as the last resort.

The point of stacking three mechanisms instead of trusting a single AI verdict is that a language model's confidence about "is this hotel business" and the actual, boring, structural shape of a shipping confirmation email are different kinds of signal. One is inference, the other is closer to a fingerprint. Hotel email triage software that leans on judgment alone will occasionally be talked into treating a well-written delivery notification as plausible guest correspondence, because a model reasoning in natural language can be reasoned with, even by an email it was never written to convince. Pattern matching doesn't get talked into anything: a courier tracking template reads like a courier tracking template in English or Spanish, confident model or not.

The keyword list built to override all of it

None of that layering is allowed to become a trap for real hotel business, though, which is why there's an explicit safety net sitting above the whole decision: a list of more than fifty real hotel-business keywords that can override every earlier layer and force full AI handling if a message clearly reads as hotel business, regardless of what the AI judgment, the regex patterns, or the keyword heuristic concluded on their own. It's the one place in the system where a simpler mechanism is deliberately given the power to overrule a more sophisticated one, because the cost of a false negative here, a genuine guest message getting silently skipped, is worse than the cost of running AI on a message that turns out not to need it. A regex layer built to catch bank notices and shipping confirmations is inherently conservative by design, so the keyword safety net is the deliberate counterweight, tuned to err toward answering rather than toward staying quiet.

An AI inbox spam filter that runs before triage even starts

Before any of that four-path logic even runs, there's a cheaper filter in front of it. A list of more than fifty known SaaS and tool domains, the kind of everyday software a hotel's own staff use for internal messaging or project management, gets discarded automatically as spam before triage begins. This is the part of an AI inbox spam filter for hotels that's easy to underrate: no model call, no judgment, nothing sophisticated about it, and that plainness is exactly why it earns its place ahead of anything that costs a model call. It's the same instinct behind the regex layer above it, applied one step earlier: stop the obvious cases as cheaply as possible, and save the AI's judgment for the messages that actually need it.

Where it connects, and what still isn't a dial you can turn

None of this triage logic is worth much if the inbox can't actually see the mail in the first place. It connects to Gmail through a push-notification subscription, so a new message triggers the pipeline the moment it lands rather than waiting on a poll, to Microsoft through webhooks working the same way, and to any other provider through IMAP polling, which is the part that makes a hotel's existing mailbox usable without a migration project. Whatever a hotel group is already running stays where it is.

One honest limit is worth stating directly: the confidence thresholds driving that "uncertain, draft a verification email" path are internal system defaults today, not a setting exposed on a dashboard. A hotel group that wants triage tuned looser or stricter for its own mailbox can't do that yet from the UI. That's a real boundary, not an oversight dressed up as one, and saying so plainly is a smaller kind of dishonesty than letting the feature imply a dial that doesn't exist.

Which is really the same design decision stated from the other direction. An inbox that claims to automate hotel guest email replies for absolutely everything, with no seams and no "we're not sure, let's ask" fallback, is promising more than any triage system can responsibly deliver. The version that's actually useful is the one that knows the difference between a guest and a courier, and says so out loud when it genuinely doesn't.