Pre-Arrival Guest Communication (Hotels)

Paid pluginsize Mplanned, not built

Indicative price, not an offer: €19/mo; SMS/email pre-check-in, QR check-in, property details

Generated from docs/plan/paid/pre-arrival-guest-communication/PLAN.md in the AstroBaaS repository. Nothing described below is implemented — it is the written plan for it.

Pre-arrival emails and SMS messages sent to guests 7 days and 1 day before arrival. Include wifi password, parking address, check-in instructions. QR check-in link lets guest verify arrival time and receive room code via mobile (no app download needed). SMS delivery tracking via Twilio. Reduces ‘where is parking?’ support calls.

The problem

Guests arrive without knowing parking details, wifi password, or exact check-in time. Customer service gets flooded with ‘where is parking?’ calls. Email alone misses urgent information. Hotel needs mobile-friendly pre-check-in flow to guide guests without staff involvement.

What it does

• Pre-arrival email (7 days before arrival)
• Pre-arrival SMS (1 day before arrival)
• Customizable templates (hotel branding, custom fields)
• QR code check-in link (guest scans, no login needed)
• Property details (wifi password, parking address, check-in hours)
• Arrival time update (guest can reschedule via link)
• Room code issuance (upon check-in)
• Mobile-responsive check-in form (no horizontal scroll)
• SMS delivery tracking (sent/failed status)
• Webhook on check-in via QR

What it deliberately does NOT do

Each boundary carries its reason. A boundary without a reason gets crossed by the next person who reads this.

• Door lock integration (Salto, Assa Abloy) — hardware lock-in, no standard. Reason: vendor fragmentation.
• Actual room key issuance — keyless entry or physical key is separate system. Reason: hardware integration.
• Parking lot management — we communicate parking details only. Reason: different operational system.

Data model

New tables: pre_arrival_messages (messageId, bookingId, sendTime, channel (email/sms), status (queued/sent/failed), template_used, sent_at, delivery_error). check_in_tokens (tokenId, bookingId, token (unique), expires_at, used_at, room_assigned, guest_ip). Booking schema: add preArrivalEmailSent, preArrivalSmsSent, checkedInViaQr, roomCode. Property schema: add communicationTemplate, wifiPassword, parkingAddress. Audit: all pre-arrival sends + check-ins. Migration: add tables + columns.

API

• POST /api/admin/pre-arrival/send-batch
• GET /api/pre-arrival/{checkInToken}
• POST /api/pre-arrival/{checkInToken}/check-in
• POST /api/pre-arrival/{checkInToken}/update-arrival-time
• GET /api/admin/properties/{propertyId}/communication-template
• PUT /api/admin/properties/{propertyId}/communication-template
• POST /api/webhooks/twilio/sms-delivery

Every route added here must also appear in src/pages/openapi.json.ts — a test fails the build if it does not.

Admin

Template editor (email body, SMS text, include dynamic fields: wifi, parking, room). Send schedule UI (when to trigger: 7 days, 24 hours). Delivery dashboard (sent, failed, bounced). Check-in flow preview (mobile mockup). Property details manager (wifi password, parking address, check-in rules).

The seam — why this is paid

Core owns: booking extensions, message templates, mobile check-in UI, QR generation. Paid pack owns: SMS delivery (Twilio), check-in token system, mobile form design.

Support commitment: SMS delivery SLA, check-in mobile app, keyless integration

Dependencies

• Booking/reservation system
• SMS provider (Twilio)
• Email system
• Webhook system
• QR code generation library

Acceptance checks

Each of these must be able to fail. Before claiming this is done, break the code deliberately and watch each one go red.

• Pre-arrival email sent 7 days before; includes wifi password + check-in link
• Guest clicks QR link in SMS; mobile form loads (no login required)
• Guest checks in via form; receives room number + door code
• Check-in token expires 1 day after check-in date (cannot reuse)
• SMS delivery webhook updates message status to ‘sent’ or ‘failed’
• Guest updates arrival from 3pm to 5pm via link; visible to staff immediately
• Property details customized per property (not global)
• Delivery report: 47 sent, 3 failed (invalid numbers)
• Mobile check-in form responsive on iPhone SE + Android (375px width, no scroll)
• Staff sees ‘Guest checked in via QR at 2:45pm’ on arrival screen

Risks

QR token reused: another guest scans same QR, gets wrong room code. SMS delivery delayed 5 minutes: guest already arrived, doesn’t see instructions. Wifi password exposed in email: guest shares password, security breach. Check-in form fails silently: guest doesn’t see room code, calls desk. Room code never actually issued: guest has code but can’t enter room. Token not invalidated after use: token reused across bookings.

Commercial context

The anchor is what the nearest equivalent charges on Shopify or Magento today. It is context for a pricing decision, not the decision.

---

Generated from the commerce plan. See docs/COMMERCE-PLAN.md for the full catalogue and ../../AI-GUIDE.md for how to work on this repository.