Required Datapoints
- Account User Roster: User IDs and roles per account.
- Engagement Logs: Activity tracking per user.
- Role Classification System: Standardized tags (admin, contributor, analyst, etc).
Percent of Accounts with Multi-Role Engagement measures the share of accounts where users from two or more distinct roles are actively using the product. It helps identify cross-functional adoption and account maturity.
Percent of Accounts with Multi-Role Engagement is a key indicator of organizational adoption and expansion potential, reflecting whether different user types within the same account are actively using your product — signaling broad utility across workflows.
The relevance and interpretation of this metric shift depending on the model or product:
A rising trend signals stickiness and value across functions, increasing the odds of retention, advocacy, and account expansion. A low rate may suggest siloed usage, narrow value perception, or poor role-specific onboarding.
Segment by industry, company size, or plan tier to prioritize multi-role engagement plays or discover gaps.
Percent of Accounts with Multi-Role Engagement informs:
These are the main factors that directly impact the metric. Understanding these lets you know what levers you can pull to improve the outcome
Actionable ideas to optimize this KPI, from fast, low-effort wins to strategic initiatives that drive measurable impact.
Activities commonly tied to improving or operationalizing this KPI.
| Activity | Description |
|---|---|
| Expansion Campaigns | Expansion Campaigns involves strategic initiatives and coordinated actions designed to increase the value of existing customers through cross-selling, upselling, or introducing new product features and services. It coordinates execution across touchpoints so teams can move users or accounts toward the target outcome. Relevant KPIs include Activation-to-Expansion Rate and Expansion Activation Rate. |
| Sales Enablement | Sales Enablement focuses on Revenue Enablement integrates people, processes, content, and technology to empower customer-facing teams throughout the buyer journey. It coordinates execution across touchpoints so teams can move users or accounts toward the target outcome. Relevant KPIs include Average Contract Value and Average Days from Referral to Close. |
| Product-Led Growth | Product-Led Growth focuses on positioning the product as the primary driver of customer acquisition, conversion, expansion, and retention. It helps teams translate strategy into repeatable execution. Relevant KPIs include Action-to-Activation Time Lag and Customer Feedback Score (Post-activation). |
| Persona-Based Onboarding | Persona-Based Onboarding focuses on Persona-Driven Onboarding takes a strategic approach by customizing the onboarding experience to address the specific needs, goals, and challenges of distinct customer personas. It helps teams translate strategy into repeatable execution. Relevant KPIs include Percent of Accounts with Multi-Role Engagement. |
A SaaS platform has 400 active accounts:
This KPI is associated with the following stages in the AAARRR (Pirate Metrics) funnel:
This KPI is classified as a lagging Indicator. It reflects the results of past actions or behaviors and is used to validate performance or assess the impact of previous strategies.
This role is directly accountable for the KPI and is expected to drive progress and decisions around it.
These roles contribute directly to performance and typically partner on execution, reporting, or optimization.
These leading indicators influence this KPI and act as early signals that forecast future changes in this KPI.
These lagging indicators confirm, quantify, or amplify this KPI and help explain the broader business impact on this KPI after the fact.
How this KPI is structured in Cube.js, including its key measures, dimensions, and calculation logic for consistent reporting.
cube('AccountUserRoster', { sql: `SELECT * FROM account_user_roster`,
joins: { EngagementLogs: { relationship: 'hasMany', sql: `${CUBE}.user_id = ${EngagementLogs}.user_id` }, RoleClassificationSystem: { relationship: 'belongsTo', sql: `${CUBE}.role_id = ${RoleClassificationSystem}.id` } },
measures: { accountCount: { sql: 'account_id', type: 'countDistinct', title: 'Total Accounts' }, multiRoleAccountCount: { sql: `account_id`, type: 'countDistinct', filters: [{ sql: `${CUBE}.role_id IN ( SELECT role_id FROM account_user_roster GROUP BY account_id, role_id HAVING COUNT(DISTINCT role_id) > 1 )` }], title: 'Accounts with Multi-Role Engagement' }, percentMultiRoleEngagement: { sql: `100.0 * ${multiRoleAccountCount} / NULLIF(${accountCount}, 0)`, type: 'number', title: 'Percent of Accounts with Multi-Role Engagement' } },
dimensions: { accountId: { sql: 'account_id', type: 'string', primaryKey: true, title: 'Account ID' }, userId: { sql: 'user_id', type: 'string', title: 'User ID' }, roleId: { sql: 'role_id', type: 'string', title: 'Role ID' } }});cube('EngagementLogs', { sql: `SELECT * FROM engagement_logs`,
dimensions: { userId: { sql: 'user_id', type: 'string', title: 'User ID' }, activityDate: { sql: 'activity_date', type: 'time', title: 'Activity Date' } }});cube('RoleClassificationSystem', { sql: `SELECT * FROM role_classification_system`,
dimensions: { id: { sql: 'id', type: 'string', primaryKey: true, title: 'Role ID' }, roleName: { sql: 'role_name', type: 'string', title: 'Role Name' } }});Note: This is a reference implementation and should be used as a starting point. You’ll need to adapt it to match your own data model and schema