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.
Last reviewed: 2020-12-22
The Fulfillment Section is comprised of the Purchase, License and Utilization groups. These groups are organized to create clear DRIs for key systems internally, and for clear boundaries between customer experiences. We've only recently established these groups and will be firming up their individual direction pages, along with all other handbook artifacts and metadata after the new year.
Additional pages of interest:
The Fulfillment section focuses on creating and supporting experiences that enable our customers to purchase, upgrade, downgrade, and renew licenses and subscriptions. Additionally we support account and subscription management (adding and removing licenses), along with consumption purchases (currently CI minutes and storage). We are constantly striving to make the billing and payment processes simple, intuitive, and stress-free for our customers and GitLab team members. We believe that engaging in business transactions with GitLab should be minimally invasive and when noticed, should be a positive, empowering, and user-friendly experience.
As we mature this section over the coming quarters we aim to reduce friction for customers by enabling them to self-service as much as possible all while reducing manual intervention from our sales and support functions empowering them to spend more time working directly with our customers on more strategic activities.
We also partner with the Growth Groups to enable experimentation and product improvements focused on making it easy for people to try, buy, grow, and stay with GitLab.
The Purchase group is responsible for all purchase experiences. Trials, purchase flows, and account management (invoices, contact, billing info). This includes payments for new customers along with trials. This group is also responsible for the purchase transitions and communication between our storefront and Zuora. Systems: CustomersDot, GitLab. Integrations: Zuora, Stripe.
The Provision group is responsible for all of the post-purchase activities that occur behind the scenes when a customer purchases new seats or modifies existing licenses. This includes retrieving and managing licenses along with integrations to back of house tools. Systems: LicenseDot, Salesforce.
The Utilization group is responsible for all consumables management, usage reporting, and usage notifications (excluding license utilization). GitLab.
we'll be iterating on the organization of these PIs as we further establish our groups, for now they are all tracked uniformly across the entire section
Percentage of transactions through self-service purchasing
Percentage of SMB transactions through self-service purchasing
CI Minutes Transactions and Revenue
You can learn more about this project here through our slack channel here.
Today's process for managing licenses of a self-managed instance is less than optimal. You need to login to customers.gitlab.com to purchase, renew and access your license key - then manually configure your instance to accept that new key. We want to make this process as painless and seamless as possible.
Our plan is to enable a license sync system that will allow customers to regularly sync their license and user counts with GitLab to streamline purchases and renewals as well as enable us to provide more flexible billing options for our customers.
At the same time, we understand that not all of our customers are running instances that can connect to the internet or have requirements against sharing any kind of information. In those cases, we need to ensure customers have the option to continue to purchase and apply licenses as they do today, but with as minimal friction as possible.
We've heard feedback from our customers and sales team members that GitLab's current true up process is not ideal. To improve we're looking to move to "co-term" seat growth on a quarterly basis. This means that instead of being billed for add on users at the end of your term, for the entire term we'd reconcile the add on users once a quarter. You can find more details in the linked epic, we're optimistic that this improvement is a great first step as we iterate on making our billing and add-on user process more transparent to our customers.
Today many actions related to a customers account require manual intervention. This could be as simple as configuring a trial, or as complex as handling add on seats mid term. We aim to reduce the tasks the require manual intervention as much as possible. Doing so enables customers to help themselves quickly, without engaging with sales. It also enables our sales and support teams to free themselves up to use their time on higher value activities and more complicated deals or customer issues. This work is comprised of many individual tasks. You can find the work tracked against the linked issue.
The below themes are groupings of work the team has been focused on over the past few quarters. We'll likely divide this out as we further establish our groups and onboard new PMs.
We don't want our customers to be surprised about billing and user management. Customers should be fully aware when they're taking an action that will require additional payment.
We want customers to easily understand what (and who) they're paying for. Over the next two quarters we will provide instance admins and group owners with tools to find the users they are being billed for.
The CustomersDot should be easy-to-use and provide a consistently delightful experience that matches our other offerings.
The CustomersDot should use our Pajamas design system
We follow the same prioritization guidelines as the product team at large. Issues tend to flow from having no milestone, to being added to the backlog, to a directional milestone (e.g. Next 3-4 releases), and are finally assigned a specific milestone.
Our entire public backlog for Fulfillment can be viewed on the issue board, and can be filtered by labels or milestones. If you find something you are interested in, you're encouraged to jump into the conversation and participate. At GitLab, everyone can contribute!
