Personalizing Messages by Account Plan and Permission State

Plan tier and permission state are two facts every B2B SaaS company already has on file, updated automatically, for every account and every user. This piece argues those two facts, used together, produce more useful and more actionable messages than role-based segmentation or time-based drip sequences ever will.

Plan Tier and Permission State as Personalization Signals

Most B2B SaaS personalization starts with role or persona declared at signup, but declared data ages poorly (a user who said "marketer" at signup may be doing ops work six months later). The trouble is that declared data ages badly. A person who checked "marketer" in month one might be running ops work by month six, and nothing in the system ever notices the shift.

Plan tier and permission state don't have that problem. They aren't self-reported, they're structural: they live in the account database, they update the moment the account changes, and they're never stale timesmarble.com. One recent description of plan-based personalization called it the most structural form of UI personalization there is, not just a gatekeeping mechanism but a deliberate choice to keep users from seeing features they can't use or don't need yet timesmarble.com.

That's the core of the signal value here. The gap between what someone can do on their plan and what they're actually doing is sitting right there in data a team already collects, no new tracking plan required timesmarble.com. Permission state sharpens the picture further: inside a single plan, an admin, an editor, a viewer, and a billing owner all face a different set of next possible actions, even though they're technically on the same contract.

A message built around what someone can actually do right now is current fact. A message built around what someone in their role usually does is a population average, and averages miss individuals by definition. Plan plus permission is, put simply, the combination most likely to produce a message the recipient can act on immediately.

Distribution of Capability Across Plans and Roles in B2B SaaS Products

Vertically, by plan tier, which sets what the account paid for. Horizontally, by role and permission, which sets what this particular person inside that account is allowed to touch.

The first onboarding experience in most B2B products belongs to an admin, an IT lead, or some technical decision-maker, and their questions have almost nothing to do with feature walkthroughs. They want to know whether the thing integrates, whether it's secure, whether it's going to break something else. Four broad persona clusters tend to show up across these products, each with a distinct capability set: engineers and developers need API docs, test keys, integration configuration; ops and admin people need user management, SSO, audit logs, the billing portal.

Plan tier cuts straight across all of that. An admin on a free plan and an admin on an enterprise plan carry the same title but very different ceilings, and the role label alone hides that difference completely. ClickUp's approach is a good illustration of this in practice: customers configure their interface by workspace or Space, toggling features on and off (they call them ClickApps) based on workflow needs, and plan tier decides which of those toggles are even available. The personalization work is already happening at the UI level before any message ever gets sent timesmarble.com.

Which means role by itself is an incomplete address. "Admin" without plan context might mean someone who can configure SSO, or someone who absolutely cannot. An SSO setup message sent to a free-plan admin lands as noise, or worse than noise if it makes the product look like it's advertising features that were never on offer.

"Grounded in What a Person Can Actually Do" in Practice

Before any message goes out, ask whether the recipient can act on it right now, given their plan and their permissions. If acting on it requires an upgrade they haven't made or an admin privilege they don't hold, the message has no chance of changing behavior.

Three ways this goes wrong. An upgrade prompt lands on a user who's already on the plan that includes the feature, which just breeds confusion and chips away at trust. A feature discovery message reaches someone who lacks the permission to open that feature at all, a dead end by design. An expansion prompt goes to an end user instead of the billing owner, reaching someone who has no authority to act on it whatsoever.

The upside version looks different. Behavioral signals from inside a plan segment, say, which features growth-plan users actually open during their first week, are worth more than any persona document written without that data behind it. The real upgrade is letting that behavioral evidence, segmented by plan, decide what gets surfaced by default rather than guessing from a role label. Todoist's approach of pre-loading the experience with content matched to a person's role or job removes the burden of imagining how the product applies to their work, and that same logic carries straight into post-onboarding messaging.

A message grounded this way can say something specific: you have access to this, you haven't used it yet, and here's the one thing to try first. Not a laundry list of everything the product could theoretically do for them. And just as important as the send logic is the skip logic. When the evidence for actionability is thin, plan state is ambiguous, permissions are unclear, the feature's already been used, sending nothing is the correct move.

Plan and Permission Signals and the Denominator Problem in Feature Adoption Measurement

Most teams measure feature adoption against a denominator of "everyone who logged in this period." That number understates adoption among the cohort that actually matters and makes the overall adoption picture look worse than it is.

Benchmark data across 181 companies put the average core feature adoption rate at 24.5%, with a median of 16.5%, but those numbers only mean something once the denominator is the eligible cohort rather than the entire user base Userpilot benchmark report timesmarble.com. Consider the difference this makes diagnostically: if 180 out of 600 eligible users completed the adoption action in a month, that is a 30% rate, and the follow-up becomes specific and answerable. What happened to the other 420? Compare that to the vague version of the question, "why is adoption low across everyone," which nobody can actually act on.

First use isn't adoption, either. Opening a dashboard is exposure. Saving a report built from live data is real evidence of value received, and pairing first-use rate with repeat-use is what turns a shaky number into a durable one. Plan and permission state are exactly the filters that build a correct denominator: strip out users whose plan doesn't include the feature, strip out users whose permission level blocks it, strip out users who've already adopted since they're successes rather than targets. What's left is the same list that should receive a re-engagement message, because the eligible cohort and the send list are, functionally, one list.

How behavioral triggers rooted in plan state outperform time-based drips

Drip sequences run on a quiet assumption: time equals readiness. The calendar knows none of that.

Behavioral triggers rooted in plan state fire on evidence instead of a date. The move is to find the features where drop-off tends to happen right after activation, then build messages that fire when a user actually reaches that friction point, driven by adoption signals rather than a fixed schedule.

