Onboarding drop-off reminder

Reminds students who stall during onboarding to come back and finish. A user is considered stalled when they have remained on the same onboarding step for 24 hours or longer without completing it. A first reminder sends at 24h, and a single follow-up sends if they are still stalled 7 days later. If the user completes the step before the reminder sends, the send is suppressed.

Attribute
Channels	email, push
User types	students
Regions	NA
Platforms	web, iOS, Android
Product area	Onboarding
Notification preference	general_communications
Notification config	v1/onboarding_drop_off_reminder.yml

Audience

Students who started onboarding but have been stuck on the same step for 24+ hours. Initial launch targets unaffiliated users only (affiliated users already receive the Iterable welcome series, which would overlap). Email goes to everyone who completed the first onboarding step (signup/confirmed email); push goes only to users who opted into push during onboarding.

Reminder-eligible steps (per the Onboarding 2026 PRD):

Step	Reminder trigger	Completion event	Priority
Phone verification	Sign up complete	Phone verified	P0 — launch first
Job interest questions	Phone verified	All 4 questions answered	P1
Resume upload	—	Uploaded or explicitly skipped	No standalone reminder; folded into profile setup email
Profile setup	Resume step resolved	Onboarding marked complete	P1

Trigger

Time-based, not event-based: a scheduled job (see NTF-4954 for the trigger implementation) scans for users stalled ≥24h (or ≥7d for the follow-up) on a step and requests sends via NSS with attributes onboarding_step and reminder_number (1 = 24h touch, 2 = 7d follow-up).

Guardrails:

• time_window_limits on both channels: max 1/day and max 2 per 2 weeks per user — this is the hard cap answering the PRD's "how many reminders per week" question.
• Send-time suppression in the monolith templates: the mailer raises SkipSendError and the push template implements should_skip_send? if the user completed the step (or all of onboarding) between enqueue and render.

How to test

Command line

curl -s \
-H 'Content-Type: application/json' \
-H "Authorization: Bearer apitoken" \
-X POST \
-d '{ "notification_name": "onboarding_drop_off_reminder", "notification_version": "1", "user_id": 125, "attributes": { "onboarding_step": "phone_verification", "reminder_number": 1 } }' \
localhost:5550/v1/notifications

E2E

Create a student account on staging, complete signup but stop before verifying your phone number, and wait for the scheduled trigger (or run it manually). You should receive the reminder email; completing the step before the trigger runs should suppress it.

Additional info

Implementation

Copy per step is TBD pending design (Lifecycle emails H2 2026 Figma) — the onboarding_step attribute is required regardless, because send-time suppression must know which step to re-check, and the CTA deep-links back into the flow. If copy ends up generic, templates simply ignore the attribute for copy purposes.

Aliases

onboarding reminder, drop-off notification, stalled onboarding email, complete your onboarding email, almost there email

Resources

• Linear project: Onboarding funnel drop-off notification (NTF-4950 – NTF-4956)
• PRD: Onboarding 2026 — drop-off reminder tab
• Design: Lifecycle emails H2 2026 Figma