6.7 KiB
Controlled FAQ auto-replies
The first automatic-response implementation supports seven exact English questions about check-in, check-out, parking, breakfast, Wi-Fi and the hotel's address. An owner maps each question to approved hotel knowledge. Responses use that answer verbatim plus the hotel signature; no AI classification or rewriting occurs.
Start with test mode
Open FAQ automation, choose a question and approved answer, enable the rule and save it. Use Try a question to inspect the content match without sending. This tester does not simulate recipient, MIME, Gmail-thread or quota checks. Use Test mode with a connected sandbox mailbox to evaluate newly received messages and inspect the actual incoming-message results. Test matches do not create deliveries or consume quotas.
Matching tolerates case, whitespace and trailing question marks/full stops. It does not remove greetings, signatures, quoted text or additional requests. Subjects must be blank, one of the supported questions, or a short permitted heading such as Question, Quick question, Parking question, Check-in, Breakfast or WiFi. Unsupported content stays with staff.
The first version requires a top-level plain-text MIME message. HTML and multipart messages are held for staff because the alternate body may contain context missing from plain text. Attachments, multiple recipients, CC/BCC, reply threads, mailing lists, automated-message headers, mismatched Reply-To and no-reply senders are also excluded. Old imported messages without the new eligibility flag cannot qualify.
Enable live mode after acceptance
Keep AUTO_REPLY_ENABLE_LIVE=false in the deployment .env until the Google send/reconciliation workflow and FAQ test-mode results have been accepted. Then set it true and restart both API and worker. Gmail sending must be configured, the hotel must enable staff sending, and the mailbox must have send consent. Finally, the owner explicitly confirms test-mode acceptance and selects Enable live replies.
Before test-mode acceptance, use Batch safety evaluation with representative synthetic cases. Each JSON case has a unique id, subject, body, expectedMatch, and optionally expectedKnowledgeId. The no-send evaluator accepts 1–100 cases, reads the hotel's current reviewed rules and knowledge, and reports false positives, false negatives and per-case reasons without saving a conversation or consuming a quota.
The minimum activation gate is zero false positives, zero false negatives for every supported exact question, and explicit exclusions covering additional requests, booking/payment/refund language, emergencies, accessibility or medical context, greetings/signatures, reply threads, and unsupported wording. Where expectedMatch is true, set expectedKnowledgeId so the case also proves the intended approved answer was selected. Keep the evaluated case set and result with the restricted acceptance record. Passing content cases does not replace mailbox-header, threading, quota, stop-control or delivery acceptance.
All modes default to Off. Every mode change creates a new activation boundary and invalidates previous queued automatic approvals. Only untouched messages received after activation and within the last 24 hours are eligible. Switching Test to Live does not send replies to previous test matches. The evaluation worker runs about every 30 seconds; the existing delivery worker handles approved outgoing messages.
Limits and rechecks
MongoDB uniquely reserves one automatic reply per Gmail thread, one per recipient per UTC day across the hotel's mailboxes, and at most 20 daily hotel slots. Slots are reserved before queueing and are not recycled after rejection or failure. Deliveries cannot carry their approval into a later UTC day. Limits concern GuestOps automation, not messages sent manually in Gmail. UTC boundaries are not rolling 24-hour windows.
The worker rechecks hotel mode, activation, server enablement, rule version, approved knowledge version and exact reply text before sending. It reads the current Gmail thread and requires the original inbox message to be its only message. A rule/answer edit or a new thread reply therefore stops queued automation. Changes made after the final read and provider submission cannot be eliminated atomically; a message already submitted to Gmail cannot be recalled by the stop control.
Automatic MIME includes Auto-Submitted: auto-replied and X-Auto-Response-Suppress: All, following the loop-prevention guidance in RFC 3834. This does not guarantee cooperation from every mail system.
Staff handover and recovery
Non-matches remain in the inbox with an evaluation reason. Existing staff edits, drafts and deliveries are never overwritten. Editing an approved knowledge answer invalidates its FAQ rules until an owner reviews and saves them again.
A rejected automatic delivery was stopped before Gmail submission. Return to staff review releases its draft for manual review and preserves the rejected approval evidence. Uncertain outcomes cannot be released or automatically replayed; use the existing read-only Gmail Sent verification. Turning automation off stops pending automatic deliveries at the next pre-send check. Manual staff-approved replies remain governed by their own controls.
The database retains thread/recipient/quota reservations and evaluation evidence. The UI shows evaluated messages among the latest 500 inbox records. An evaluation interrupted before queueing can consume a slot without sending; it is deliberately not automatically retried.
Acceptance and follow-on work
Automated tests use fake provider handlers and MongoDB; they never send live emails. They cover exact matching, exclusions, tenant boundaries, changed answers, concurrent evaluation, quotas, rule/epoch invalidation, Gmail-thread changes and uncertain delivery. Live acceptance remains pending.
Test allowed questions and exclusions with your sandbox mailbox, verify duplicate prevention across restarts, inspect the actual received email, and exercise the stop control before enabling a hotel. Record the owner responsible for rule changes, the operator monitoring the first live window, the rollback decision-maker, and the duration of heightened monitoring. Any false positive, unexpected recipient, duplicate, uncertain unreviewed outcome, or changed knowledge answer is a stop condition: select Turn off, preserve evidence, and reconcile in-flight work before considering reactivation. Broad natural-language matching, multilingual questions, greetings/signature stripping, HTML/multipart equivalence and higher throughput are follow-on work requiring representative evaluation. PMS actions, payment requests and complex guest issues remain staff workflows.