Advance the onboarding sequence on what the user actually did in the product, not on a fixed timer that ignores their progress
The typical onboarding series is a fixed-time drip: email one on signup, email two on day two, email three on day four, regardless of what the user has actually done. This produces the two failures that define bad onboarding. The user who completed setup in the first hour gets emails telling them to do things they already did, which reads as the product not paying attention. The user who is stuck on step one gets email two about step two, which assumes a progress they have not made and leaves them more lost. A timer knows the calendar; it does not know the user.
The fix is to gate the sequence on in-product behavior: each step advances when the user completes the prior step's action, not when a clock runs out. This requires the product events that signal completion to reach the messaging layer, and it requires detecting the absence of progress (the stuck user) as its own trigger, because a user who has not advanced needs help on the step they are on rather than the next step's email.
This recipe advances onboarding on what the user did, and intervenes when they did nothing.
An onboarding sequence that tracks the user's actual progress, lifting activation and completion over a fixed-time series. The metric is onboarding completion rate (or the activation milestone that predicts retention) against a fixed-time baseline, because the claim is that behavior-gating beats the timer. The lift concentrates where users vary widely in pace (most B2B products) and where the activation milestone genuinely predicts retention; for a product where everyone activates in one obvious step, gating adds little. The honest framing is that this recipe matches the onboarding to the user's pace, which helps both the fast user (who stops being told to do done things) and the slow one (who gets help on the step they are stuck on).
The second outcome is the stuck-user intervention: detecting the absence of progress and addressing it, which a timer-based series structurally cannot do.
A messaging layer that can trigger on product events rather than only on time, fed by reliable product activity instrumentation. Composable stacks suit this because the product events and the messaging consume a shared event stream. The capability that decides whether the recipe is even possible is the product instrumentation: gating onboarding on in-product actions requires those actions to be captured and to reach the messaging layer reliably, and a team without that instrumentation is really building event capture first and the gated sequence second.
Compare the tools on Martech Stack Builder
Marketing ops owns the step definitions, the action-to-message gating, and the stalled-user intervention. Product is critical here, because the in-product actions that define each step and the activation milestone that matters are product decisions, and the instrumentation to capture them is product work. Data engineering owns the product-event capture, the gating logic, and the stall detection. Analytics measures completion lift against the fixed-time baseline. The recipe ships in weeks where product instrumentation exists, and takes longer where it does not, because the gating depends entirely on reliable in-product event capture. The messaging side is simple; the event dependency is the gate.
Work in this order. Define steps as actions, advance on completion, catch the stall, and help on the step the user is actually on.
Timed message sequence covers steps 1 and 7, behavioral trigger steps 2 and 3, negative signal capture steps 4 and 5, and channel eligibility check step 6.
The first failure is telling users to do what they have done. A sequence that does not check completion sends step-two instructions to a user who finished step two an hour ago, which is the single most common onboarding annoyance and signals that the product is not watching. The completion gating is what stops it.
The second is missing the stall. Gating on completion handles the user who progresses, but the user who stops is the one most at risk, and a sequence that only fires on completion goes silent exactly when the stuck user needs help. Negative signal capture (detecting the absence of the expected action within a window) is what turns the stall into an intervention rather than a dropped user.
The third is assuming onboarding email is exempt from consent. Onboarding messaging sits in a gray zone between transactional and marketing, and treating all of it as transactional to bypass consent is a mistake in jurisdictions that draw the line tightly. The send-time eligibility check keeps the onboarding contact on the right side of the customer's permissions rather than assuming the onboarding label exempts it.
The Workshop works out with your team which of these matter for your stack right now, and what to do first: a 90-minute session with the people who own the decision.
The product instrumentation that makes gating possible, the action-to-step mapping, the stall detection that catches the stuck user, and the consent line that onboarding email still has to respect: those are the decisions that turn a fixed-time drip into an onboarding that tracks the user's real pace.
Did this recipe match your situation?Anonymous response. Sign up to leave a longer note tied to your account.
Recognize tenure and usage milestones with a touch that reads as personal rather than as a template with a date merged in
Warn the customer before the overage, the roaming charge, or the plan-mismatch cost lands on the bill, so the conversation is about what to do next rather than about why the bill is what it is
Recover the buy-online-pickup-in-store orders that the customer placed and never collected, with the cross-system identity and the in-store inventory signal that the recovery has to coordinate around