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: 2021-08-19
The Fulfillment section is passionate about creating seamless commerce experiences for our customers. We traverse sales segments, checkout preferences, and hosting options focused on ensuring customers can easily purchase, activate, and manage their subscriptions. Our goal is to increase net ARR while improving overall GTM efficiency, doing so will help GitLab scale growth and create an exponential lift while other departments and sections leverage our platform and experiences.
Currently our section is divided across three groups. Purchase is responsible for our primary checkout experiences and any product-driven purchase automation, License is responsible for provisioning of both SaaS and Self-Managed subscriptions, and Utilization takes care of usage reporting and usage admin controls. We also collaborate frequently across all of GitLab to achieve our goals. Most commonly we work with Sales Ops, Commercial and Enterprise Sales, Enterprise Applications, Growth and the Data teams.
If you have any feedback on our direction we'd love to hear from you. Feel free and raise an MR, open an issue, or email Justin Farris.
Across our stable counterparts we follow four key principles (listed below). These principles keep us focused on delivering the right results and aide in enabling us to collaborate better with our stakeholders. These principles are not absolute, the intent is for them to guide our decision making.
When customers choose to purchase GitLab they've already discovered value in the product, they know what they want and they're ready to unlock additional value by accessing the features / services enabled by a transaction. We should strive to ensure our transacting experiences fade into the background. This creates a better customer experience (no one wants to labor over buying something, they just want to use the product they bought), and result in accelerated growth for GitLab.
Fulfillment's systems are often the foundational layer for a lot of the commerce conducted within the organization. We interface directly with Zuora (our SSOT for all subscriptions and transactions), maintain the licensing system that provisions a purchase for customers, and are the source of data for many KPIs and trusted data models. These systems need to be reliable, scale with demand and provide a solid surface area for other teams to collaborate on top of. If we do this well teams at GitLab don't need our time and resources as they take a dependency on our systems.
On the Fulfillment team we have many sensing mechanisms at our disposal: customers are a zoom call away, we sync with our counterparts across the business weekly, and our issue tracker is full of improvement suggestions raised by GitLab team members and members of the wider community. We're also beginning to improve 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, to do so the Fulfillment teams will ensure we've properly instrumented each point in our transaction funnels and leverage analysis of that data to inform our strategy and direction.
Iteration is one of the most challenging values to follow, especially within Fulfillment. Often times our work needs to be bundled and aligned closely with external announcements or communication. Even if that is unavoidable the Fulfillment team strives to break work down as much as possible and always be searching for the smallest possible iteration that delivers value to our customers or the business.
The Purchase group is responsible for all transaction experiences and commerce automation. Trials, purchase flows, consumption purchasing, and account management (invoices, contact, billing info). This includes payments for new customers along with renewals. This group is also responsible for the purchase transitions and communication between our storefront and Zuora. Systems: CustomersDot, GitLab. Integrations: Zuora, Stripe.
The License group is responsible for all of the post-purchase activities that occur behind the scenes when a customer purchases new seats or modifies existing subscription. This includes retrieving and managing licenses, provisioning of SaaS subscriptions, and integrations to back of house tools. Systems: LicenseDot, Salesforce, GitLab.
The Utilization group is responsible for all consumables reporting and management, usage reporting, and usage notifications. GitLab.
Our vision is to build an exceptional commerce experience for our customers, an experience that "gets out of the way" of the product and enables GitLab to scale growth as we add more and more customers. Delivering on this vision will mature all interfaces where customers conduct business with GitLab, regardless of customer size or needs they'll be able to transact smoothly and begin using what they've purchased quickly and efficiently. By focusing on building an exceptional experience we'll also enable GitLab team members contributing to GTM activities. Sales can scale to spend more time on accounts with a high LAM, while functions like Support and Finance will spend less time manually supporting customers and our field teams.
To achieve this vision we'll focus on the following areas:
Many new logos land as small first-orders. A common buyer persona in the webstore is Alex choosing to purchase GitLab for their team. Alex may work at a small startup poised to grow, or a larger enterprise with some influence to adopt a new DevOps tool. Either way that initial experience with purchasing GitLab often starts in the webstore as a self-service transaction. This customer isn't necessarily ready to talk with sales, and only wants to make a small investment to get started with GitLab. By building a simple and easy to use transaction experience we can get out of Alex's way and get them back to adopting newly acquired features and onboarding. One of the best ways to do this is reducing friction from the point a customer has decided to purchase to when they're back in app developing their applications. This is why we're focused first on moving our purchase flows out of a separate website (customers.gitlab.com) and into the core product. This forms the foundation that enables us to start iterate from. Our goal is for many other teams to contribute to that purchase experience, namely our Growth team counterparts who might run experiments improving conversion. Furthermore, we also aim to provide optionality at checkout and make the purchase experience tie more closely to the entire GTM self-service funnel. As one example: Imagine being able to run promotions that offer discounts connected to a marketing campaign, making that experience seamless will help improve conversion and lead to a better overall experience transacting with GitLab.
The focus here is efficiency, enabling more and more transactions to be started and completed via the webstore will free up our GTM counterparts to spend more time on higher value activities. Naturally the most benefit we get here is from SMB accounts but the vision is to enable support across our entire customer base. Mid-Market and Enterprise customers may want to transact completely self-service OR add-on to their GitLab subscription with incremental spend (e.g. purchase additional CI minutes). The fastest and most efficient way to do this for both the customer and our field teams is to enable that capability digitally. To do this well everyone in the loop needs visibility into the transactions. Our field teams may be compensated from those transactions and the customer needs a clear understanding of their total spend on GitLab, even if some of those transactions originated via different "storefronts".
A key aspect to ensuring success in this area is a strong partnership with our GTM teams, especially our VP of Online Sales & Self Service. We'll need to map out the correct customer journeys across sales-segements and enable customers to self-select as they progress through the purchase experience.
While the majority of GitLab transactions occur with a credit card and pay up-front for anything they purchase, that's not necessarily the preferred method for a large part of the world. Outside of the US the preferred digital payment method is an e-wallet and many customers as they grow and scale have more complex payment and billing requirements. To meet global demand we need to support multiple payment types and options. This can include multiple payment types, support for complex billing motions automatically via the webstore (POs, ACH transactions, etc), and support for multiple currencies.
More and more GitLab customers begin their journey with GitLab via a partner. They may transact in a cloud provider's marketplace or purchase with a larger bundling of software via a distributor. Our goal is to ensure those customers and partners get as high quality of service as they would buying direct. This means extending our APIs to support "indirect" transactions and collaborating closely with our counterparts in Channel Ops, Finance, and Enterprise Apps to design solutions that extend our internal systems beyond their direct-sales use-cases.
With GitLab 14.1 we launched Cloud Licensing this provides a foundation for an improved licensing and provisioning experience for our customers. For years GitLab was behind in modernizing our licensing systems and architecture, now that we've caught up we need to continue to iterate to help customers scale and reduce friction in license management. There are two key areas to focus on in the future:
Enterprise License Management The larger the instance the more challenging license and seat management becomes. These customers often need multiple instances, move large amounts of users in and out of the application each month and have complicated configuration requirements. To that end we will begin to unpack these problems and deliver solutions that help customers with larger instances easily deploy licenses and manage provisioning over the entire enterprise. The goal is to ensure Sidney and Skyler can easily deploy licenses to meet the evolving needs of their business.
Usage and Reporting The most common Fulfillment-related questions customers ask after they've transacted is related to usage and consumption. While the majority of GitLab transactions occur on an annual subscription model there is still incremental usage and spend customers need to manage each month or quarter. This comes in the form of add on users, and consumables (storage and CI minutes). Managing usage based spend can be a headache for any customer. Organizations of any size need predictability in costs so our goal is to deliver transparent and clear reporting of seat usage, consumption and any other metered usage/billing option GitLab offers.
Fulfillment just wrapped up a large cross-functional effort to deliver Cloud Licensing. After a smooth and successful rollout we're shifting focus towards work aligned to a few key themes. These themes map to our Project Compass levers and are focused on enabling continued growth for GitLab's business.
Scale and stabalize our core systems that support millions in ARR per quarter. Over the past year we've delivered two major projects in EoA and Super Sonics. To support those changes we've deferred a lot of tech debt and general performance and reliability work both in the application layer and overall configuration and integration of how our propritary systems interface with tools like Zuora and SFDC. This work catches us up, and hardens that foundation that will allow us to scale to many millions in transactions processed per quarter.
Infra Dev - Move customers.gitlab.com out of Azure and into GCP (Purchase, License, Utilization)
Support to complete the migration to Zuora orders (Purchase, License)
Follow On Iterations for Cloud Licensing & Quarterly Reconciliation There are a few follow on items to continue to support iteations on cloud licensing and enable all customers to be elligible for the new licensing and billing changes.
Followups from Cloud Licensing (Purchase, License)
Quarterly Reconciliation support for customers who require purchase orders (including Channel partners) (Purchase)
Convert more SMB and low-dollar transactions via self service Since the launch of EOA our self service transaction share has been declining. We need to focus on building a solid foundation to push more and more purchasing towards self-service and find opportunities to redirect SMB sales-assisted transactions to the webstore.
Evolve license, seat and usage management across SaaS and Self Managed Now that we have a licensing system that will scale with GitLab's growh, and consistent Operational Data flowing from self managed instances we're ready to enhance our licensing, provisioning and utilization capabilities.
Problem and Solution validation for enterprise license management (License)
User Caps (Utilization)
Improvements to Billable Members (Utilization)
Seat Usage Vision (Utilization)
Project Level Storage Visibility (Utilization)
Note: this work is not inclusive of all Epics/Issues scheduled in the next few milestones, to see that list please see our more detailed roadmap
Below is a list of performance indicators we track amongst the Fulfillment team. Note: some metrics are non-public so they may not be visible in the handbook.
Percentage of transactions through self-service purchasing
Percentage of SMB transactions through self-service purchasing
CI Minutes Transactions and Revenue
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!
We also track and prioritize work closely with our GTM counterparts. This is tracked in an internal spreadsheet and reviewed monthly with the CRO leadership team.
