Guest Experience Guide

Purpose

Task 60 turns the guest app into one coherent, occasion-first portal instead of a loose set of feature pages.

The goal is to make entry, RSVP, forms, schedule, seating, gallery, and return visits feel like one guided journey.

Occasion-First IA

The guest experience is organized around one occasion with a small number of calm guest-facing surfaces:

• overview
• events
• RSVP
• forms
• schedule
• seating
• gallery
• shared planning when available
• access/help

The overview is the control point. It explains the current journey state, shows the next recommended action, and keeps the guest oriented without exposing planner structure.

Entry And Access Model

Entry remains token-first and account-optional.

Supported entry modes now include:

• invitation links
• reminder links
• seating or schedule update links
• direct return visits on the same device

The shell resolves:

• occasion slug
• guest token
• entry source
• requested deep-link target
• saved return path

If a requested target is no longer valid, the app falls back to the backend-provided recommended target instead of landing the guest on a broken or empty route.

RSVP And Forms Integration

RSVP and forms are treated as one participation layer.

The backend bootstrap now computes journey state from:

• invited event count
• pending RSVP count
• pending form count

That summary drives:

• overview messaging
• navigation emphasis
• deep-link fallback
• recommended next step

Guests still use the dedicated RSVP and Forms pages, but the experience frames them as one coordinated guest task set.

Schedule, Seating, And Gallery Integration

These surfaces remain separately routed, but they are now integrated into the journey model through backend summary counts and availability:

• guest-safe schedule summaries only
• published seating only
• approved gallery items and upload posture only

Unavailable or unpublished surfaces do not dominate navigation. They appear only when relevant to the current guest context.

Deep-Link And Notification Behavior

Communications still own delivery. Guest routing now owns landing continuity.

Notification links now support target-aware entry, for example:

• invite links prefer RSVP when invited events exist
• RSVP reminders land toward RSVP
• return visits can resume a saved guest path when that path is still valid

If a target becomes invalid, the app falls back to the recommended journey target derived from the current backend bootstrap.

Mobile-First Considerations

The guest shell remains mobile-first:

• a simplified navigation set hides unavailable surfaces
• a sticky mobile bottom action keeps the next step visible
• return continuity avoids forcing guests to rebuild context after opening links from email or messages

Edge And Error States

The journey model explicitly supports:

• missing slug
• missing token
• invalid or expired invite
• occasion unavailable
• no visible events
• no RSVP needed
• no forms pending
• schedule not published
• seating not published
• gallery closed
• deep-link target no longer valid

Future Extension Points

This task leaves clean seams for:

• richer household and claimed-guest identity
• post-event guest experiences
• publishing-driven deep links
• automation-triggered guest flows
• finer guest surface availability metadata

Final Summary

The guest experience is now driven by one shared journey model and one backend bootstrap summary. Entry, navigation, next-step guidance, return continuity, and deep-link fallback are all occasion-first and capability-aware.