The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
The Utilization group aims to ensure customers have access to seat usage data, so that they can make the optimal decisions for their business needs.
What is our long-term solution concept? Analogy: what will it look like at the top of the mountain?
We aim to evolve our seat cost management functionality to simplify assignment, management, and billing for overages of seats.
Seat Type = Base where available roles are Reporter, Developer, Maintainer, Owner, Admin, or a billable custom role. 5 of 20 users could be on Seat Type = Free where the roles available are Guest, Minimal Access, or a non-billable custom role. You'll be able to assign a Seat Type to a user, which determines what roles they can then have.Seat Type = Free with Role = Guest that is free. However, the user has now changed roles and needs access to a Developer role. As part of that transition, they will need to be promoted to a Seat Type = Base, which has increased cost implications. We will need to give customers controls to make that transition from Seat Type = Free to Seat Type = Base given both the compliance and cost implications of such changes.What features are the Utilization group responsible for and how mature are they?
Legend:
| Category | Feature | Maturity | Description |
|---|---|---|---|
| Seat Cost Management (non-add-on products) | Seat Usage Visibility | 😊 Viable | Customers understand how many seats are being used and by whom |
| Seat Cost Management (non-add-on products) | Billable Users Calculation | 🙂 Minimal | Customers understand how many billable seats are being used, by whom, and when they are being used |
| Seat Cost Management (non-add-on products) | Seat Limits | 😊 Viable | Customers understand if they are within the user limits threshold and how to take action (remove, add more, set seat limits) |
Where are we focused over the next 12 months to make meaningful steps towards achieving our vision and increasing feature maturity?
Further Details (Not Public)
| What is the work to do? | Why are we doing this work? |
|---|---|
| Dormant User Management for GitLab.com | Identifying dormant users and removing them on Gitlab.com is a labor intensive and not very intuitive process for our customers. We should make user management, specifically around dormant users, easier so owners can focus their time on less arduous tasks and budgets overages are avoided. |
| Expansion of seat cost management through non-billable role promotion management | - Users' roles are easily adjustable, which can have billable implications in some scenarios. Customers want the ability to manage a user's role to ensure it is not adjusting without the correct approvals. - User caps intends to avoid having billable users > user cap, thus helping GitLab Admins/Owners control the costs of their subscription. Non-billable users don't contribute to billings, so they don't need to be controlled by the user caps feature to accomplish the goal of the feature. |
| Create feature to block seat overages | Enables customers to manage their seat usage |
| Evolve billing model with the Seat Assignment Model | In our current billable model, when adding users to a group or project, they immediately consume a license/subscription seat based on the role they have. We are developing a plan for a Seat Assignment Model (SAM), whereby we allow group owners to assign members to a seat type, which in turn determines what roles they can have when being added to groups or projects. |
| What is the work to do? | Why are we considering doing it |
|---|---|
| Make user counts consistent | Our GitLab sales and support team members frequently get reports of User counts in self-managed and SaaS behaving in an unexpected manner and our goal is to improve the customer experience and user count visibility. |
| Seat digest for users with QSRs | These customers are the ones who already get billed quarterly base on the same usage information we would be sending them in these e-mails. They are the ones who could benefit from seeing the digest in advance of the QSR as a way avoid surprise bills. |
| Question | Answer |
|---|---|
| What type of customers does Utilization serve? | - SM & SaaS Self-service customers - SM & SaaS (GitLab.com and Dedicated) Sales assisted customers - SM & SaaS Channel Partners and their customers |
| What customer personas are Utilization solving for? | Our customers fit the buyer persona and may play a different role in the decision-making and purchasing process depending on their company size and their role. |
| What customer segment is Utilization focused on? | - For SMB and mid-market companies: The application development manager needs to have visibility into usage across their teams and be able to control usage in a way that fits their company preferences/processes/budget. - For large or enterprise company: The release and change management director is concerned with accurate billing and being able to make purchasing decisions based on usage information. |
| What internal teams does Utilization serve? | - Support - Customer Success - Sales |