Implementation worksheet · 5 min read
A Returning-User Onboarding Resume Policy
Write an explicit resume policy with three time bands: under 48 hours, resume exactly where they left (same step, same data, one-line 'picking up where you left off'); 2-14 days, show a compressed recap then the next step (they've forgotten context, not intent); past 14 days, treat as effectively new — fresh entry point, prior data preserved but not presumed, and any dated checklist quietly reset. Onboarding state must persist server-side per account, never in local storage where a device switch resets everyone to zero.
Every onboarding funnel leaks users who intended to finish. The resume experience decides whether that leak refills or compounds — and most products have no policy at all, just whatever the state machine accidentally does.
Put it into practice
1. Persist progress server-side
Step index, entered data, dismissals — on the account. The user who starts on desktop and returns on mobile is the common case, not the edge case.
2. Define the three time bands
48h / 14d boundaries work for most products; adjust to your visit cadence. What matters is that behavior at each band is chosen, written, and tested — not emergent.
3. Resume with context, not just position
Band two's recap is one screen: 'you connected X, next is Y, it takes ~2 minutes'. Dropping someone at step 4 of 6 with no reminder of steps 1-3 resumes the confusion, not the progress.
4. Reset what staleness invalidated
OAuth tokens expire, invited teammates already joined, sample data aged out. The resume path revalidates prerequisites before dropping the user at their old step — resuming into a broken step is worse than restarting.
5. Cap the checklist's lifetime
Onboarding checklists older than the band-three boundary stop appearing. A 'complete your setup (2 of 7)' badge following a now-expert user around is the product refusing to notice they're activated.
Resume policy bands
Copy this structure into your review document and record your observed result for each row.
| Time since drop-off | Behavior | State shown | Notes |
|---|---|---|---|
| < 48 hours | resume in place | exact step + data | |
| 2–14 days | recap, then next step | compressed summary | |
| > 14 days | fresh entry | data kept, flow reset | |
| Any band | revalidate prereqs first | ||
| Activated users | suppress all onboarding UI | by value event, not step count |
A failure worth checking
The eternal checklist: onboarding completion measured by checklist steps instead of the value event, so a user who found value their own way is nagged forever about step 3. Suppress onboarding UI on the value event, whatever the checklist says — the checklist serves activation, not the other way round.
Common questions
Should returning users be emailed to resume?
Once, in band two, referencing the specific next step — 'finish connecting your data (2 min)' outperforms 'complete your setup'. Past band three, market the value, not the chore list.
What about users who abandoned three times?
Third abandonment at the same step is a product signal, not a persistence target: that step is broken or mis-ordered. Route those sessions to your session-replay tool and fix the step.
Basis and scope
This is a proposed implementation method using illustrative examples, not a measured benchmark or a customer case study. Prepared with AI assistance. Validate product-specific behavior against current documentation and your own test environment.