In this article, we walk through five key questions to help you design a Team Management Portal that unlocks product-led growth.
When SaaS operators envision the self-serve monetization journey in B2B SaaS, the pricing pages and checkout flow are usually top-of-mind.
For those aspiring to embrace the Product-Led Growth (PLG) model with per-user pricing, the Team Management Portal emerges as a crucial driver of monetization.
For instance, if you already have a commercial relationship in place (e.g., credit card on file), this portal unlocks Express Licensing – the SaaS equivalent of 1-Click Checkout.
Is every team member role considered billable?#
The first consideration is whether your product should offer a user role that is not billable. In other words, are some user roles free? The Coda Maker Billing is a great example of this concept:
The choice of role design and how it relates to monetization is not solely a tactical consideration for the product teams assigned to work on Account Management and Subscription Management. It is, in fact, a strategic decision that requires careful consideration of the value of secondary users of your product.
The case for free roles (Coda, Figma) #
- An organization has lower willingness to pay for secondary users; however, these secondary users enhance the product's value for primary users.
- Since there is a free role for inviting users, SaaS companies tend to feel more comfortable granting user invitation privileges to all users by default, rather than limiting them to only admins.
- For instance, Figma does not charge an organization for non-editors. This approach enhanced the product's value for designers by providing a platform for collaborative design processes. Subsequently, they monetized these non-designers by cross-selling their whiteboard product, Figjam.
The case against free roles (Zoom, GitHub) #
- There are no obvious secondary users, so offering a free role may lead to cannibalization of paying users
- In the case of GitHub, introducing a free role could potentially have more drawbacks than advantages. Unlike Figma, users who cannot read code may not enhance the platform's collaborative utility. Furthermore, attempting to create a free role for non-engineers introduces the risk of cannibalization. GitHub could lose the ability to monetize engineers who do not write code but still provide valuable contributions through code reviews.
How should your Team Management portal behave at each pricing tier?#
The Team Management portal must be designed to address the varying user licensing behaviors across pricing plans in order to accommodate different go-to-market strategies, such as self-serve versus sales-led. This means that each plan will likely require plan-specific business logic related to Team Management.
Self-serve plans require technology teams to codify the relationship between the Team Portal and monetization. The result of sales intervention is a loose coupling between the entitled state and the billable state.
An excellent example of this is Figma Quarterly True-Up Process on their Enterprise Plans. The customer account can become over-provisioned, with the Team Management Portal listing a number of licenses the customer has not paid for (members_active > user_licenses). This behavior, as depicted below, does not occur on lower-tier plans.
From an architectural standpoint, the separation of entitlements from billing makes it easier for your Team Management Portal to handle the complexities of both go-to-market motions.
Last point on Pricing Plans: organizational features such as enterprise SSO (SCIM) tend to be packaged on higher plans themselves as well.. which leads us to question three.
How do End-Users join a Team?#
There are 3 pathways that are standard for B2B SaaS:
| Member Method | Description | How is user role set? | Pricing & Packaging tendencies |
|---|---|---|---|
| Invitations | An end-user is invited specifically by someone with administrative authority over an account (e.g. team member with invitation rights, or a member of the support team from the SaaS company). The invitee establishes relevant attributes of the user (role, licenses, etc). | The invited user role established by the invitee user. | Available on lower-level plans. |
| Just-in-Time Provisioning | Just-in-time user provisioning creates a user in an app when the user attempts to sign in for the first time (via SSO). The account and respective role don’t exist until the app creates them. | Must decide default role. | Available on lower-level plans. |
| Enterprise SSO (SCIM) | Provisioning users is initiated outside of your application via Directory Sync, which is required by large enterprises - this likely only exists on enterprise plans. | Setup within the Directory. | Enterprise-equivalent plan only. |
One important concept to understand is the effect of Enterprise SSO when it is implemented. Access is now fully controlled and automated outside of your Team Portal, via a directory sync. Therefore, your Team Portal will only display the current state of your customer account, and it will no longer be the place where management of the user occurs. This feature is typically reserved for enterprise plans, and most companies package Enterprise SSO at their highest tier.
Beware: some people get upset about this; see The SSO Wall of Shame.
Here is how the configuration of these three on-ramps appears within the 1Password Team Management Portal:
As we mentioned in point one, the access level of the user (e.g., the user role) will be relevant in terms of determining the billable state of the user. So, think through how access is assigned for each member pathway. On Figma Enterprise Plan, you can set default roles for SCIM:
Per Figma Documentation:
On the Enterprise plan, organization admins can set Default Roles for anyone joining the organization. This helps organization admins to better control and manage new editor seats.
This leads to a more general question….
What is the optimal Monetization Moment?#
You have to map the monetization moment onto the user journey. Let’s revisit Coda Maker Billing model, and how it manifests in their Team Admin portal. Coda provides 3 licensing flows:
In the default licensing flow, end-users become billable after they create a document (which automatically changes their role to Doc Maker). This is low-friction from the perspective of the end-user, who does not need the billing admin to buy a user license before becoming a Doc Maker. Instead, the monetization moment happens afterward, and the billing admin is given a chance to intervene.
This stands in contrast to a higher friction approach, such as GitHub, where licenses must be bought and assigned by an admin. In this approach, end-users are blocked by monetization.
To decide where your product should lie on this spectrum, it requires a point of view regarding how your product will be adopted within an organization. If you can rely on a billing admin to drive adoption, your product can tolerate more friction because end-users will have a mandate to use the product. If demand for your product is driven by end-users (e.g. "bottoms-up"), you need to remove friction out of that process to allow them to make progress before a billing admin can intervene.
Of course, billing admins need cost control. This brings us to our final consideration.
How forgiving are your proration flows?#
Your proration flows codify the business logic that dictates how customers should be billed for adjustments to their subscription in the middle of a billing cycle. If your PLG motion is working, this will be a regular occurrence. The Team Management portal focuses on intra-plan changes (e.g. adding or removing users). So for now, we can ignore the other instances of proration (e.g. inter-pricing plan changes).
Let's revisit Coda. Their Team Portal offers three licensing configurations that dictate how end-users become Doc Makers. The default approach, which we discussed in the previous section, provides the most lenient proration flow among the three choices:
| Access to Doc Maker | Proration | Default | End-User Friction |
|---|---|---|---|
| Instant | Standard: Immediately counted as a billable user. If a user joins half way through a month, they are billed for the balance. | N | Low |
| 7-day grace period | Forgiving: The admin has 7 days whereby the user is not considered billable for a week. | Y | Low |
| Manual | Standard: Send request flow to billing admin, who must approve the request. If billing admin grants access, user is counted as a billable user. | N | High |
In a licensing flow that allows end-users to become billable without prior approval from the billing admin, it is common to incorporate a grace period, as Coda has done for their default licensing flow ("7-day grace period"). This grace period provides the billing admin an opportunity to adjust the subscription before an invoice is issued.
Coda has provided three licensing flows, which requires a large investment in subscription management and billing automation. However, if it's right for your product, it could drive subscription growth.