Back To Member Concierge

Privacy

Trust, kept visible.

This is the current implementation baseline for the Domain8 Member Concierge walkthrough. It explains what the shared desk stores today, what stays route-attached at the handoff, what still does not count as direct member-data intake, and why the broader public privacy-owner gap remains a site-level launch blocker.

Current build status

Search persistence may be enabled on the server through Supabase.
Member Concierge walkthroughs now use the shared Domain8 desk with /member-concierge attached and workflow-pilot context already selected.
This remains a bounded preview: no direct member-data intake, member login, member vault, or credential handoff is being claimed here.
Optional analytics, pixels, and profiling are controlled by the privacy choices layer and stay off in essential-only mode.

Policy Scope

Keep the collection story honest and narrowly described.

This page is written to describe the current member-review path, not a hypothetical member platform. If the shared desk later expands into direct member-data intake, new storage behavior, or tracking, the policy needs to move with that reality.

01

What this review path collects

Only the narrow handoff details needed to review the member-lifecycle break

The shared desk collects first name, last name, email, message body, human verification status, optional phone, optional customer type and address, the attached route, request type, an optional quick-note seed, and optional discount or phone-follow-up preferences so an operator can review onboarding drift, digest gaps, answer-state confusion, or re-engagement friction.

02

What this route does not collect

Member Concierge still avoids direct member-data intake, member login, and credential drops

The public note is for the lifecycle break or access gap, not the secret itself. This route does not open a member vault, does not collect private member records directly, and does not ask for passwords, payment data, or hidden portal credentials.

03

Storage and processors

Contact requests may write to Supabase and notify handlers when email is configured

When the contact-request storage layer is available, the shared desk can write the note to Supabase on the server. When storage is unavailable, the desk returns a truthful pilot-mode receipt and queues manual follow-up instead of pretending the write succeeded. Search snapshots and queue-governance metadata may also use the same server-side Supabase setup.

04

Cookies and similar tech

Optional tracking stays behind the privacy choices layer

On Harper Relay, optional analytics, marketing pixels, and visitor profiling are controlled by the privacy choices layer. Essential-only mode keeps non-essential tracking off. The current route does not use session replay, keystroke logging, or automatic marketing retargeting by default.

Currently In Scope

the route-attached Member Concierge handoff at /contact?from=member-concierge with workflow-pilot context already selected
shared-desk submissions: first name, last name, email, message, human verification status, optional phone, customer type, company, address, route, request type, quick-note seed, and optional discount or phone-follow-up preference
a public note that stays high-level and asks for the lifecycle break or access gap instead of passwords, payment data, or private member records
route-aware privacy and about pages that keep the member-review story attached instead of dropping into a generic trust page
pilot-mode manual-follow-up receipts when contact storage is unavailable on the current run
domain-search queries and generated comparison snapshots elsewhere on the site
queue-governance metadata used for internal lane work

Still Not Live

direct member-data intake on the public Member Concierge route
a separate member login, member vault, or hidden credential-drop lane
a dedicated public privacy-request owner approved for broader site handling
session replay, keystroke logging, or advertising pixels that load before consent

Current Limitation

Privacy requests still need a dedicated public owner before launch.

This repo now exposes both the policy route and a public contact-routing page, but it still needs an operator-approved direct mailbox or verified privacy-request owner before the site can honestly call the trust path complete.