Implementation worksheet · 6 min read
An Onboarding Segment Eligibility Decision Table
Write eligibility as an ordered decision table rather than as independent rules per flow. Each row is a condition set, a flow, and a priority; the first matching row wins and evaluation stops. Then add the two things independent rules cannot give you — a guaranteed-exhaustive default row so every user gets something, and an overlap check proving no user can match two rows at the same priority. Independent per-flow rules feel simpler and produce the two failures that define this area: users matching nothing and seeing no onboarding at all, and users matching three flows and seeing whichever the code evaluated first.
Personalised onboarding starts with one flow and a condition. By the fourth flow, the conditions were written at different times by different people, they overlap in ways nobody mapped, and which flow a given user sees depends on evaluation order that was never a decision. The bug reports are unreproducible because they depend on a user's exact attribute combination.
Put it into practice
1. Put every flow in one ordered table
One table, read top to bottom, first match wins. This is the whole technique. Rules living next to their own flows cannot be reasoned about together, and 'which flow does this user get' becomes a question you answer by running the code.
2. Make the last row unconditional
A default flow that matches everyone. Without it some users match nothing, and 'nothing' usually renders as no onboarding rather than as an error — so the failure is silent and the affected users are exactly the ones whose attributes you did not anticipate.
3. Test for overlap at the same priority
Generate the attribute combinations and check no two rows at equal priority can both match. Where they can, one of them is wrong or they need distinct priorities. This is a script, not a review; overlap between four multi-condition rules is not something anyone spots by reading.
4. Use attributes available at the moment of evaluation
Onboarding runs seconds after signup, when company size, plan and role are often unknown. A rule keyed on an attribute populated later matches nobody at the time it is evaluated and matches later in testing, where you set the attribute first. Mark each attribute with when it becomes available.
5. Decide what happens when attributes change mid-flow
A user picks a role on step two that would have made them eligible for a different flow. Switching mid-flow is disorienting; ignoring it means the personalisation is decided before you know enough to personalise. Pick one and write it down — usually: finish this flow, apply the better match next time.
6. Log the matched row per user
Which row matched, and why. Without it every support conversation about onboarding starts with a reconstruction. With it, the answer is one lookup, and you can also count how many users land on the default row, which tells you whether your segments cover reality.
The eligibility decision table
Copy this structure into your review document and record your observed result for each row.
| Priority | Conditions | Flow | Attributes available at evaluation? |
|---|---|---|---|
| 1 | invited by an existing team member | team-join flow | yes |
| 2 | signed up from an integration listing | integration-first flow | yes |
| 3 | self-serve, role = developer | technical flow | only if asked at signup |
| 4 | self-serve, role = marketer | non-technical flow | only if asked at signup |
| 5 | self-serve, company size > 50 | team-setup flow | rarely at signup |
| 6 | (unconditional) | default flow | n/a |
| — | overlap check at equal priority | must be empty | n/a |
| — | % of users landing on the default | monitored | n/a |
A failure worth checking
The rule that matches nobody. A flow is built for enterprise signups, keyed on a company-size attribute that is enriched asynchronously and is null at the moment onboarding evaluates. In testing it works, because the test account was created earlier and enriched. In production it matches zero users and the flow quietly never runs — no error, no alert, and the team concludes enterprise onboarding is not converting. The availability column exists to catch this before launch.
Common questions
How many onboarding flows is too many?
The limit is maintenance, not technology. Every flow needs its own copy, its own testing and its own eligibility row, and each one added makes the overlap surface larger. Most products are better served by three well-maintained flows than eight that drift.
Should users be able to switch flows?
Offering a visible 'this is not what I need' escape is usually better than trying to detect a mismatch automatically. It is a cheap control, and the rate at which it is used is a direct measurement of how wrong your segmentation is.
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.