If your question is not answered by the key links above or this guide:
Not all Fulfillment features are available at the time for all types of customers, please refer to the availability matrix below.
| Customer Type | Cloud Licensing (Y/N) | Auto-Renewals (Y/N) | Quarterly Subscription Reconciliation (Y/N) | Operational Data (Y/N) |
|---|---|---|---|---|
| Customers with credit card on file | Yes | Yes | Yes | Yes |
| Customers paying with invoice | Yes | Yes | Yes | Yes |
| Customers requiring a PO | Yes | No | No | Yes |
| Customers with an MSA | Yes | No | No | No |
| Customers with multi-year deals | Yes | No | No | Yes |
| Customers purchasing through a GitLab Reseller or other Channel/Alliance Partner | Yes | No | No | Yes |
| Public Sector Customers | Yes | No | No | Yes |
| Customers with offline/airgapped environments | Yes (Offline cloud license released in GitLab 15.0) |
No | No | No |
| GitLab for Education, Open Source and Startups Customers | No | No | No | No |
| Free Tier Users | No | No | No | No |
We currently have a version of User Caps for groups built for SaaS, which is similar in behavior to the self-managed User Caps feature. As of now, this feature is not ready for production use. GitLab team members can learn more about the feature in the internal handbook.
List of features managed by the billing and subscription management group within the Fulfillment section.
The renew subscription feature allows customers to renew their SaaS or Self-managed subscriptions. This feature is available through the Renew button on the subscription card in the Customers Portal.
The target audience is the internal GitLab team, and covers the admin panel of the CustomersDot. Customers or subscription managers should refer to the Customers section of GitLab's user documentation for help in using the portal, or the licensing FAQ for questions on subscriptions such as how users are counted.
For members of our sales teams, you can learn more about how to use CustomerDot for common use cases in our Field Operations - CustomersDot Access and Use page.
When using the admin panel search, be aware that results will be based on searching only one field at a time. For example, entering a person's full name will likely provide no results because the system will not search first and last name at the same time, only one or the other.
We recommend searching by email address, partial email address (e.g. company domain), or company name. When searching by name, enter only first or last name.
After your initial search, you can further filter the search results.
In the search results, any account which has a subscription tied to it will have a "Subscription" badge next to their name.
To edit an account's details, such as name.
Edit.History.If an account has a connected GitLab.com user account, then a list of namespaces will show with relevant information including current plan.
The list of namespaces are:
OwnerNote: Until customers #973 and customers #1643 are resolved, this is unlikely to be available.
GitLab Groups.Renew Trial button.Update. Warning: Do not change the date to a date prior to today's date in UTC timezone.If a bug is discovered that impacts Fulfillment, including provisioning, purchasing, billing, subscription data, etc., please do the following:
Reporting the issue
@fulfillment-group/leadership/fulfillment-pm group.ofernandez2 for review and action.Notifying appropriate DRIs
The following individuals should be looped into the issue, depending on the impact of the bug:
Sarah McCauley - Director, Billing & ARJessica Salcido - Finance Systems AdministratorJesse Rabbits - Sr. Manager, Deal DeskLyle Kozloff - Director of Support, Global ReadinessJustin Farris - Sr. Dir, Product MonetizationAcross our stable counterparts, we follow four key principles to keep us focused on delivering the right results. These principles are not absolute, the intent is for them to guide our decision-making.
Make conducting business with GitLab seamless
When customers choose to purchase GitLab they've already decided to unlock additional value by accessing the features or services enabled by a transaction. We strive to make the transaction experiences fade into the background, helping customers unlock this additional value as easily as possible. This creates a better customer experience and results in accelerated growth for GitLab.
This means that in every initiative we question the need for complexity. We strive to build functionality that is easy to understand and use, and make sure it works flawlessly for customers of all types. As much as we can, we won't require a customer to speak to a sales representative and will allow them to choose whether to transact via online self-service tools.
Build a strong foundation so GitLab can scale
Fulfillment systems are the foundational layer for many commerce activities within GitLab. Our systems provision licenses for customers, are the source of data for multiple KPIs and data models, and interact directly with Zuora and Salesforce. These systems need to be reliable, scale with demand, and allow other teams to collaborate.
We regularly invest in our foundations and will continue to pause new feature development in favor of foundations whenever we feel that our foundational systems aren't robust enough. We established a Fulfillment Platform group in FY23 for focused efforts in this area.
Use data to make decisions and measure impact
We have many sensing mechanisms at our disposal: feedback routed via our GTM teams, meetings with business counterparts, customer feedback from user research, and improvement suggestions raised by GitLab team members and members of the wider community in our issue tracker.
We're also improving how we use data as a sensing mechanism to set direction and prioritization. Understanding our funnel is paramount in building a seamless commerce experience for our customers. Fulfillment teams in collaboration with Growth are instrumenting each point in our transaction funnels so we can use data to inform our strategy and direction.
Iterate, especially when the impact of a change is sizeable
Iteration is one of the most challenging values to follow, especially within Fulfillment. Oftentimes our work needs to be bundled and aligned closely with external announcements or communications. Even so, we strive to break work down as much as possible and decouple functionality releases from broader announcements. Doing this expedites delivering value to our customers and the business.
Minimize and remove business logic from the GitLab application code
In the past, we have embedded significant business logic into the GitLab instance code directly. For example, we have logic in our licensing system that checks at the instance level whether the customer license should be activated based on licenses paid for, etc. This causes significant issues as we evolve our business policies, which we can't then reflect in past GitLab versions that we support.
We will minimize such logic and remove it from the application code whenever possible, seeking alternative solutions.
Our roadmap is prioritized and scheduled following our Project management process. We aim to update this roadmap every month as a part of our milestone planning process.
To request work to be added to the Fulfillment roadmap, please follow our intake request process. Changes in priorities of this roadmap follow our prioritization process.
The source of truth for all Fulfillment projects is our in-product Fulfillment Roadmap.
By nature of our direction, Fulfillment works mostly on highly cross-functional projects where either or both of the following are true:
To focus on the most impactful work, Fulfillment’s prioritization process seeks to:
A project will be prioritized in the Fulfillment roadmap based on the considerations below.
All initiatives, regardless of who requests them, will be evaluated based on this same criteria.
Some initiatives will have a direct impact on these criteria, but others will have an indirect impact. We will consider indirect impact as part of the prioritization.
When scoping new solutions we will prefer those that best allow GitLab to scale and accelerate future work. These solutions often require more upfront foundational work, which we will include in the initial scope. In cases when we decide to accelerate a solution by skipping on some foundational work, we will add this foundational work as a separate line item to the roadmap.
A note on Customer Satisfaction: to understand the impact of efforts aimed at improving customer satisfaction, we should estimate the indirect impact of improving CSAT on revenue and cost. For example, by reducing the number of steps or improving the steps required to purchase we will see an increase in conversion rate and thus revenue.
Prioritization based on the established criteria will drive the order in which work is scheduled to be completed. The product team will review overall prioritization regularly. Before changing priorities, will consider:
To minimize impact and give more predictability to partner teams, we will minimize changes to initiatives that we’ve already agreed with cross-functional partners to do within the ongoing quarter.
Anyone can request new items to be added to the roadmap via an intake request.
One of our prioritization goals is to maximize overall team output across Fulfillment and cross-functional partners. We want to give transparency to all GitLab team members about the work that Fulfillment and its partner teams plan to deliver.
To enable this, we will do a roadmap review with our stable counterparts before the beginning of a new fiscal quarter. As part of this review, we gather feedback on roadmap priorities, update the roadmap based on the feedback, and agree with partners on the scope and delivery milestones for the upcoming 3-6 months.
During these quarterly reviews we will aim to commit up to 70% of Fulfillment’s engineering capacity for the upcoming quarter, and no more than 30% of capacity for the quarter after. This is meant to provide enough visibility into upcoming activities for cross-functional partners to plan for them while leaving room for reprioritization and changes as needed.
Any proposed changes to the roadmap will be first communicated to cross-functional partners async in a relevant Slack channel with the relevant context and rationale, and ask for feedback. As needed, a synchronous meeting will be scheduled to discuss. All feedback will be considered by the product team and a final decision will be made and communicated once made.