Complete PostHog funnel and session replay for online scheduler

Objective

• Give support and client care a reliable way to verify what a customer actually did in the public online scheduler when they report a failed or unexpected booking — without relying on memory or external tools alone.
• Stand up a PostHog funnel aligned to the real scheduler steps, enable full session replay for public scheduler sessions, and identify the PostHog person once the user enters contact information so replays and events can be correlated.
• Use PostHog as the troubleshooting surface (not an in-product audit log), per product direction from Chris.

Background

• Jun 17, 2026 catch-up: when agents or customers say the scheduler failed or they followed a certain path, there is no reliable way to confirm the actual steps taken.
• Chris proposed handling this in PostHog: create an online scheduler funnel, track key step events, enable session replay for the scheduler, and call identify once the person enters their information.
• PostHog is already integrated in the frontend (ATT-1747 Done): src/instrumentation-client.ts initializes the client in production via /ingest, with PII scrubbing in src/util/posthog/sharedConfig.ts.
• Partial scheduler instrumentation already exists but does not fully match the five-step flow or support replay lookup:
• Events today: scheduler_service_selected (ServiceConfirmation.tsx), scheduler_slot_selected (SlotsStep.tsx), scheduler_job_booked / scheduler_booking_failed (BookingJobLoader.tsx), scheduler_quote_sent (SendQuoteLoader.tsx).
• SchedulerContext.tsx calls posthog.identify(contactId, …) and registers scheduler_contact_id when a contact record exists.
• SchedulerRunProvider sets scheduler_run_id on both public /scheduler and internal /tools/schedule.
• A Scheduler Booking Funnel insight was created during PostHog setup (posthog-setup-report.md) but covers only service → slot → booked — not property, contact, summary, quote, or failure paths.
• The public online scheduler is a five-step flow in src/app/scheduler/page.tsx: Services → Property → Schedule (slots) → Contact → Summary (SchedulerContent.tsx). Contact identification currently happens when the contact object is set (step 4), after slot selection (step 3).

Product Decisions

Locked

1. Troubleshooting surface — Use PostHog (funnel + session replay), not an in-product scheduler audit log.
2. Primary use case — Support and client care investigating online scheduler complaints (user path + session behavior).
3. User identity — Call PostHog identify when the user enters contact information in the scheduler flow (extend/refine existing SchedulerContext behavior as needed).
4. Surface scope — Public online /scheduler only. Internal CSR scheduling at /tools/schedule is out of scope for this work.
5. Event coverage — The more information the better for support troubleshooting. Instrument all five scheduler steps plus both completion paths (book job and send quote), failures, and other high-signal events (e.g. session started, step completed, property confirmed, contact submitted, booking failed). Dev should prefer comprehensive step-level events over a minimal three-event funnel.
6. Session replay — Full (100%) session replay for public /scheduler sessions — not sampled.
7. Support lookup workflow — Primary support workflow is filtering PostHog replays/events by company + time range (easiest path today). Document this in a brief runbook; scheduler_run_id and contact id remain useful secondary filters when known.
8. PII in replays — Dev discretion: choose PostHog masking/block selectors vs visible contact fields in replay based on tradeoffs; consult Chris or Ryan before finalizing if unclear.

Open

1. Identify timing — Identify on first contact field entry, on step 4 completion, or when contact record is created/saved (current: when contact._id exists in context)?
2. PostHog project config — Who owns creating/updating the funnel insight and replay filters in the PostHog UI after events ship (eng vs product/ops)?

Scope

Frontend

• In scope: public scheduler only — src/app/scheduler/ (layout wraps SchedulerRunProvider; main flow in SchedulerContent.tsx, steps 1–5).
• Out of scope: internal CSR scheduler at src/app/tools/schedule/ — do not add or extend scheduler analytics events there for this ticket.
• Existing PostHog touchpoints to extend or align:
• src/app/scheduler/SchedulerContext.tsx — company group, contact identify, scheduler_contact_id register.
• src/components/scheduling/SchedulerRunProvider.tsx — scheduler_run_id per tab session (continue on public scheduler).
• Step-level captures in ServiceConfirmation.tsx, SlotsStep.tsx, BookingJobLoader.tsx, SendQuoteLoader.tsx.
• Gaps to address:
• Property and contact step events and step-order alignment with the real five-step UI flow.
• Comprehensive event coverage across book, quote, and failure paths (locked decision #5).
• Full session replay activation scoped to public /scheduler routes (no scheduler-specific replay config in instrumentation-client.ts today).
• Consistent event properties: company_id, scheduler_run_id, step name/order, surface=scheduler (or equivalent) for PostHog filtering.

PostHog configuration (outside repo)

• Create or update funnel(s) to match the full five-step flow and both book/quote outcomes.
• Configure 100% session replay for public scheduler URL/surface filters.
• Document support lookup: filter by company + time range in PostHog (locked decision #7).

Backend

• No backend API required for v1 — scheduler telemetry remains client-side PostHog.

Out of scope (v1)

• Internal CSR /tools/schedule analytics.
• In-product scheduler audit/history UI.
• PostHog instrumentation for client report page (ATT-1748).
• Mobile scheduler.

Done when

• [ ] PostHog events cover the full public scheduler path — all five steps plus book, quote, and failure outcomes.
• [ ] 100% session replay is enabled for public /scheduler sessions.
• [ ] Support can find a relevant replay/session using company + time range (documented in runbook).
• [ ] PostHog identifies the user once contact information is entered.
• [ ] Event properties include company_id, scheduler_run_id, and step context for filtering.
• [ ] PII/masking approach for replays decided (dev consults Chris/Ryan if needed).

References

• PostHog init: attik-frontend/src/instrumentation-client.ts
• PII scrubbing: attik-frontend/src/util/posthog/sharedConfig.ts
• Scheduler context / identify: attik-frontend/src/app/scheduler/SchedulerContext.tsx
• Run id: attik-frontend/src/components/scheduling/SchedulerRunProvider.tsx
• Scheduler steps: attik-frontend/src/app/scheduler/page.tsx, SchedulerContent.tsx
• Existing setup notes: attik-frontend/posthog-setup-report.md
• Platform setup (Done): ATT-1747
• Related report analytics: ATT-1748