How to Build a Team Admin Portal for Product-led-Growth (PLG)

May 3, 2023
Patrick Rafferty
Co-founder of UserHub

When SaaS operators envision the self-serve monetization journey in B2B SaaS, the pricing pages and checkout flow are usually top-of-mind.

However, 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.


1. 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.


2. 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 (<span style="color: #906bfa;">members_active</span> > <span style="color: #906bfa;">user_licenses</span>). 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.

3. How do End-Users join a Team?

There are 3 pathways that are standard for B2B SaaS:

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:

(From 1Password Team Management Portal - no enterprise plan so no Enterprise SSO).

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….

4. What is 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.

5. 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:

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.

<div class="button-blog-wrapper"><a href="" class="button-blog">REACH OUT TO US IF YOU WANT TO TALK ABOUT TEAM MANAGEMENT</a></div>

What’s a Rich Text element?

What’s a Rich Text element?

What’s a Rich Text element?

What’s a Rich Text element?

What’s a Rich Text element?
What’s a Rich Text element?

The rich text element allows you to create and format headings, paragraphs, blockquotes, images, and video all in one place instead of having to add and format them individually. Just double-click and easily create content.

  • list item 1
  • list item 2
This is caption

In this article, we walk through five key questions to help you design a Team Management Portal that unlocks product-led growth:

  • Is every Team Membership role considered billable?
  • How should your Team Management portal behave at each pricing tier?
  • How can users become team members?
  • What is the optimal moment to monetize an end-user?
  • How forgiving are your proration flows to billing admins?
The Case For Free Roles
Examples: 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
Examples: 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.

[Users with the role of] Viewer can upgrade themselves to a paid Editor role by performing an upgrade action. Admins don't need to approve these upgrades…. This allows people to get the access they need without requiring approval. Figma only includes them in the organization’s billing when they signal their intent and take an explicit edit action. As this is a provisional role, it's not possible to set someone's role back to viewer after they are upgraded. [Instead, they can only be placed back to a Viewer-Restricted Role].

PLG [product-led growth] works when end users experience value and bring their organization on board. That’s not possible in industries where the enterprise buyer holds all the power…. End-users need to have permission from the organization to solve the problem. This includes access to suitable systems/passwords & decision-making ability.

Patrick Rafferty
Co-founder of UserHub

Featured blogs