4 · Support & onboarding

TL;DR

Objective — make the path to value short and the path to help obvious, because a customer who can sign up but can’t get help — or can’t reach first value — churns.

Steps at a glance:

1. Build the support surface — A help page or FAQ, a working contact form, an in-app help icon, and a bug-reporting path — all reachable before launch.
2. Design time to first value — Design a five-minute first-run: signup → a brief welcome with a skip option → a guided first action (a pre-filled sample) → next steps (invite a teammate, create real data).
3. Instrument activation tracking — Instrument the funnel (verified → reached onboarding → created first item → marked onboarded → day-7 retention) so you can see where new users drop off and fix the worst step first.
4. Prepare the Phase 12 launch-day runbook — The signoff (page 2) clears you to enter Phase 12; this page prepares the owner list, rollback trigger, watch cadence, and T-minus checklist that Phase 12 will execute.

User part + done-when

🔀 User part — 👤 design judgment is human-owned: shaping the five-minute first-run experience and choosing what “first value” means are product calls. 🤖 The agent builds the support surface, instruments the funnel, and drafts the launch-day runbook once the shape is decided.

Done when the support surface is reachable, a five-minute time-to-first-value flow exists, the activation funnel is instrumented end to end, and the Phase 12 launch-day runbook is written with owners and triggers.  ·  ⏱ ~varies  ·  🔀 mixed (👤 UX design, 🤖 instrumentation).

Background

A customer who can sign up but can’t get help — or can’t reach first value — churns. Make the path to value short and the path to help obvious before launch.

Steps

1. Build the support surface

A help page or FAQ, a working contact form, an in-app help icon, and a bug-reporting path — all reachable before launch.

1. Wire the help page, contact form, help icon, and bug-reporting path.

   • ✅ Every support entry point is reachable before launch.

2. Design time to first value

Design a five-minute first-run: signup → a brief welcome with a skip option → a guided first action (a pre-filled sample) → next steps (invite a teammate, create real data).

Who does this

👤 User designs the first-run experience — deciding what the guided first action and “next steps” are is a product call only a person makes.

1. Build the five-minute first-run flow from signup through the guided first action to next steps.

   • ✅ A new user reaches a meaningful first action within roughly five minutes, with a skip option on the welcome.

3. Instrument activation tracking

Instrument the funnel (verified → reached onboarding → created first item → marked onboarded → day-7 retention) so you can see where new users drop off and fix the worst step first.

1. Track each funnel stage so drop-off is visible by step.

   • ✅ The funnel reports verified, reached-onboarding, first-item, onboarded, and day-7 retention so the worst step is fixable first.

2. Hold each funnel stage to a numeric target and diagnose the worst gap. Track these daily for the first seven days — a stage well below target tells you exactly which step to fix.

   Stage	Target
   Signups	baseline
   Email verified	> 85%
   Reached onboarding	> 82%
   Created sample item	> 60%
   Marked onboarded	> 45%
   Day-7 retention	> 30%
   Upgrade rate	> 5%

   Reading the drop-off:

   • Many verify but few create their first item (e.g. 85% → 60%) → the first-run flow is unclear; simplify it.

   • Many create but few are active on day 7 (e.g. 60% → 20%) → the core value is unclear; improve the core feature, not the funnel.

   • ✅ Each stage is measured against its target, and the lowest-performing step has a named fix queued.

4. Prepare the Phase 12 launch-day runbook

The signoff (page 2) clears you to enter Phase 12; Phase 12 performs the production deploy, production-only rechecks, live-payment gate, registration opening, and post-launch watch. This page prepares the runbook so the production phase is not improvised. Keep the rollback command documented before Phase 12 opens registration — you do not want to be looking it up while payments are failing.

Who does this

🔀 User + Agent — 🤖 the agent drafts the checklist, owner table, rollback trigger, and monitoring cadence from Zaj-PROJECT.md; 👤 the user owns every continue/rollback/go-live decision in Phase 12.

1. Draft the T-minus checklist without executing production changes. The runbook must name where each action happens and which Phase 12 page executes it.

   Moment	Prepared item	Phase 12 owner
   T-24h	Final technical checklist rerun, production seed-surface sweep, backup proof, production test/demo cleanup plan	Phase 12 preflight
   T-1h	Error-tracking check, uptime green, rollback command reviewed with --plan	Phase 12 release/deploy
   T-0	Open registration, enable paid channels, watch first signup/payment	Phase 12 harden/verify/sync
   T+24h	Error review, early feedback, performance, backup proof	Phase 12 monitor

   • ✅ Each T-minus item points to a Phase 12 page and has an owner; no production mutation is executed in Phase 11.

2. Record the rollback command and trigger. Review the command shape now; the real rollback decision and execution stay in Phase 12.

   # Dry-run the rollback so it is rehearsed, not improvised
   dep rollback production --plan   # e.g. dep rollback production after plan review

   • ✅ Rollback command, rollback trigger, and decision owner are written into the runbook.

3. Write down owners before Phase 12. Launch owner, support owner, rollback trigger, and the first 24-hour monitoring schedule must be explicit — not implied.

   • ✅ Launch owner, support owner, rollback trigger, and first 24-hour monitoring schedule are written down before traffic starts.

Post-launch monitoring cadence

Period	Frequency	Watch
First 24 hours	every 5 min	errors, health endpoint, payments
After 24 hours	hourly	error rate, payments, server resources
After 1 week	daily	overnight errors, payment volume
After 1 month	routine	normal monitoring

If issues appear during launch — decision tree

Symptom	Decision
Users can still browse (degraded, non-critical)	Continue with warnings; fix forward
Users cannot log in	Consider rollback — assess blast radius first
Payments are broken	Immediate rollback: dep rollback production

Rollback only un-does deploy-related breakage

A rollback reverts code, not data. If the failure is a config, DNS, or third-party outage, rolling back will not help — diagnose the layer first. Per destructive-ops discipline, confirm a current backup exists before any rollback that could touch migrations.

What’s next

Phase 11 is the last pre-customer readiness gate. Once signoff passes, run Phase 12 · Deploy to production when you’re ready to go live. For every subsequent release, return to that same production checklist, and watch error tracking, uptime, and analytics closely for the first seven days. If a critical issue appears, follow the incident runbook and roll back if it is deploy-related.

Plan customer acquisition before you flip the switch

Launching the app and getting customers are different jobs — don’t let a quiet launch surprise you. Line up distribution before (or at) launch: a launch-day post (Product Hunt / your audience’s channels), direct outreach to your ideal first users, any paid channel you’ll run (Google Ads), and a referral hook. Track signups per channel so you double down on what works. Growth tactics live in Phase 9 · Growth & polish and the ongoing Continuous deploy loop.

Checklist

Do not mark this step done until every box below is checked.

• 🤖 Support surface live — help/FAQ, contact form, in-app help icon, and bug-reporting path all reachable.
• 👤 Time to first value — a five-minute first-run flow exists with a guided first action.
• 🤖 Activation tracking — the funnel is instrumented from verified through day-7 retention.
• 🔀 Phase 12 launch-day runbook ready — T-minus checklist, rollback command, rollback trigger, launch owner, support owner, and watch cadence are documented; no production mutation was executed in Phase 11.

→Next step

Launch signoff — final go/no-go