| Resource | Areas Covered |
|---|---|
| Fulfillment Direction | Fulfillment vision and what we are working on next. |
| docs.gitlab.com Subscription | Customer-facing documentation around GitLab subscriptions, including Customer Portal (customers.gitlab.com) information. |
| Fulfillment Guide (this page) | Documentation around CustomersDot Admin tools and process documentation that is not part of the docs.gitlab.com Subscription documentation above. |
| Fulfillment Development Sub-Department | Team members, stable counterparts (PM, UX, Quality, Security, EntApps, Field Ops, Sales, Billing, Customer Success, Support Engineering), project management processes, and more. |
| Internal Handbook - Fulfillment | Documentation that can't be in the public handbook. Minimize this to only Not Public information. |
| Cloud Licesing Overview (External) | Why Cloud Licensing, data collected, customer pre-requisites |
| Cloud Licensing (Internal) | Internal handbook information about Cloud Licensing |
| Deal Desk Handbook | Standard Quote Configuration (new subscription, amend subscription, add-on quote creation, upgrade or product switch during subscription term, renewal, channel deals, true-ups, co-terms, Starter/Bronze End of Availability, SuperSonics, Professional Services), Non-Standard Quotes (Contract Resets, Concurrent Subscriptions, Multi-year Deals, Ramp deals), Alliance Marketplace Private Offers, and more. |
| Sales Order Processing | Account and opportunity creation, quote configuration, approvals process, opportunity booking requirements, closing an opportunity. |
| Internal Support | Submitting all requests around licensing, subscription, trials, and grace periods. |
| Licensing FAQ | Common questions around purchasing, licensing, billing, contacting sales, and more |
| Finance and Legal Authorization Matrix | |
| Trade Compliance | |
| Billing, invoice and payment requests | Zuora contact change, Zuora entity change and effects on SM/SaaS subscriptions, cancellations, downgrades, refunds, invoices, payments, credit card removals, renewal reversals, split payment requests |
| Troubleshooting: True Ups, licenses + EULAs | |
| Quote-to-Cash systems documentation (EntApps) | Overview of systems, EntApps Architecture, Process Flow Diagrams, Entity Relationship Diagrams |
| Quote-to-Cash process | EntApps documentation including systems and process diagrams. |
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 |
last updated: April 2023
Purpose: document what notifications customers see as part of today's existing repository/project 10GB enforcement.
| Question | Banner Notification | CLI |
|---|---|---|
| What are we showing? | In-app banner notifications that can be seen throughout the GitLab product, on pages related to the affected top-level group and projects. | Command line interface notifications about storage usage when git commands occur. If the push will send the project over the storage limit, a notification will appear and the command will be rejected. |
| What type of enforcement scenario is this applicable? | Project storage enforcement. | Project storage enforcement. |
| Is this live and being shown to customers today (as of Apr 20 2023)? | Yes | Yes |
| When will we stop showing these notifications? | When we roll out Group Namespace Storage Enforcement for the Free and then later Paid tiers |
When we roll out Group Namespace Storage Enforcement for the Free and then later Paid tiers |
| Who is seeing this? | All members of the impacted group/project. | Anyone using the CLI. |
| When are we showing this? | Customers who have used 75%+ of their allotted storage, will receive warning messages. When a customer has gone above their allotted storage amount 100%+ (> 100%, not >=),, they will receive a notification that their project is in a read-only state. |
Customers who have used 95%-100% of their of their allotted storage, will receive warning messages. When a customer has gone above their allotted storage amount 100%+ (> 100%, not >=),, they will receive a notification that their MR has been rejected. |
| How is this notification controlled? | We first check if we're enforcing via automatic_purchased_storage_allocation application setting (code) and then we check if the criteria is met. The Application Setting used to determine the limit is repository_size_limit (code). Currently the limit is 10 GB and can only be set to the whole GitLab instance. |
Same. See issue |
| Links | See issue and MR Screenshots |
See MR Screenshots |
Purpose: document what notifications customers can expect to see as part of the group namespace storage enforcement project. FAQ / docs.
| Question | Pre-Enforcement Banner Notification | Banner Notification | CLI | Emails |
|---|---|---|---|---|
| What are we showing? | In-app banner notifications that can be seen throughout the GitLab product that let customers know that we will start enforcing storage limits soon. They follow customers around in all pages under group, project, and user. |
In-app banner notifications that can be seen throughout the GitLab product that let customers know they are nearing their storage limits. They follow customers around in all pages under group, project, and user. |
Command line interface notifications about storage usage when git commands occur. If the push will send the group over the storage limit, a notification will appear. | E-mails when customers are nearing group namespace storage limits and when they are over storage limits. |
| What type of enforcement scenario is this applicable? | Group Namespace Storage Enforcement. | Group Namespace Storage Enforcement. | Group Namespace Storage Enforcement. | Group Namespace Storage Enforcement. |
| Is this live and being shown to customers today (as of Apr 20 2023)? | No | No | No | No |
| When will we stop showing these notifications? | These will stop after we have rolled out storage enforcement to the Free tier. Note: we will then deploy them again when we do storage enforcement for the Paid Tier. |
Never | Never | Never |
| Who is seeing this? | Owners and non-owners | Owners and non-owners | Anyone using the CLI. | Namespace group owners. |
| When are we showing this? | We are showing these starting 60 days in advance of Free tier storage enforcement. |
When group namespace storage enforcement begins, customers who have used 75%+ of their allotted storage, will receive warning banners. When a customer reaches or goes over their allotted storage amount 100%+ (> 100%, not >=),, they will receive a banner informing them that their group is now in a read-only state. Note: we haven't enabled the feature flags on production, once we do all users should start see banners once the usage criteria is met. |
Customers who have used 95%-100% of their allotted storage, will receive warning messages. When a customer reaches or goes over their allotted storage amount 100%+ (> 100%, not >=), they will receive a notification that their git command has been rejected. |
When group namespace storage enforcement begins, customers who have used 70%, 85%, 95% of their allotted storage, will receive warning e-mails. When a customer reaches or goes over their allotted storage amount 100%+ (> 100%, not >=),, they will receive an e-mail informing of them that their group is now in a read-only state and to purchase storage and/or decrease storage usage. |
| How is this notification controlled? | We check if the group has no subscription (code). Then we check if the group has not been marked for storage_limit_exclusion (code), then we check if their plan has a notification_limit (code) and if so we check if their consumed storage reaches or goes over the notification limit (code). The notification_limit will start high and will be gradually decreased until we get to the dashboard limit, controlled by the storage_size_limit application setting. |
We first check if we're enforcing (code), then if the criteria is met either for warning or error banners (code). We use application settings to enable the enforcement and the Plan Limit named storage_size_limit to check what's the storage quota included in the plan (code). Each plan will have a different limits |
Same. See issue | The controls are the same but the email trigger needs to be verified |
| Special Notes | For dismissal: - For now: can we allow for dismissal but have it re-appear ever 14 days - For later / closer to enforcement: we make the banner re-appear every day if dismissed. |
For dismissal: - Customer can dismiss banner but it will re-appear if they change thresholds (eg they jump from 70% of usage to 95% of usage) - The banner will become non-dismissable when usage is above 95%. |
||
| Links | See MR Screenshots |
See issue Screenshots |
See MR Screenshots |
See MR and issue Screenshots |
On GitLab.com, this feature is now available for all groups. For more information, see User cap for groups.
As of 2023-06-28, customers who have purchased a GitLab subscription through an authorized reseller (including GCP and AWS marketplaces) have access to the Customers Portal.
Please keep in mind:
List of features managed by the billing and subscription management group within the Fulfillment section.
Customers can renew their SaaS or Self-managed subscriptions using either auto-renewal or manual renewal. By default, subscriptions are set to auto-renew. Customers who are not eligible for auto-renew or do not want to auto-renew their subscription can manually renew their subscription through the Renew button on the subscription card in the Customers Portal.
As of 2023-01-21, almost all of the subscriptions enrolled in auto-renewal (identified in Zuora as Subscription.TurnOnAutoRenew = Yes) will be scheduled for auto-renewal and processed. Certain exceptions exist:
We will not attempt to auto-renew if:
Auto-renewal will fail if:
Accounts and Subscriptions excluded from auto-renewal:
Account.PO Required = Yes (customer notifies GitLab they have a “no PO, no Pay policy”, booking requirement and pre-billing).Account.Portal Required = Yes (customer notifies GitLab that they require invoices to be manually uploaded to a billing portal, and includes non-PO, PO, contract, or SOW).Account.Support Hold = Yes (customers are placed on support hold when accounts become >90 days past due without payment commitment).Account.Credit Hold = Yes (customers are placed on credit hold when any balance is written off to bad debt)There’s an automated process (Zuora Workflow) that sets Subscription.TurnOnAutoRenew__c to No for the use cases listed above.
With QSR, paying for the seat overages is easy to understand, saves precious time, and results in a fairer billing model for our customers. SaaS and Self-Managed customers have their seat usage reviewed on quarterly basis, and receive an invoice for any overages. Some customers may choose to opt out of QSR (via Contract amendment), in which case they will default to the existing Annual true-up process. Using operational data around seat utilization, we aim to automate as much as possible for the seat overage billing process. This allow us to:
Accounts and Subscriptions excluded from QSR:
Account.PO Required = Yes (customer notifies GitLab they have a “no PO, no Pay policy”, booking requirement and pre-billing).Account.Portal Required = Yes (customer notifies GitLab that they require invoices to be manually uploaded to a billing portal, and includes non-PO, PO, contract, or SOW).Account.Support Hold = Yes (customers are placed on support hold when accounts become >90 days past due without payment commitment).Account.Credit Hold = Yes (customers are placed on credit hold when any balance is written off to bad debt)There’s an automated process (Zuora Workflow) that sets Subscription.TurnOnSeatReconciliation__c to No for the use cases listed above.
Subscription.TurnOnSeatReconciliation__c variable is set to Yes.Subscription.ContractSeatReconciliation__c variable is set to Yes.How individual automated reconciliation works:
This functionality lives in Customers Portal and runs daily at midnight UTC. Please note that this process is shifted by 6 days for Self-Managed subscriptions, so that we have enough time to collect seat usage data from the instance.
TurnOnSeatReconciliation__c is equal to Yes.Automated seat reconciliation.As of 2023-05-22, SFDC Opportunities created for QSR have 2 new fields populated: QSR Status and QSR Notes. Here's a summary of what you can expect to see in these fields and suggested action for Sales Reps.
| QSR Status | QSR Notes | Stage | Suggestion Action | Additional Notes |
|---|---|---|---|---|
| Pending | Reconciliation record link (e.g.cust….gitlab.com/admin/r../12345) | 6-Awaiting Signature | No action | The QSR will be auto reconciled within 7 days. |
| Processed | Reconciliation record link (e.g.cust….gitlab.com/admin/r../12345) | Closed Won | No action | |
| Failed | Failed to amend subscription/ amount does not match latest preview | 6-Awaiting Signature | AE to set to Closed Lost. | The QSR has become redundant, since the customer purchased additional seats after the QSR has already been created. |
| Failed | multiple_rate_plans | 6-Awaiting Signature | AE to contact customer, advising that extra seats must be purchased. | QSR cannot be processed as the customer has multiple rate plans on the subscription. |
| Failed | - card was declined - card does not support this type of purchase - card number is incorrect - expiration year is invalid - expiration month is invalid - has insufficient funds, or any other payment_declined/ transaction declined error. |
6-Awaiting Signature | Optional: AE to contact customer. | Customer will receive a notification that their card was declined, together with the steps they need to take to resolve. Once the customer updates their payment method, QSR will be re-processed. |
1 for looking up the QSR status.reconciliations_disabled reason code.
The target audience is the internal GitLab team, and covers the admin panel of the Customers Portal. 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.
File an access request for customers.gitlab.com/admin/ (example access request) to get access.
Once access is granted, either go to customers.gitlab.com/admin/ and click “Sign in with Okta” or go to your Okta App and look for the Customers Portal App.
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.
Customers in the admin panel.Refresh or hit Enter on your keyboard to initiate the search.Add filter.Refresh again.Note: The updated customer details are synced to the matching Zuora BillTo/SoldTo contact.
Customers section.First name, Last name, and Email.Save.Deactivate login for Customer
If you want to update the physical address of the customer or other details, you need to impersonate the customer.
Impersonate.Customers section.Login activatedSave.The customer is now blocked from accessing their Customers Portal account.
Note: That does not affect the ability to access their GitLab.com account.
Zuora Subscriptions.Note: Owed seat = Max seats used - seats in subscription.
History.Note: If a user is admin:[email protected] in a log line, that indicates a change on the customer's record that was done via the admin panel.
With the one-time sign in url a customer is able to directly sign in to their Customers Portal account. This works for customers that have or don't have a GitLab.com account linked to their Customers Portal account.
Customers section.One time sign in url.Note: A new one-time sign-in link will be generated after the previous one has been used. The one-time sign in url does not log the customer into their GitLab.com account, only their Customers Portal account.
If a customer has a connected GitLab.com user account, then a list of namespaces will show with relevant information including current plan.
Note: This only works as long as the customer's access_token is valid.
The list of namespaces are:
OwnerThe billing account is the representation of a billing entity which is mostly connected to an organization. The billing account has data associated to Zuora, SFDC, important company information and all billing account memberships.
Billing accounts in the admin panel.Refresh or hit Enter on your keyboard to initiate the search.Add filter.Refresh again.History.Show you will find the Bill_To and Sold_To contact.Note: There can only be one Bill_To and one Sold_To contact associated to a billing account. They can be the same contact.
List Invoices.Note: This view is also accessible for CDot admins with read only permissions.
List Payment Methods.Note: This view is also accessible for CDot admins with read only permissions.
Zuora Subscriptions.Note: Owed seat = Max seats used - seats in subscription.
The billing account contact represents the billing account's contact details that are used to send invoices, notices, etc. Other information such as location based data is used for tax related calculations. A contact can be a Bill_To or a Sold_To contact (or the same if applied that way).
There can only be one Bill_To and one Sold_To contact for a billing account. It is possible to use the same contact information (e.g. email address) over multiple billing accounts.
Billing account contacts in the admin panel.Refresh or hit Enter on your keyboard to initiate the search.Add filter.Refresh again.Billing account contacts section.email address).Edit.Save.If a Zuora contact is not available in CustomersDot, but in Zuora, the contact can be added through the admin panel.
Billing account contacts section.+ Add New.Zuora contact ID.Save.This will create a contact record in CustomersDot that is in sync with Zuora. This directly assigns all the billing account contact attributes from Zuora to the created contact.
Note: It is possible that a contact doesn't have a Billing account attached in CustomersDot (e.g. if it does not exist in Customers Portal).
History.The billing account membership defines the relation between a customer and a billing account. The customer will be able to see the subscription in their Customers Portal account if there is a billing account membership with an active subscription.
Currently a customer can only have one billing account membership.
Adding a new billing account membership between a customer and a billing account results in the customer becoming a subscription management contact.
Billing account memberships section.+ Add new action.Save.Note: We display the Zuora account name and Zuora account ID (in brackets) in the list of billing accounts.
Billing account memberships section.x Delete action.Yes, I'm sure.Billing account membership successfully deleted success notification.GitLab Groups.Renew Trial button.Update. Warning: Do not change the date to a date prior to today's date in UTC timezone.Licenses section.The details of a license contains the following information:
The following process allows you to view Service Ping usage data for all servers with a given license installed.
Licenses section.Lookup hostnames under Hostnames with this license at the bottom of the screen. This will open version.gitlab.com
Usage Ping Last Checked On column to determine which entries contain recent usage ping data.This video tutorial walks through an example of how to find the license details for a particular customer.
The License seat links page in CustomersDot provides visibility into current usage and version data for Self Managed customers on Cloud Licensing or Offline Cloud Licensing. One record is created for each data sync, representing point-in-time data that can help to show changes in usage over time or the date that a customer exceeded a certain seat count. For Cloud License enabled customers, a record will be created once per day as part of License Sync. For Offline License enabled customers, a record is created whenever the customer manually submits their usage data to GitLab, which is requested at a cadence of once per month.
On this page, you can search by Company, Subscription name, or Hostname to see all license usage for a specific customer. The following metrics are reported with each sync:
License user count - the number of seats purchased as part of the customer's subscriptionBilllable user count - the current count of active, billable users at the time of the syncMax historical user count - the highest value of billable users recorded during the current subscription termGitLab version - the version of GitLab at time the customer is on at time of syncOrders section.Reconciliations section.It provides an understanding of who and how many trials they have requested, when, and for how many users. Self-Requested Trials are not easily reported.
It's the only way to search for usage ping data if the server name is not known. For example a customer acmeinc.com uses acmeinc.ninja. There is no straightforward way to find this.
It is important to know who received the license for further troubleshooting as CustomersDot is the SSOT for license information.
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 MonetizationLicense won't activate due to a true-up or seat overage mismatch
What type of connection does the GitLab instance require to activate Cloud Licensing?
The instance would need to have a 443 port connection to customers.gitlab.com in order to activate. This is also used for license synchronization as outlined in our documentation here.
Can customers opt out of telemetry or sharing license sync data?
The data transmitted with Cloud License is covered in this documentation. In short, it's aggregate user counts and some license metadata. This data is required for Cloud Licensing. It's intended to only include necessary data to support our needs for administering a license, supporting future renewals, supporting add-ons, and any seat reconciliations.
You can look at sample code that generates the counts by searching for subscription events in metrics.gitlab.com.
What is Operational vs Optional Data?
Our service usage data primarily aggregate counts from your instance (e.g. counts of issues or MRs) and is sent to GitLab on a weekly (or slower) cadence.
Can a customer send subscription data ad-hoc, while keeping their GitLab instance airgapped/not connected to the internet?
Please see Offline Cloud Licensing for more information.
Across 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.
If you have an urgent Fulfillment need that is not being prioritized by Fulfillment's regular prioritization process due to competing priorities, and it is both important and urgent, please work with your division's leadership for escalation. The first step can be an async discussion involving Fulfillment leadership (as of now include ofernandez2). Situations in which competing company-priority projects would need to be reprioritized to accommodate your request may require escalation to GitLab's e-group.
Team members in our Sales and Customer Success groups should escalate first via the Top ARR Drivers meeting for cross-team leadership visibility and prioritization. Simply add your item to the list of asks (link in the meeting agenda) for discussion.