Customer Portal

The customer portal is the authenticated self-service surface for each workspace. Customers use it to review orders, billing, bookings, tickets, profile details, notification preferences, and saved items.

Portal routes live under the workspace site route and require a valid customer session. Operators should treat the console as the source of truth and the portal as the customer-facing view of that data.

Route Map

Public booking manage links may also send customers to /{site}/bookings/manage/{bookingId} and /{site}/bookings/manage/{bookingId}/reschedule. Those links use scoped booking access and should expose only the booking action the link was created for.

Auth And Scope

Portal pages must stay scoped to the active site and the signed-in customer.

Operational expectations:

• Customers without a valid session are sent through the portal sign-in flow.
• The next destination should bring the customer back to the page they requested.
• Orders, bookings, invoices, subscriptions, tickets, profile data, and saved items must belong to the current customer.
• Operators should verify the workspace slug before troubleshooting missing records.
• Public magic links should not reveal unrelated customer data.

If a customer sees no data after signing in, check the customer record, email match, guest claim state, workspace slug, and whether the order, booking, invoice, or ticket is actually linked to that customer.

Orders

The orders routes let customers review product purchases and fulfillment progress.

Customers should be able to see:

• Order history.
• Order detail.
• Payment state.
• Fulfillment state.
• Shipping address when relevant.
• Tracking when available.
• Product and total summary.

Operators should reconcile missing or wrong orders from Sales and the customer record before changing the portal. Common causes are guest checkout ownership, payment webhook delay, customer merge issues, or viewing the wrong workspace.

Billing, Invoices, And Subscriptions

Billing is the customer’s money-management surface. It should reflect the same invoice and subscription state that operators see in the console and payment provider.

Use billing routes for:

• Billing summary at /{site}/billing.
• Invoice review at /{site}/billing/invoices.
• Subscription review at /{site}/billing/subscriptions.
• Available invoice payment, download, or detail actions when configured.
• Available subscription cancellation or management actions when policy allows.

Before launch, verify that paid products, booking deposits, final booking payments, hosted invoices, and subscriptions all land in the correct customer history.

Bookings And Reschedule

The booking portal routes let customers see their service history and manage upcoming appointments.

Customers should be able to:

• Review upcoming and past bookings.
• Open a booking detail page.
• See service, time, location, staff, add-ons, and payment state when available.
• Pay a deposit or final balance when that action is available.
• Reschedule only when the booking is upcoming and policy allows it.

The authenticated reschedule route is:

/{site}/account/my-bookings/{id}/reschedule

Reschedule depends on availability, service duration, buffers, staff, overrides, existing bookings, and calendar sync. If no times appear, inspect Scheduling before editing the portal.

Profile

The profile route is the customer-owned view of identity details.

Use it to verify:

• Name.
• Email.
• Phone.
• Address or other profile fields when configured.
• Customer record linkage.

Profile changes should update the customer record without breaking order, booking, ticket, or billing history.

Notification Preferences

Notification preferences live at:

/{site}/profile/notifications

Customers use this page to adjust communication preferences for workspace messages. Operators should verify that preference state is honored by booking lifecycle messages, ticket updates, account messages, marketing email, and other configured notification categories.

Preference controls do not replace legally required operational messages. If a customer reports unexpected email, check the notification trigger, template, sender identity, consent state, and whether the message is transactional or optional.

Tickets

Tickets let authenticated customers ask for help and continue a thread.

Portal ticket routes support:

• Ticket list at /{site}/tickets.
• Ticket creation at /{site}/tickets/new.
• Ticket detail and replies at /{site}/tickets/{id}.

Operators should handle ticket work from Inbox, Tickets, and the customer record. A reply should be understandable from both sides: the operator sees customer context, and the customer sees the current thread without internal-only notes.

Saved Items

Saved items live at:

/{site}/account/saved

Customers use saved items to return to products or offers they want to revisit. Operators should verify saved items still point to public, purchasable, workspace-scoped products. If a saved product is archived, out of stock, or unpublished, the portal should not make a false purchase promise.

Operator Launch Checks

1. Sign in as an internal test customer.
2. Confirm the portal opens under the intended /{site} route.
3. Verify orders and order detail are scoped to that customer.
4. Verify billing, invoices, and subscriptions match the console.
5. Verify booking history, booking detail, and reschedule behavior.
6. Update profile fields and confirm the customer record stays linked.
7. Change notification preferences and confirm the saved state.
8. Create a ticket, reply as an operator, and confirm the customer sees the reply.
9. Save a product and confirm it appears under saved items.
10. Confirm no route exposes another customer’s records.