Customer Sites and Portal

The sites app is the customer-facing side of Sophosic. It serves public pages, conversion flows, and authenticated self-service for each workspace.

Public Site Routing

In production, a workspace is usually reached through a custom domain or a Sophosic shop subdomain. In local development, a site is usually reached through a path:

/{site-slug}
/{site-slug}/shop
/{site-slug}/bookings

The site slug resolves the tenant. All public rendering, checkout, booking, and portal actions must stay scoped to that tenant.

Public Pages

Customers can visit:

• Homepage.
• Custom pages.
• Policies.
• Contact.
• Stories.
• Help.
• Knowledge articles.
• Forms.
• Shop.
• Bookings.

The page shell uses workspace branding, navigation, footer, theme, and legal links configured in the console.

Public pages should always answer two questions quickly: what the business offers and what the customer can do next. If a page looks correct but customers still hesitate, review the page’s primary action, policy links, service-area language, and whether the content matches the products or services configured in console.

Shop Experience

The shop supports:

• Product browsing.
• Filters.
• Product detail pages.
• Modifiers and variants.
• Cart.
• Checkout.
• Coupons.
• Wallets when available.
• Return and success pages.
• Saved items.
• Back-in-stock or reorder flows when enabled.

If checkout is unavailable, verify that products are purchasable, inventory is available, Stripe is connected, shipping/tax rules are complete, and site status allows commerce.

Booking Experience

The booking flow supports:

• Service list.
• Service detail.
• Tier selection.
• Date and time selection.
• Staff selection when configured.
• Add-ons.
• Waivers.
• Deposits.
• Confirmation.
• Pay links.
• Manage and reschedule pages.

If no times are visible, inspect availability and calendar sync in the console before changing public-site code.

Customer Portal

Authenticated customers can manage:

• Account overview.
• Profile.
• Notifications.
• Orders.
• Billing and subscriptions.
• Tickets.
• Saved items.
• Booking history.
• Reschedule flows.

Portal paths must require a valid customer session. Public links such as booking manage or pay links may use scoped tokens and should never expose unnecessary customer data.

Help And Support

Customers can self-serve through help trees and articles. If they need a human, they can create support tickets or submit forms. Operators should triage those items through Inbox, Customers, and related console views.

Help content should reduce repeated support work, not hide the team. Keep high-volume questions current, route forms to an owned console surface, and verify that customers receive a clear confirmation when they ask for help.

Search And Sharing

Sites exposes routes for sitemap, robots, Open Graph image, llms.txt, IndexNow, and canonical metadata. Discovery settings in the console should be checked when pages are missing from search or previews look wrong.

Use search and sharing checks after any change to titles, descriptions, hero media, domains, redirects, or important content paths. A page can load correctly for customers while still showing stale metadata to search engines or social previews.

Verification Pass

Before launch, test as a customer:

1. Browse public pages.
2. Search content.
3. Submit a form.
4. Add product to cart.
5. Reach checkout.
6. Book a service.
7. Pay a deposit or final balance if enabled.
8. Sign in to the portal.
9. View orders, bookings, billing, tickets, profile, and notifications.

Use this matrix to make the pass reproducible:

Record the final URL, test customer, tested action, and resulting console record. That evidence makes future support triage faster than relying on “it worked during launch.”