Guest Checkout Policy

This is a core, non-negotiable rule of the platform: no public purchase flow may ever require creating an account or signing in before paying. Pick a room, pick a time, enter contact info, pay, done. No exceptions.

Why

Forcing account creation or sign-in before payment adds friction that loses customers. This is a guest-checkout-first system — account creation is opt-in and comes after the sale, never a gate in front of it.

How it actually works

1. A guest completes a purchase using just their name, email, and phone — no Clerk account involved at all. This creates or updates a real Customer record, matched by email.
2. After a successful payment, the system sends an email inviting the customer to optionally create a portal account.
3. If they do, that new account links to their existing Customer record — matched by email — rather than creating a duplicate. Same "one customer record" principle that runs through the rest of the CRM.

This applies to every public flow: meeting-room booking, day passes, registered/virtual office signup, and the guided office-inquiry funnel.

What this means for anyone changing these flows

• Never add a sign-up or sign-in step in front of payment on a public flow, even temporarily, even for "just this one edge case."
• The post-payment account nudge should fire from every purchase path, guarded by if (!customer.clerkUserId) — a customer who already has an account shouldn't be nudged to make another one.
• If you're building a new public purchase flow, this rule applies to it by default. Treat any deviation as something to raise explicitly, not something to assume is fine because "it's just this once."

Where this is implemented

Every public checkout page (/book, /day-pass, /registered-office, the guided office-inquiry funnel) follows this pattern. The account-nudge email fires from the same point in each product's purchase-completion logic, immediately after the real charge succeeds.