A developer analytics platform noticed that users who checked error logs more than three times were strong candidates for the premium API monitoring module. The trigger was behavioral (repeated log views), the eligibility filter was plan state (free users who had the option to upgrade), and paid account adoption rose from 19% to 42%. That's not a rounding error but a near-doubling, and it came from watching behavior inside a known plan segment rather than counting days since signup.

The same logic extends to expansion prompts generally. A team bumping against its plan limits, a solo user whose invite count suggests they're bringing in collaborators, a power user whose feature use maps cleanly onto a higher tier, these are all behavioral signals that make an expansion message relevant rather than presumptuous. And this is where plan state does its most direct work: a growth-plan user consistently hitting the ceiling of their current tier is a fundamentally different audience from a growth-plan user who hasn't touched most of what they already have.

Role-based tours that swap out a single canonical onboarding flow have shown real but varied lift, roughly a 10% activation increase in one documented case, a 14% relative increase in another timesmarble.com. The same segmentation instinct, applied to ongoing messages rather than confined to onboarding, extends that advantage across the entire lifecycle of the account timesmarble.com. Time-based drip logic assumes the passage of time is a proxy for readiness, but it is not; a user who signed up 14 days ago and has not yet reached a feature may not have had the opportunity, may lack the right permissions, or may be on a plan where the feature is locked.

Why the account-versus-person distinction changes who gets which message

B2B SaaS runs two adoption problems at once, and they don't resolve the same way. Organizational adoption asks whether the account is using the product across its intended use cases. Individual adoption asks whether this specific person is reaching the behaviors that generate value for them.

User onboarding and product onboarding get treated as the same problem more often than they should be, and they aren't. User onboarding teaches individuals how to use the thing day to day. Product onboarding configures the platform to match the organization's workflows and business goals. Customer success teams that solve only one tend to end up with adoption that looks fine on paper and partial in practice timesmarble.com.

The account's plan sets a ceiling on what's available. The individual's permission state sets a floor on what they personally can reach within that ceiling. Both have to be known before a message can be considered grounded. That has concrete routing consequences: an expansion message belongs with the billing owner or account admin, full stop, not with an end user who has no authority to buy anything. A configuration message about SSO or audit logs belongs with the admin persona no matter how many other seats exist on the account.

Measuring adoption at the wrong level produces false confidence, and this appears most clearly when a feature adopted enthusiastically by one power user is mistaken for account-wide adoption. A feature adopted enthusiastically by one power user inside a twenty-person account is not account adoption, even though it might look like a win in a dashboard somewhere. Distinguishing people from accounts means telling apart a real signal from a misleading one.

Building the data foundation: connecting plan state to behavior without a new tracking plan

Plan tier and permission state are almost never analytics events that need instrumenting; they're facts sitting in the product's own database already. They're facts sitting in the product's own database already, updated the moment an account or a role changes.

The behavioral half of the equation, what a user has actually done and when, lives in product analytics. The gap between the two, what someone on this plan with these permissions should have done by now versus what they've actually done, is the signal worth building messages around. A unified event stream covering product usage, billing, CRM, and support is the underlying foundation, but plan and permission data are typically already sitting in the billing and CRM layer, so there's no new instrumentation project required to get at them.

Three tables tend to matter most for this specific use case. An accounts table carrying plan tier, billing status, contract dates, seats purchased. A users table carrying role, permission level, last active date, assigned features or modules. An events table carrying feature interactions, milestone completions, how often key actions repeat.

The eligible cohort for any given message is the intersection of all three: users whose account plan includes the feature, whose permission level grants access to it, and whose behavior shows they haven't reached the adoption milestone yet. Behavioral data broken out by plan segment, again, which features growth-plan users open in week one, is worth more than assumptions about personas, and it's already being generated. It just needs an analytics layer that captures events at the feature level. On the operations side, a shared definition of "eligible user" and "adoption milestone" that gets reused across campaigns, rather than reinvented by every team that runs one, is what keeps segments from drifting apart over time. One activation criterion, defined once, in the database, is the asset that lasts.

What plan-and-permission-grounded messages look like compared to role-based or broadcast alternatives

Broadcast messaging looks like this: "Upgrade to unlock advanced reporting," fired to every growth-plan user on day 30, no matter whether they've touched basic reporting yet, no matter whether they're the billing owner, no matter whether advanced reporting has anything to do with their job timesmarble.com.

Role-based messaging is a step up but still shaky: "As a marketer, you'll love our campaign analytics dashboard," sent to everyone who typed "marketer" into a signup field, whether or not they hold the permission to open that dashboard or sit on a plan that includes it.

The grounded version narrows things down to users on plans that include the feature, with permission to access it, who haven't used it yet, and whose behavior shows they've reached the point where it's actually relevant to them. The message then references one specific action available to them right now.

Reciting someone's activity back at them ("noticed you logged in three times this week") without tying it to a useful next step is just data on display. A message earns its specificity by pointing somewhere, not by proving the system was watching. Static onboarding sequences that keep repeating themselves after the product already has better information run into the same wall: a user who skipped the checklist but found value through some other path needs advanced guidance next, not another beginner nudge, and that principle holds for every ongoing message grounded in current state, not just onboarding timesmarble.com. Under S4, the AI upgrade on plan-based personalization is to let behavioral data from each plan segment determine what gets surfaced by default rather than making assumptions, and a message built this way is an extension of the same logic into the outbound channel.

Measuring whether plan-and-permission-grounded messages changed behavior

The sources checked for this guide are listed below.