# Onboarding Help Page: https://alidemirbas.com.tr/en/lab/journeys/struggling-user-assistance User gets stuck → offer help → escalate if needed → continue or exit ## Purpose Help users who struggle during onboarding before the friction turns into abandonment. Goal: Relationship Recovery & Intervention · Category: Activation & Usage ## Steps - **Trigger**: Onboarding struggle signal detected - **Action**: In-app: Show help for the step where the user is stuck - A short tip, step guide or FAQ matched to the detected friction: form entry, technical error, guidance or an unclear step. - **Wait**: Wait about 1 day - **Decision**: Was the onboarding step completed? - Yes: Onboarding step completed - No: Push: Continue where you left off - **Action**: Push: Continue where you left off - **Wait**: Wait 2 days - **Decision**: Did they return or complete the step? - Yes: Onboarding step completed - No: Email: More complete help + live-support option - **Action**: Email: More complete help + live-support option - **Wait**: Wait 3–5 days - **Decision**: Onboarding completed? - Yes: Onboarding step completed - No: Stop onboarding help - **Exit**: Onboarding step completed - **Exit**: Stop onboarding help ## Guardrails - Do not restart onboarding steps that are already complete. - End the journey as soon as the user progresses successfully. ## Core rule Start with the lightest useful help. Escalate only if the user still cannot move forward. ## When to set it up Onboarding help is worth building when the funnel report shows users stalling at a particular step, hitting the same validation error repeatedly or taking far longer than expected, and then not coming back. Before launch, define the struggle signal per step, confirm that step completion, in-app message display and push and email permissions are tied to the same user, and map in advance which step gets which kind of help (tip, guide or FAQ). If the error logs show a technical fault at that same step, fix the fault first; a help message is no substitute for an unresolved product error. ## How to set it up - **Trigger and entry**: The struggle signal you defined (a stalled step, a repeated error, an unusually long time) opens the journey when it appears during onboarding. Randomly assign the user at that point to the journey group or to a control group that receives no help messages from this flow; one slow session is not a signal. - **Who must not enter**: The stuck step sets the scope, and no second flow opens for the same step. Users who have already completed that step or finished onboarding stay out, no message restarts a completed step, and help is tied only to the task the user is attempting right now. - **Timing and channels**: Short in-app help for the stuck step comes first. If the step is not completed after about 1 day, a push follows; if 2 days later there is neither a return nor a completion, an email with fuller help and a live-support option goes out. Step status is checked before each touch. - **Exit and handoff**: The journey ends, and remaining messages are cancelled, when the step is completed or when the user returns to the app at the second check. If onboarding is still not complete 3 to 5 days after the email, help stops. There is no handoff; the flow closes in its own two exits. - **Frequency and consent**: One struggle gets at most three touches: in-app, push and email. Push and email are used only where that channel's permission exists; in-app help shows only while the user is in the app. Pick the help content by the type of friction detected rather than reusing one text for every step. ## How to measure success **Incremental step completion vs control**: Some stuck users get through on their own; the journey's value is how many more of the helped group complete the step than the control group that got no help, not in-app impressions or clicks. All users assigned at the struggle signal to the journey or control group form the denominator; the numerator is those who complete the onboarding step they were stuck on within the same follow-up window from assignment. Whether a message was shown, delivered or clicked does not change the denominator. Also track: - **Return-to-app rate**: Among assigned users, the share who come back to the app; track returning separately from completion, because a user who returns and gets stuck again is telling you the help was not enough. - **Contribution by escalation step**: Read completions after the in-app help, the push and the email separately; if the email tier adds no completions, try capping the escalation at two touches. - **Result by friction type**: Read the form entry, technical error, guidance need and unclear step groups separately; no gap in the technical error group means the problem is on the product side. - **Live-support requests and permission loss**: Watch who asks for live support after the email, who turns push off and who unsubscribes from email; a rise in support requests says the help content falls short. ## What to watch when reading the result - Equal step completion in both groups means the help was shown to users who would have moved on anyway; seeing the in-app help or tapping the push does not change that. Rising returns without rising completions do not make the journey a success. - Whatever gap you get holds for this escalation order (in-app, push, email), these waits and the struggle signal definition you chose. With no handoff, a step completion is credited to this struggle alone, and the same user getting stuck at a later step is a new entry. - If the gap is small, put each group's user count and step completions into the [A/B test significance calculator](https://alidemirbas.com.tr/en/calculators/ab-test); if it is not significant, extend the follow-up window to cover at least the final wait and rerun the read before you narrow the struggle signal. - A gap near zero in the technical error type means the help text cannot paper over a product fault; fix the fault instead of adding messages, and pause entries for that step while you do. ## Frequently Asked Questions ### How can I identify users struggling with onboarding? Look for a stalled step, repeated validation errors or unusually slow progress. Define the signal before implementation. One slow session does not prove a problem. Tie help to the task the user is attempting. ### Which channel should onboarding help use first? Start with brief contextual in-app help. In this example, lack of progress leads to push after about a day and more detailed email support two days later. Explain the obstacle rather than merely asking the person to return. ### When should onboarding assistance stop? Stop help for a step once it is completed. If progress does not resume, this example ends after its final follow-up. Track returning separately from completion. Messaging cannot substitute for fixing a product error.