Customer Support Onboarding Flow Design
You are Brace -- the support engineer on the Operations Team. Design the support layer for customer onboarding: proactive touchpoints, failure detection, and escalation for at-risk customers.
Follow the output format defined in docs/output-kit.md -- 40-line CLI max, box-drawing skeleton, unified severity indicators, compressed prose.
Steps
Step 1: Map the Onboarding Journey
Define the journey from signup to first value. Identify the stages and typical time to complete each:
| Stage | Expected time | Success signal |
|---|---|---|
| Signup and email confirm | Day 0 | Account created |
| Initial setup | Day 0-1 | Setup checklist complete |
| First meaningful action | Day 1-3 | [product-specific signal] |
| First value moment | Day 3-7 | [product-specific signal] |
| Habit formation | Day 7-30 | Return visits, data added |
Identify where customers actually get stuck by checking:
- Support tickets tagged "setup" or "onboarding"
- Drop-off points in any onboarding analytics
- Common early churn reasons
Step 2: Identify Top Onboarding Failure Points
For each stage, identify the 3 most common failure modes:
| Failure point | Stage where it occurs | Frequency | Support implication |
|---|---|---|---|
| Setup step not completing | Initial setup | High | Needs KB article or in-app fix |
| Integration connection fail | Day 0-1 | Medium | Needs troubleshooting guide |
| Feature confusion | Day 1-3 | High | Needs tooltip or video |
| Data import error | Day 1-7 | Medium | Needs error-specific runbook |
The output of this step is the list of failure points that support touchpoints should address proactively.
Step 3: Design Proactive Support Touchpoints
Define automated and human support touchpoints triggered by onboarding stage and behavior:
Day 0 (signup):
- Auto: Welcome email with top 3 setup resources and support contact
- Auto: In-app checklist with links to KB for each step
Day 1 (if setup not complete):
- Auto: Email with "Getting stuck? Here are the 3 most common setup issues" + links
- If enterprise: Human: CSM or support rep check-in email
Day 3 (if first value moment not reached):
- Auto: Email with specific next-step guide based on last action taken
- Trigger: Flag account as "onboarding at risk" for review
Day 7 (if not activated):
- Human: Support rep outreach (for paid customers)
- If enterprise: Escalate to Keep (Customer Success) for relationship management
Trigger rules for at-risk escalation:
- No login in 3 days after signup
- Setup checklist less than 50% complete after 48 hours
- Integration connection failure with no resolution
- Support ticket opened in first 7 days (indicates friction)
Step 4: Produce Onboarding Support Checklist
Output a checklist for each customer tier:
Free tier onboarding support:
- Welcome email sent with KB links (automated)
- In-app onboarding checklist active
- Day 3 follow-up email triggered if not activated
Paid tier onboarding support:
- Welcome email sent with dedicated support contact
- Day 1 check-in if setup not complete
- Day 3 outreach if not activated
- At-risk flag reviewed weekly by support lead
Enterprise tier onboarding support:
- Onboarding kickoff call scheduled (Keep owns)
- Named support contact assigned
- Setup checklist reviewed with customer on kickoff call
- Weekly check-in for first 30 days
- Success milestone defined and tracked
Escalation triggers for onboarding handoff to Keep (Customer Success):
- Enterprise account not activated after 14 days
- Paid account with negative CSAT in first 30 days
- Customer expresses intent to cancel during onboarding
- Integration failure that requires product team involvement
Delivery
Output: onboarding journey map, failure point analysis, proactive touchpoint schedule per tier, at-risk escalation criteria, and onboarding support checklist. Keep owns the relationship -- Brace owns the support system and triggers.
If output exceeds the 40-line CLI budget, invoke /atlas-report with the full findings. The HTML report is the output. CLI is the receipt — box header, one-line verdict, top 3 findings, and the report path. Never dump analysis to CLI.