Guest Preferences & History (Hotels)

Paid pluginsize Mplanned, not built

Indicative price, not an offer: €24/mo; preference profiles, allergy tracking, VIP flags

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

Guest preference profiles for hotel repeat visitors. Store room type, bed type, floor preference, allergy details, VIP status. Auto-populate on rebooking. Staff can view/edit on check-in. Guests can review and modify their own preferences online. Audit log tracks all changes.

The problem

Repeat guests want same room, bed type, floor as last time. Manual notes in staff notebooks get lost when staff leaves. VIP guests book but find preferences ignored, creating frustration. No system-wide view of guest history across multiple visits.

What it does

• Guest preference profile (room type, bed type, floor, special requests, allergies)
• Guest profile (name, email, phone, VIP tier, notes, language preference)
• Visit history (previous stays, check-in/out dates, room assigned, rating)
• Auto-populate preferences on rebooking (suggest matching room)
• Staff can view/edit preferences on check-in
• Guest can review + modify own preferences via account
• VIP tagging (tier: bronze/silver/gold based on stay count or spend)
• Allergy tracking (shellfish, nuts, lactose, etc.)
• Audit log (who changed what preference, when)
• Webhook on preference update

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.

• Preferences shared across hotel chains — requires data governance + consent. Reason: privacy boundary; each hotel owns guest data.
• ML-based preference prediction — accuracy issues + algorithmic bias risk. Reason: liability.
• Housekeeping system integration (device push, room status boards) — different system, no standard API. Reason: vendor-specific.

Data model

New tables: guest_preferences (guestId, room_type_preferred, bed_type, floor_preferred, special_requests (array), allergies (array)). guest_profile (guestId, full_name, email, phone, is_vip, vip_tier, notes, preferred_language, created_at, updated_at). guest_visit_history (visitId, guestId, checkin_date, checkout_date, room_id, rating, notes). Booking schema: add guestPreferenceId, allergies_honored (boolean). Audit: all preference updates + user. Migration: add tables + foreign keys.

API

• GET /api/guests/{guestId}/preferences
• PUT /api/guests/{guestId}/preferences
• GET /api/guests/{guestId}/profile
• POST /api/guests
• GET /api/guests/search
• GET /api/bookings/{bookingId}/suggested-room
• POST /api/admin/guests/{guestId}/preferences
• GET /api/admin/guests/vip-list

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

Admin

Guest profile UI (search, view, edit). Preferences editor (bed type, floor, special requests, allergies). VIP tier manager. Visit history timeline. Check-in assistant (shows preferences, asks if valid). Preference audit log viewer.

The seam — why this is paid

Core owns: guest + booking schema extensions, preference storage, audit logging. Paid pack owns: preference matching algorithm, VIP tier management, guest data privacy compliance.

Support commitment: GDPR guest data privacy, preference accuracy SLA

Dependencies

• Guest/booking system
• Audit log
• Webhook system

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.

• Guest checks in; staff pulls profile showing ‘King bed, high floor, no nuts’
• Guest updates own preferences online; changes visible immediately in staff view
• On rebooking, system suggests Room 312 matching guest’s floor + bed preference
• Booking shows ‘Allergies: shellfish, lactose’ prominently
• VIP flag shows ‘>5 stays’ or ’>€5k lifetime spend’
• Audit shows ‘Guest updated room preference King→Queen on Sept 1 by guest’
• Staff adds note ‘Anniversary stay’; visible on future bookings
• Guest privacy: guest sees own preferences, cannot see other guests’
• Housekeeping sees allergy warnings on room status (integration dependent)
• Preference match accuracy: room type 95%+ match on rebooking

Risks

Outdated preferences forever: guest updates email but old preference lingers. Allergy list not shown to housekeeping: safety incident (nut allergy, room not sanitized). Staff edits without audit: guest profile tampered. GDPR erasure: preferences not deleted, compliance breach. VIP tier miscalculated: wrong guest marked VIP, receives undeserved benefits.

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.