Welcome to the Sales Order Processing page!
This page outlines the Quote to Cash process. Topics include account and opportunity creation, quote configuration and approvals, opportunity booking requirements, and closing an opportunity. This page will also cover common questions that may arise after an opportunity has been closed.
Salesforce Reports and Dashboards
Frequently Used Handbook Pages
Channelaccount, it should be created via the partner creating an account in Impartner or manually via Channel Operations. Sales should not create Channel accounts and should Slack #channel-programs-ops.
The following is a high level guide to quote types and important quote information to note before processing an order. Review the Go To Market Handbook for opportunity creation instructions, and opportunity management guidelines. Review the Deal Desk Quote Configuration Guide for written instructions and video tutorials specific to each quote type.
Reference Link: Starter/Bronze End of Availability + Tier Re-naming Quoting Guide
There are 4 different types of quotes - New Subscription, Amend Existing, Renew Existing, Cancel Existing. Quote type will typically align to opportunity type. The correct quote type must be used for each opportunity.
|Quote Type||When to Use|
|New Subscription||Any New Subscription Term OR Renewal where customer is changing term length|
|Amend Subscription||Use this quote type to add users, true up, or change product tier during the current subscription term. (NOTE: True-ups added before renewal date will not eliminate true-up requirement for the same term which will be charged at renewal. True-up is a backward looking one-time fee that is always recognized at renewal. License add-ons during the term will eliminate the future true-ups to be charged at renewal.)|
|Renew Existing Subscription||Customer is at the end of their current term and wants to renew for the same term length|
|Cancel Existing Subcription||This is used for a Contract Reset - please chatter on the opportunity level for assistance with contract resets|
GitLab uses 5 quote templates to support each type of transaction. The following quote templates are available on all quotes (New Subscription, Amendment, Renewal). The correct quote template must be used for the deal as there is acceptance language specific to each route to market.
|Standard Order Form||Most quotes, including alliance marketplace transactions, EDU/OSS/YC, or Customers with an Existing Agreement (MSA) in place|
|Standard Order Form (Hide Discount)||Hide the Discount and List Price Column for Direct Deals. Otherwise Identical to the Standard Order Form|
|Authorized Reseller Order Form||Authorized Reseller Transactions|
|MSP Order Form||Managed Service Provider Transactions|
|Distributor Order Form||Distributor Transactions|
Pre-Approved Legal Language can be added to each quote. Selections are listed as Toggle Fields on the quote object.
|Annual Payments||Annual Payment Language will populate in Payment Details on the Order Form PDF|
|Customer Reference Language||Customer Reference Language will populate in Notes Section of the order form|
|Add Quarterly True Up Language||Standard Quarterly True Up Language will populate in the Notes section of the Order Form *This language permits manual quarterly add-ons, and can only be used when SuperSonics Quarterly Reconciliations do not apply|
|Remove Signature Block||Signature Block will be removed. Use for customers with Existing Agreements (MSA)|
Quotes run through an automated logic check to ensure that the selected Legal Language can be added to the order form. This logic check reviews characteristics of the quote, including populated fields, route to market, and products being sold to ensure added language does not conflict with the deal structure.
In some instances, you will make a selection that will require additional review and approval before an order form can be sent out. This is typically for complex/non standard deals. If you make a selection that cannot be accommodated, you will see an error message. Remove the selection and move forward with the quote. If you are confused, or need assistance, tag Sales-Support in chatter and provide a screenshot of the error you're experiencing.
Additional Line Items Displaying on the Quote: If you construct a quote and notice that there is an additional line item displaying on your quote, know that this is the result of a known Zuora bug. The only current workaround in place is to recreate the quote from scratch by clicking the
New Quote button and follow the New Quote creation flow.
If your quote requires any special, non-standard edits, or if you have questions regarding standard quotes, you are encouraged to send a Chatter message to
@Sales-Support on the SFDC Opportunity record for assistance.
Please provide as much detail as possible, including links to relevant records, dates, user counts, and other applicable information. It is the Opportunity Owner's responsibility to create all standard quotes, unless they are complex custom deals or one of the scenarios listed below.
Deal Desk will review any quote to ensure accuracy and completion. Standard Quotes are expected to be created and managed by the opportunity owner or ISR.
For Non-Standard/Complex Quote requests, the Deal Desk team will assist the opportunity owner in creating the quote correctly. Some examples of these complex scenarios include:
Please review the Deal Desk Quote Configuration Guide for more information. Note that the above list of non-standard quote elements is not exhaustive. If you encounter a non-standard need that is not listed on this page, please chatter @Sales-Support on the SFDC Opportunity in question for evaluation and assistance.
If a customer requests Tax removed from the quote, they need to provide a Valid Tax Exemption Certificate. Please attach this to the opportunity.
VAT IDfrom a quotes
VAT/Tax ID- If you attempt to update the VAT ID and it is overwritten please chatter for support on the related opportunity
Follow the standard process for quote creation. The Quote Object does not need to be approved before generating a Draft proposal.
GitLab's Cloud Licensing experience allows for the activation and provisioning of Quarterly Subscription Reconciliation and Auto-Renewals, which apply to both SaaS and Self-Managed Subscription plans. In addition, the Cloud Licensing experience introduces Operational Data.
The SuperSonics Billing and Subscription Management Experience applies to all eligible new customers and any eligible existing customers at their next renewal, assuming they are running GitLab 14.1 and have opted into the new terms. To determine whether your customer is eligible for Auto-Renewal, Quarterly Subcription Reconciliation, and Operational Data, review the Availability Matrix and read the Customer Availability Summary Table section of the Field Team FAQ. Please direct any questions regarding SuperSonics eligibility to the #pnp-changes-field-questions Slack channel.
Specific fields have been added to the Quote object to support SuperSonics Functionality. These fields will appear on two sections of the quote object.
This section contains a number of fields that show the current state of each SuperSonics feature (Auto-Renewal, Quarterly Subscription Reconciliation, Operational Data). The "Contract" fields show whether the customer is contractually eligible for the related feature. The "Turn On" fields show whether that feature is actually enabled on the subscription.
For customers who are not exempt, the default values will be "Yes" for all fields. For customers who are exempt based on the Availability Matrix, the default values will be "No" for all fields.
|Field Name||Field Description|
|Contract Auto-Renewal||(Yes/No) Shows whether customer is contractually eligible for Auto-Renewal|
|Contract Quarterly Reconciliation||(Yes/No) Shows whether customer is contractually eligible for Quarterly Subscription Reconciliation|
|Contract Operational Data||(Yes/No) Shows whether customer is contractually eligible for Operational Data|
|Turn On Auto-Renewal||(Yes/No) Shows whether Auto-Renewal is enabled for the subscription|
|Turn On Quarterly Reconciliation||(Yes/No) Shows whether Quarterly Subscription Reconciliation is enabled for the subscription|
|Turn On Operational Data||(Yes/No) Shows whether Operational Data is enabled for the subscription|
|Turn On Cloud Licensing||(Yes/Offline/No) Shows whether a customer activated with Cloud Licensing, Offline Cloud Licensing or a Legacy License File|
Note: there is no contractual field for Cloud Licensing as sending Cloud License Subscription Data is part of the standard GitLab's standard Subscription Agreement.
Cloud Licensing Fields
The fields in this section enable contractual opt-outs for each SuperSonics feature. If you wish to request an opt-out of Auto-Renewal, Quarterly Subscription Reconciliation, or Operational Data, you must check the applicable box on the quote object. Checking these boxes will trigger an approval workflow, and will ultimately insert legal language onto the Order Form that opts the customer out of the related feature. If any of these boxes are checked, and the opt-out is approved, the related Zuora Fields will reset to "No."
|Field Name||Field Description|
|[Cloud Lic] Add Reconciliation Opt Out||(Checkbox) Opts customer out of Quarterly Subscription Reconciliation|
|[Cloud Lic] Add Auto-Renewal Opt-Out||(Checkbox) Opts customer out of Auto-Renewal|
|[Cloud Lic] Add Operational Data Opt Out||(Checkbox) Opts customer out of Operational Data|
|[Cloud Lic] Add Cloud Licensing Opt Out||(Picklist) Opts customer out of Cloud Licensing to an
The below process applies to any existing customers with an active subscription who have QSR enabled, and who exceed their billable user count during the subscription term.
During the Sales process, a customer who would not otherwise be exempt from Auto-Renewal, Quarterly Subscription Reconciliation, Cloud Licensing and/or Operational Data may request to disable one or more of these features. Every opt-out will require approvals, as noted in the Deal Approval Matrix. If an opt-out is requested and approved, upon Closed Won the related feature will be disabled for the subscription in question.
Steps to Request an Opt-Out:
During the Sales process, there may be a need for Sales to "pause" an upcoming Auto-Renewal or Quarterly Subscription Reconciliation while negotiating with the customer. Every pause will require approvals, as noted in the Deal Approval Matrix. If a pause is requested and approved, that feature will be temporarily disabled for the subscription in question until the next renewal occurs. A pause is not possible for Cloud Licensing.
Steps to Request a Pause:
The following resources pertaining to the SuperSonics Billing and Subscription Management Experience are for internal purposes only.
There are several scenarios where you might need Legal assistance on an opportunity. Thouroughly review the information below. You can also learn more about the team and their scope by visiting their handbook page or by checking out these best practices on how to Collaborate with Legal.
For general questions related to the customer, please open a case with legal. f Within the Customer Opportunity:
All contracts / Agreements that require GitLab countersignature will be digitally stamped by a GitLab Contract Manager or legal representative. This is done to ensure and signify that the document has been reviewed and vetted by GitLab legal, and may be signed.
Receiving a stamped contract / Agreement
NOTE: In very few circumstances, a Customer may refuse to use a PDF with GitLab Legal stamp for signature, due to their electronic signature tool(s). If this is the case, please supply the Agreement to be signed, and notify the individual(s) with signatory authority with the following information: (I) Overview that the Customer toolset prohibits the use of our GitLab Legal stamp, and (II) A link to the SFDC Case where the Contract / Agreement was negotiated. With this information, the GitLab individuals with signatory authority will be able to compare the requested version for execution, and the latest version approved by Legal in the case.
The signatory Authorization Matrix can be found here: /handbook/finance/authorization-matrix/
Process for Signature Once negotiations are completed, and the digital stamp has been affixed to the final version of the contract / Agreement:
To add our SaaS SLA Addendum to an order form, please open a Legal case after all approvals have been secured for your quote.
This tool checks Account information against various databases to ensure no matches, Accounts are checked repeatedly to ensure GitLab's continued compliance
If the Opportunity meets the dollar thresholds:
A presentation overview of the process to engage GitLab Legal can be found HERE
A video tutorial can be found HERE
You may contact Legal directly in Slack via #Legal
Within the Customer Opportunity:
At this time, the Contract Request Case will be marked as "Closed". Follow the below steps to initiate "Contract Review" of the Customer edits.
Within the Customer Opportunity:
All communications, and versions of Agreements, should be kept in the Contract Request Case
Within the Customer Opportunity:
At this time, the Contract Request Case will be marked as "Closed". Follow the below steps to initiate "Contract Review" of the Partner edits. Please note, ANY DOCUMENT THAT REQUIRES GITLAB SIGNATURE MUST HAVE A GITLAB LEGAL STAMP (SEE OBTAIN SIGNATURE)
After both parties have signed the contract, complete these steps:
Contract Statusfield to show “Active”;
and fill in theContract Term (months)` field, if applicable. The End Date will auto-fill based on the number you enter. Do not put the end date in the Termination Date field.
Our experience shows that using a prospect's form agreement is expensive and, more importantly, time consuming. Deals in which we use the customer agreement take on average 60 days longer to close than if completing using our standard subscription agreement with changes as requested by customer counsel. The arguments in favor of using our agreement are as follows:
Despite the overwhelming arguments in favor of using the GitLab form some prospects insist on using their form agreement. GitLab will accommodate such requests with the following assumptions:
GitLab will not accommodate changes to our standard forms for deals under $25,000.
If GitLab agrees to customized subscription terms with a customer, all quotes, SOWs, POs, etc. must reference those customized terms and not the GitLab standard terms listed on our website.
To update the terms of a quote, follow these steps:
If custom terms need to be added to a quote, notify the Deal Desk team. The team will review and determine if we can fulfill the request or if we will need to work with Legal. Please check out the Legal handbook page for more information on how to open Legal cases, responding to Vendor Set Up forms, or questions on GitLab's Standard Agreement.
For assistance with a Subscription Transfer Agreement please open a Legal Request. Please provide details as to the Account which purchased the Subscription–Including the original Opportunity–and the updated Account that is requesting to be assigned ownership.
GitLab provides free licenses to qualifying entities through the Community Programs: GitLab for Education Program, GitLab for Open Source Program and GitLab for Startups Program. All applications to these programs are routed through the Community Programs applications automated workflows. Only Community Relations team members should handle these applications and opportunities because the team verifies program requirements before issuing/renewing licenses and these opportunities are handled differently since the opportunities are free.
firstname.lastname@example.org. Then reassign the lead to the appropriate program manager.
The following is intended as a guide for Opportunity Owners who need to submit a quote for approval for discount or payment terms. If the quote requires approvals before sending to a customer, there will be a red stop sign flagged with "Additional Approvals Required".
Prior to generating a standard (non-draft) quote to deliver to a client or prospect in PDF format, any non-standard elements (discounts, unique payment terms, and other items found in the matrix) must be approved. The following steps outline the process for how to correctly submit a quote for approval. This approval flow follows the criteria in our approval matrix for approvers.
Submitter Commentson the quote before you submit for discount and terms approval. Please provide as much detail as to why you are requesting discounts or other terms that require approval.
Submit for Approvalbutton on the quote screen.
Required Quote Approvals.
If a discount has been applied to a quote pursuant to a signed agreement between GitLab and the customer, additional approvals are not required. Tag Sales-Support in chatter with a link to the signed agreement to request that the quote approvals be overridden.
Under the GitLab Partner Program, signed Channel Partners are granted specific, contractual discounts depending on the product, Partner Deal Type, and the Partner Engagement type. This information is automatically captured at the opportunity level. For more information, review the SFDC Field Definitions and the Partner Program Discount Tables.
Only GitLab-authorized partners who have completed one sales certification may transact a GitLab order.
Quote Approvals: The Quote Approval module identifies channel deals (subscription deals only) and manages the necessary approvals automatically. To request approval on a quote, follow the steps above: Standard Quote Approval
Channel Approvers: More information regarding regional Channel Approvers can be found here.
In the event that you require escalation for an approval request, please reach out to Deal Desk. Deal Desk will override the approvals as applicable or help seek approvals from necessary parties.
The quote approval module and approval workflow outlined above does not apply to Public Sector opportunities. For more information on opportunity requirements for Public Sector, check out the Public Sector Opportunity requirements.
The quoting system will provide visibility into the correct programmatic partner discount. On the quote object, each line will be stamped with the “Partner Programmatic Discount.” This field is populated by the system, but does not provide any actual discount to the quote. In order to apply the discount to the quote, this amount should be entered into the “Discount %” field on the edit products page. To confirm that the discount is correct, go to the opportunity and look at the Partner Deal Type, and then look at the Partner Engagement. Next, reference the appropriate Partner Program Discount Table. The product, Engagement, and Deal Type will allow you to find the proper discount in the matrix..
1. New - First Order
1. New - First Order
If an opportunity meets the criteria listed above, a minimum of $15,000 in Professional Services must be attached to the opportunity. Services can be attached using one of two methods:
If an opportunity meets the criteria listed above, but does not have a Professional Services value of $15,000, or does not have a linked opportunity with a Professional Services value of $15,000, the quote will require approval to sell the subscription deal without the minimum Service Attach.
Summary: Waived True-Ups require executive approvals and may negatively impact Net ARR.
Complex deals require approval via chatter. Use the applicable template below to request approvals. You will need to tag the approvers outlined in the Deal Approval Matrix. For standard quotes please submit the quote for approval, do not request additional approval in chatter.
If you are Requesting Approval for New Subscriptions:
Proposed Subscription Terms: Product Tier: Quantity: List Price/User/Year: Discount: Effective Price/User/Year: TCV: Contract Start Date: Contract End Date: Payment Terms: Non-Standard Contract Terms: Route to Market (Direct/Channel):
If you are Requesting Approval for Add-Ons/Upgrades/Amendments/Renewals:
Existing Subscription Terms: Product Tier: Quantity: List Price/User/Year: Discount: Effective Price/User/Year: TCV: Contract Start Date: Contract End Date: Payment Terms: Non-Standard Contract Terms: Route to Market (Direct/Channel): Proposed Subscription Terms: Product Tier: Quantity: List Price/User/Year: Discount: Effective Price/User/Year: TCV: Contract Start Date: Contract End Date: Payment Terms: Non-Standard Contract Terms: Route to Market (Direct/Channel):
The following is intended as a guide for quote approvers.
According to our matrix for approvers there are a number of reasons that you may be involved in approving an opportunity. Please make sure that you are familiar with the scenarios that you may be involved with.
NOmust the first line of the email message. Any other terms in the first line of the reply will result in an error.
If you are a quote approver and will be out of office, you will need to notify Deal Desk and set up rerouting of any quote approvals.
Note: If you are a Delegated Approver and are not receiving approval emails, contact sales-support for assistance.
If a quote has multiple product tier SKUs (ex. Premium AND Ultimate), this requires additional approvals perour matrix.
If a quote has a green circle at the top of the page, flagged with "Approved", it's ready to send to the customer! Note, a PDF of a quote cannot be generated until the quote has been approved.
Generate PDF Doc. The document will be saved as an attachment in the Notes and Attachments section in the opportunity record.
The first time you login to DocuSign from SFDC, you will be required to Authorize access and log in. Please follow these steps when prompted:
After clicking on the “Send with DocuSign” button, you will be prompted with this screen. Select “Authorize” to continue.
On the next screen, login to your DocuSign account. Enter your GitLab email address and click continue. This will automatically log you in with OKTA.
To send a digital copy of an Order Form to the customer via DocuSign:
From the Opportunity, select the “Send with DocuSign” button.
From the Opportunity level in our Salesforce instance, you can view the status of a document by hovering over the “DocuSign Envelope Status.
Note: You must log in with your DocuSign credentials to access these educational resources.
You've created the quote, received all necessary approvals, and the customer has signed the Order Form. Awesome! Time to submit the opportunity for booking. Hold up! Be sure to review all required fields listed below before submitting the opportunity for approval.
All opportunities must meet all requirements outlined below to be processed. Exceptions are rare and not made lightly and often require several approvals. Your opportunity will be rejected if it does not meet booking requirements.
There are unique requirements for different methods of selling GitLab. Please see the general summary presentation of our booking requirements here.
Review the drop down below related to your order type.
|DIRECT Subscription Purchase Requirements|
|Signed Order Form||Required||Exceptions:
a) Signed MSA (Subscription Agreement) is in place.
b) If the customer does not have an MSA but refuses to sign our Order Form, we need:
- PAO and Legal approvals to accept the correctly issued PO without signed Order Form AND the following confirmation:
- Reason(s) why the Customer is refusing to execute the Order Form; and
- Documentation (i.e., email thread) of the customer refusal.
In the above cases we need a correctly issued PO document (please see the details below) which does not include any terms and conditions which conflict with the Order Form and
|Signature||Required||Signature with full name and signature date|
|Correct Order Form Attachment Format||Required||Full pdf document with all the pages without manual edits (only PO nr, VAT ID manual edits can be accepted)|
|PO||Required in some cases||PO document in pdf is required if the customer previously provided a PO document for any purchase.
If the customer won't provide a signed Order Form (see details above), the PO must contain the following details and we need to generate an Order Form without signature block:
- correct GitLab entity,
- the Quote No. found within the applicable Order Form,
- payment terms matching the Order Form,
- currency: USD,
- line item descriptions that match the Order Form (without signature block)
- visible PO number
- matching subscription term
If the customer signs our Order Form but previously they provided a PO doc as well but now they don't want to issue an PO document, they need to also provide an email confirmation that they will accept our invoice without a PO number.
A Direct Deal is a deal between GitLab and the Customer. There are no Distributors/Partners/Resellers involved at any stage of the process. IMPORTANT NOTE: At this time, we cannot accept Direct Deals through India. All opportunities with customers based in India must go through a reseller or partner.
For all Direct Deals (Sales Assisted Opportunities) the customer must sign the Approved Order Form. Order Forms without a full customer signature (Name, Title, Company, Date) will be rejected by Deal Desk.
GITLAB FIRMLY REQUIRES ORDER FORMS TO BE FULLY EXECUTED. CLICK HERE IF CUSTOMER REFUSES TO SIGN ORDER FORM
Prospect/Client paid via Credit Card through the web portal- In this scenario the applicbale GitLab terms are agreed upon at the time of the purchase.
An Order Form (which includes a Quote No.) is required in order to confirm products purchased, # of seats, term, and pricing. An Order Form is also needed to confirm the Prospect/Client agrees to the terms and conditions referenced in the Order Form.
Discuss with customers / prospects, from on the onset, that signature will be required.
If an Order Form is executed by the Customer, GitLab review of a submitted purchase order will be minimal, the purchase order must include: a) the correct GitLab entity, b) the Quote No. found within the applicable Order Form, c) payment terms matching the Order Form, and d) line item descriptions that match the Order Form.
If the Customer's purchase order DOES NOT include any legal or finance terms, as determined and approved by GitLab finance and legal, and includes a) the correct GitLab entity, b) the Quote No. found within the applicable Order Form, c) payment terms matching the Order Form, and d) line item descriptions that match the Order Form (without signature block), GitLab may accept the Order Form and purchase order without changes.
Remove all references to such terms found within the purchase order; and/or
Insert the following language into the supplied PO: "Notwithstanding any of purchaser's standard terms and conditions set forth or referenced herein, this PO is governed by the GitLab Subscription Agreement, GitLab Professional Services Terms (as applicable) or other such software license and/or services agreement negotiated by the parties"
The purchase order in either instance (3&4) must also include: a) the correct GitLab entity, b) the Quote No. found within the applicable Order Form, c) payment terms matching the Order Form, d) line item descriptions that match the Order Form (without signature block)
|RESELLER Subscription Purchase Requirements|
|Signed Order Form||Not required||Exception: if the reseller cannot provide a PO document and wants to sign our Order Form, the reseller Order Form with signature block can be selected in the quote template section of the quote object.|
|Signature||Not required||If the reseller chooses to sign our reseller Order Form, signature with full name and signature date are required.|
|Correct Order Form Attachment Format||Not required||Complete pdf document with all the pages without manual edits (only PO nr, VAT ID manual edits can be accepted)|
(however reseller can sign the Order Form and in that case we don't need a PO document)
|If the reseller won't provide a signed Order Form, the
PO document in pdf must contain the following details and we need to generate a reseller Order Form without signature block:
- correct GitLab entity,
- the Quote No. found within the applicable Order Form,
- currency: USD,
- payment terms matching the Order Form,
- line item descriptions that match the Order Form (without signature block),
- matching subscription term,
- visible PO number
An Authorized Reseller, Distributor, or MSP is an approved partner with an active contract with GitLab in place. For opportunities where an any of these partners will purchase and resell to an End User:
Accepted Atfrom the customer's previous EULA. Then insert the following into the quote: "By accepting this quote, you, and the entity that you represent (collectively, “Customer”) unconditionally agree to be bound by the terms agreed to in EULA
Tokenpreviously accepted on
AWS Private Offer Transactions have a unique process flow, from quoting to opportunity approval. If your customer has chosen to transact via AWS, please note the following:
Requirements to Close Deal:
Closing the Deal:
GCP Private Offer Transactions have a unique process flow, from quoting to opportunity approval. If your customer has chosen to transact via GCP, please note the following:
Requirements to Close Deal:
Closing the Deal:
IBM OEM Transactions have a unique process flow, from quoting to opportunity approval. If your customer has chosen to transact via IBM, please note the following:
Opportunity Management (DRI = Sales):
Example Opportunity: https://gitlab.my.salesforce.com/0064M00000ZFzVI
Notification, Quoting, and Requirements to Close Deal (DRI = Alliance Operations):
Closing the Deal:
Public Sector opportunities have specific requirements that fall outside of the standard opportunity booking process.
A copy of the Distributor PO to GitLab must be attached to the opportunity. The Account Manager or ISR will confirm that all details on the PO match the Quote before submitting the Opportunity for approval.
After the ISR or Account manager confirms the Distributor PO is correct, a quote object will be created on the opportunity to match the Distributor PO to GitLab.
Review the Professional Services handbook page for in-depth information on Professional Services and the Deal Desk handbook page for the details of PS quote creation.
Professional Services Opportunities Only - If the SOW outlines a split payment schedle, only one opp is needed to book the order. We do not use multiple opps with PS opps requiring separate payments.
This policy dictates the timing of opportunity closure for all sales-assisted deals. The purpose of this policy is to ensure forecast predictability and proper revenue recognition.
Do I have to wait to submit my opportunity for approval?
My customer is waiting for their license key (self-managed) or provisioning email (SaaS). When will they receive their entitlements?
Under the Bookings Policy, opportunities must be submitted for approval by 11:59 PM Pacific Time on the last calendar day of the fiscal quarter to be booked within that same quarter. At the time of opportunity approval submission, such opportunities must meet all documented booking requirements to be booked within the quarter (including an enforceable agreement). If an opportunity is submitted for approval by 11:59 Pacific Time on the last calendar day of the fiscal quarter, but upon review the Order Management and/or Billing Teams conclude that the opportunity does not meet all booking requirements and is rejected, that opportunity will not be booked within the quarter that has just ended.
In the event that a deal meets all booking requirements and is submitted for approval by 11:59 Pacific Time on the last calendar day of a fiscal quarter, but is not reviewed by the Order Management and Billing Teams until the next day, that opportunity's close date will be backdated to the previous quarter upon final approval.
Deal Desk will review the start date on all opportunities at time of booking. The following scenarios are firm guidelines for accepting orders where the Subscription Start Date is in the past.
New Business Opportunity Customer procurement cycles can take time. A start date on a quote may be in the past if the procurement cycle took longer than expected.
All Closed Won and Closed Lost opportunities closed in a given month will become locked for editing on the tenth day of the next month. Any requested edits to opportunities closed in a locked accounting period will require review and action by the Senior Manager, Deal Desk or the Senior Director, Sales Operations.
Certain customers require that invoices submitted to them include a Purchase Order (PO) number. For these customers, a PO is required for opportunity closure, with limited exceptions. This policy is supplemental to the other booking requirements listed on this page. It does not replace any other booking requirements.
If there is a PO document and customer wants GitLab to add the PO nr to the invoice, we cannot do that without reviewing the PO document (unless there is no PO document issued)
Customer POs should be remitted to PO@gitlab.com (Direct Deals Only)
How can I determine whether a customer requires POs?
For new customers:
New business transactions for net new customers will require validation from the customer. Prior to closing a new business deal, Sales should validate with the customer whether they will issue a PO for the transaction and provide this information upon submitting the opportunity for approval. In addition, Sales should confirm with the customer whether there are any related special billing requirements prior to deal closure.
For existing customers:
This information can be reviewed in several places within Salesforce:
How does GitLab know that a customer requires POs?
If a PO is not provided during the booking process, customers who require POs will typically notify the Billing team of their requirement once an invoice has been issued. In many of these cases, the invoice is rejected and Billing works with the customer to obtain their PO and manually reissue the invoice with the PO number included. The Billing team then updates Zuora to denote the customer's PO requirement.
Why does the customer PO requirement matter?
If a customer requires POs, they will typically reject any invoice sent to them that does not include a PO number. Additional billing and collection efforts become required to engage with the customer, to obtain the PO, and to manually issue a new invoice once the PO has ultimately been received. In addition, this scenario often produces significant delays to cash collection.
What if "PO Required" = "YES," but the customer states that they do not require a PO?
If the customer does not require a PO for a specific transaction, on the opportunity please attach the customer's written confirmation stating that they will accept the invoice without PO number reference. If all other booking requirements are met, the opportunity will be closed without a PO attached and the invoice won`t contain a customer PO number.
If the customer does not require a PO for any transaction, attach the customer's written confirmation to the opportunity. If all other booking requirements are met, the opportunity will be closed without a PO attached. In addition, the Billing team will update "PO Required" to "NO."
What if "PO Required" = "YES," and the customer has provided a PO number but not a PO document?
What if the customer requires a PO and the PO is delayed, but all other booking requirements are met?
If "PO Required" = "YES" and the customer's PO will be provided to GitLab at a future date, the opportunity will be held for booking until the PO is provided by the customer. Exceptions will only be made at quarter end (see below).
What if the customer requires a PO and the PO is delayed, but all other booking requirements are met and the customer's license grace period is about to end?
If the customer's license has expired, and the customer's grace period is nearing its end, please open an Issue to request a grace period extension for the related license. A grace period extension will prevent the customer from losing functionality while the opportunity is pending approval due to a delayed PO.
End of Quarter Exceptions
If "PO Required" = "YES" and the customer's PO will be provided to GitLab at a future date, exceptions will be considered at quarter end if the following requirements are met:
Note: If an exception is granted and the PO is not received within 10 days, on the 11th day the opportunity will be decommissioned, reversing all credit given for the booking.
When you have reviewed all opportunity requirements and have met all necessary booking requirements, please submit the opportunity for approval.
NOTE - Orders will be processed as long as the Quote Start Date is within 15 calendar days from date of submission. If the Quote Start Date is more than 15 days out, Order Management will approve and update the close date to the earliest date that the opportunity can be booked. Only on or after that date will the Billing team review the opportunity for final booking. For more information, review the Bookings Policy.
To view the status of an opportunity after it has been submitted for approval, review the 7-Closing Stage Dashboard.
The opportunity closed! Congrats! Wait… my customer still has questions! Here are some of the most common questions that come up after an opportunity has closed… and how to resolve them.
Licenses (Self-Managed) and Provisioning Details (SaaS) are automatically emailed to the Sold To contact entered on the quote.
Notes on License Timing:
Licensing emails sent to customers are captured and stored in Salesforce as an Activity against the Contact record. This activity will also be related to the Account record, and can be found under "Activity History" list on the Account level.
Look for Task title:
Email: Your GitLab License File of
Email: Your GitLab Activation Code
Check out our License & Renewal Workflows page
On this page you can find answers to some of the most common questions/errors:
As soon as an invoice is generated, the sales rep can view and download it as a PDF in Salesforce on the Account page. Navigate to the "Invoices" section. Click on the relevant invoice number. On the bottom of the invoice view, click "Invoice PDF".
You can also view the "Invoices" tab at the top of the account page, under the chatter feed. A paid invoice will have a zeroed Balance and positive Payment Amount.
If an opportunity was sold through channel or MSP, the Invoice will be located on the Partner or MSP Account page, not the Customer Account page. You can send a copy of this invoice PDF if the customer requests.
In some cases, a prospect or customer that is currently engaged with an AE on an opportunity might be proactive and sign up online via the web portal. If this occurs, then a duplicate Account, Opportunity, and Contact could be created. In the event that a duplicate record is created, please do the following to resolve as we want to keep the original lead source, activity history, and other information from the original opportunity:
Sales Accepted Dateand
Sales Qualified Date, but only if these dates are for the current month. Please do not update if this is in the past since this opportunity was already counted as an SAO or SQO for a previous period. If either the Close Date, Sales Accepted Date or Sales Qualified Date are from a previous month, we must create a refund opportunity, which is described below.
10-Duplicate(if you do not perform the first step, you will run into a validation rule).
End Date, and
Opportunity Termto match the values from the web direct opportunity.
Amountvalues are the same.
If the prospect is still a Lead record that has not converted into an Account, please complete the following steps:
Go to the Lead record and convert it into an account, contact, and opportunity as you normally would any qualified opportunity.
Then follow Steps 1-4 in the previous section.
Customer will receive a Renewal notification email for every subscription that they have active - this not only includes subscriptions with recurring charges, but also subscriptions with one-time charges only (like Professional Services and CI Minutes). It can be very confusing to the customer, so please assure them that this type of subscription will not renew and it does not impact their recurring GitLab plan subscription. You can see a current list of these emails here.
This is a current system limitation. Renewal emails are sent by Zuora - they are very generic and are not customizable based on subscription state, products purchased or customer account settings. Ideally we would not send a renewal email for a subscription with non-renewable products. The work to improve these emails is being explored in this Epic.
The deal has closed, but the customer has questions, or worse, problems. You don't know who to go to, your palms are sweating. Reading this probably isn't helping.
Go to the right team who can support you with your request. NOTE It is so important to go directly to the correct team, they are often the only ones who can resolve the issue!
Be sure to review the (common questions after a deal has closed)[### Post Sale Information] section. If you still have questions, tag Sales-Support on the relevant Closed Won opportunity.
We love to help, but even our powers are limited.
Sales-support does not have the ability to: * Resolve Zendesk tickets or open Support issues * Access the LicenseApp - we can't send trials, new licenses, or activation codes
The customer support team is here to resolve technical errors related to the customers subscription. DO NOT GO TO CUSTOMER SUPPORT for License issues until you have read this page
Please check out the support page[/handbook/support/#gitlab-support-service-levels] for indepth information on how to contact the team. Spoiler alert, you will need to open an issue or the customer needs to open a Support ticket.
The support team cannot assist you with:
* Salesforce updates/Account/Opportunity Management * Quoting - Whether it's a new quote or fixing a true up error, they cannot build quotes * Questions regarding the LicenseApp