Community Programs Workflows

About

This handbook page describes various workflows associated with GitLab’s community programs, including GitLab for Education, GitLab for Open Source, and GitLab for Startups. By maintaining this page, we aim to establish more transparency into our workflows so GitLab team members can integrate with them.

Automated applications workflow overview

Community Programs applications workflows have been automated since FY23Q3. The Community Programs team partners with a third party, SheerID, to assist in processing applications to community programs.

The Community Programs team processes applications to GitLab’s community programs with a seven-stage workflow:

Application

SheerID hosts applications for the GitLab for Open Education and GitLab for Open Source programs. SheerID therefore hosts and sends all communications (email and browser notifications) for these two programs. SheerID also provides customer service specific to GitLab. MySheerID is the customer portal for the verification system. The portal contains details on each application form, a reporting system, and account settings. GitLab team members requiring access to the MySheerID portal can request an account through an access request.

We review GitLab’s contract with SheerID on an annual basis. Costs are based on the total number of verifications across all programs.

The application to GitLab for Startups is a Marketo form.

Verification

The verification process differs by program. See these handbook pages for more detail:

• GitLab for Education workflows
• GitLab for Open Source workflows
• GitLab for Startups workflows

Upon successful verification, applicants receive an email with instructions for obtaining their licenses. These instructions include a unique coupon code generated by the fulfillment team at GitLab (via a coupon code generator). The DRI for the coupon code generator is the fulfillment team. To generate new coupon codes, open an issue (example) in the customers-gitlab-com project.

Additionally, note the following:

• We store sensitive, program-specific codes internally; only Alex Karsten can access these codes.
• SheerID provides coupon codes when requested via email to productsupport@sheerid.com.
• SheerID provides codes in an individual .csv file specific to each program. The .csv file should only have one column, with no header.
• SheerID provides sufficient coupon codes for one year of verifications for each program at a time. The number of coupon codes per year is determined using the following basic formula: number of applications expected per quarter + number of expected renewals * an average re-verification factor.

Booking

Successful applicants receive an email from SheerID. This email contains a direct link to a program-specific page in the Customers Portal. These program-specific pages are not available directly in the GitLab Customers Portal; they are only accessible via links in success emails. See GitLab’s internal handbook for links to these portals.

During the checkout process:

• Applicants must enter the unique coupon codes they receive in their verification emails

• Applicants must accept a program agreement:

  • GitLab for Education Program Agreement
  • GitLab for Open Source Agreement
  • GitLab for Startups Agreement is presented directly upon checkout

The GitLab for Startups Terms:

If you meet the requirements of the GitLab for Startups Program, you will be eligible to receive twelve (12) months Ultimate [SaaS or Self-Managed] at no cost, without Support. Renewal of the User(s) will be at the current published List Price. Your use of the GitLab Software is subject to the GitLab Subscription Agreement. Software is provided as “Free Software”.

Provisioning

Licenses are provisioned directly during process via the WebDirect flow and according to one of the following SKUs:

• [EDU Program] SaaS - Ultimate (formerly Gold) - 1 Year [EDU Program] SaaS - Ultimate - 1 Year

• [EDU Program] SaaS - Ultimate (formerly Gold) w/ Support - 1 Year [EDU Program] SaaS - Support - 1 Year [EDU Program] SaaS - Ultimate - 1 Year

• [EDU Program] Self-Managed - Ultimate - 1 Year [EDU Program] Self-Managed - Ultimate - 1 Year

• [EDU Program] Self-Managed - Ultimate w/ Support - 1 Year [EDU Program] Self-Managed - Ultimate - 1 Year [EDU Program] Self-Managed - Support - 1 Year

• [OSS Program] SaaS - Ultimate (formerly Gold) - 1 Year [OSS Program] SaaS - Ultimate - 1 Year

• [OSS Program] SaaS - Ultimate (formerly Gold) w/ Support - 1 Year [OSS Program] SaaS - Support - 1 Year [OSS Program] SaaS - Ultimate - 1 Year

• [OSS Program] SaaS - Ultimate (formerly Gold) w/ Support - 3 Year [OSS Program] SaaS - Support - 3 Year [OSS Program] SaaS - Ultimate - 1 Year

• [OSS Program] Self-Managed - Ultimate - 1 Year [OSS Program] Self-Managed - Ultimate - 1 Year

• [OSS Program] Self-Managed - Ultimate w/ Support - 1 Year [OSS Program] Self-Managed - Support - 1 Year [OSS Program] Self-Managed - Ultimate - 1 Year

• [OSS Program] Self-Managed - Ultimate w/ Support - 1 Year [OSS Program] Self-Managed - Support - 3 Year [OSS Program] Self-Managed - Ultimate - 3 Year

• [Startups Program] SaaS - Ultimate (formerly Gold) - 1 Year [Startups Program] SaaS - Ultimate - 1 Year

• [Startups Program] SaaS - Ultimate (formerly Gold) w/ Support - 1 Year [Startups Program] SaaS - Ultimate - 1 Year [Startups Program] SaaS - Support - 1 Year

• [Startups Program] Self-Managed - Ultimate - 1 Year [Startups Program] Self-Managed - Ultimate - 1 Year

• [Startups Program] Self-Managed - Ultimate w/ Support - 1 Year [Startups Program] Self-Managed - Ultimate - 1 Year [Startups Program] Self-Managed - Support - 1 Year

Compliance

Sales-Support and Billing Ops handle compliance-related issues. This stage results in granting the license and notifying the customer of how to access the licenses. The Community Programs team ensures compliance with Program Agreements.

In cases where the Community Programs team believes a program member’s actions violate the terms of a Program Agreement, team members will report the suspected violation by opening a Legal and Compliance issue. The Community Programs team will then collaborate with GitLab’s Legal team to determine the most appropriate method of assessing the issue.

In cases where the Community Programs team believes a program member’s actions violate the terms of a Program Agreement, and the violation is curable, the team will enact the following procedure to begin redress and ensure compliance.

First, the team will notify the program member of the suspected violation with a message that conforms to the appropriate template. The purpose of this message is to:

• Serve as formal notice that under the terms of an applicable Agreement the program member’s current use of the licenses granted is not in compliance with the terms of the applicable Agreement.
• Signal the beginning of the 30-day cure period, by the conclusion of which the program member must rectify the failure
• Express interest in and commitment to working with the program member to remedy the situation
• Offer to meet with (or communicate asynchronously with) the program member to answer additional questions about the member’s use of GitLab under the terms of the Program Agreement

Members of the Community Programs team will then work with the program member to cure the failure before the 30-day cure period has concluded.

At the conclusion of the cure period:

If the program member remedies the situation, then no further action is necessary and the program member can continue using its GitLab subscription. The program member should expect to renew this subscription at the conclusion of its term, and at that time be subject to review of its eligibility criteria.

If the program member does not remedy the situation, then GitLab will terminate the subscription license it granted the program member under the terms of the applicable Agreement.

Certain situations may warrant immediate evocation of a program member’s subscription license. In those cases, GitLab will use best efforts to notify the program member prior to revocation subject to the terms of the applicable agreement.

To revoke a subscription license, GitLab team members should engage GitLab’s Sales Support team via Salesforce as follows:

1. Locate the subscription associated with the license in question
2. Chatter Deal Desk to request this subscription be “debooked”

Debooking a subscription revokes its associated Ultimate license.

Renewal

Applicants renewing their program memberships must re-apply to their respective programs to ensure continued eligibility. To do this, they use the same application forms they used when initially enrolling in the program.

The success email will contain a direct link to a program-specific page for each program (Education/Open Source) in the GitLab Customers Portal. The program-specific pages are not available directly in the GitLab Customers Portal without the direct link. See Community Programs’ internal handbook for direct links to these portals.

As they did when initially applying for the program, applicants enter their unique coupon codes during the checkout process.

Supporting the automated application workflow

Each step of the automated application workflow has different set of potential errors and related support workflows.

The Community Programs team is responsible for all processes involved in issuing licenses for GitLab’s community programs. The team also maintains program support queues, through which all Community Programs emails are funneled.

Below are details related to various Commuity Programs workflows.

Inbound sales requests routing workflows

Sales team members receiving inbound requests regarding community programs should adhere to the following workflow and direct leads according to the routing table below.

Common program-related Salesforce workflows

Edit an address

1. Navigate to the Account view in Salesforce. Scroll down to the Address Information, Billing Address.

• Note: The Billing Address can also be accessed from the Contact view.

1. Click the edit button to edit the address. Click OK to save the changes.

• Note: The address should update for the Account, Contact and Opportunity.

Reassign a Salesforce object

1. Click Change next to the object owner field and select the appropriate owner.

Merge duplicated accounts

1. Make sure the domain and account names are the same.
2. Chatter @Sales-Support one of the accounts and request that the accounts be merged.

View a signed quote

1. Once signed the document will be automatically attached to the Opportunity in the Google Docs, Notes, and Attachments section.

Apply naming conventions

Naming conventions

• Lead status: Accepted means Program Manager reached out to the lead/contact
• Lead status: Qualifying means Program Manager is in 2-way conversation with lead/contact
• Lead status: Unqualified means Applicant is not qualified for that program

Check approval history

1. From the Opportunity click Approval History.
2. Each step in the process will appear under Action.
3. If the opportunity was approved the Overall Status will indicated Approved.
4. If the opportunity appears to be stalled in the process, chatter the person the opportunity is assigned to.

Chatter the Sales team

Chatter is the primary method of communication between users and groups in Salesforce. Chatter can occur at Account or Opportunity level. Chatter notifications for individuals can be found on the individual’s home tab in Salesforce.

• Sales team members (operations and account owners) will chatter Program Managers or individuals when an action is required on a record.
• When an individual is chattered the message will appear both at the top of the object from which the chatter initiated, i.e. Account or Opportunity and it will appear in the Chatter tab of Salesforce.
• In order to chatter someone directly you can type @{NAME} in the chatter window and select the name of the person or group you wish to chatter.
• For most questions related to the EDU-OSS workflow, chatter @Sales-Support

Close expired renewals

The sales team might tag the Program Manager in expired opportunities that were never processed. This could be the result of an applicant deciding they no longer need a GitLab license, or a group not reaching out to renew their license. While it’s not a priority, it’s important these expired opportunities be processed in Salesforce.

1. The sales team will chatter the Program Manager on expired opportunities.
2. On the opportunity page, click Edit
3. Update the Close Date to today’s date.
4. Change the Stage to 8- Closed Lost
5. Update the Closed Lost/Unqualified Detailed section to other and add details that say “Educational Institution did not reach out to renew” or “Educational Institution did not move forward with license”
6. Save the opportunity details.
7. Close the case in the Case Queue.

Editing and resending a quote due to Zipcode Error

If an error is made on a quote, for example, a missing zipcode or incorrect billing contact, you’ll need to update and resend the quote via Salesforce and DocuSign.

1. Navigate to the relevant opportunity
2. Click on the ‘Contacts’ section and choose the contact that serves as the Sold To/Bill To contact. Update the address on the billing contact’s page. Click ‘Save’
3. Return to the opportunity, scroll down to the ‘Quotes’ section and click the link to the relevant quote in the ‘Quote Name’ column
4. Click ‘Generate PDF Doc’ and proceed with standard process for sending a quote through DocuSign.

Editing and Resending a quote due to a Sold To / Bill To Contact Error

1. Navigate to the relevant opportunity
2. Scroll down to the ‘Quotes’ section and click the link to the relevant quote in the ‘Quote Name’ column
3. Click the ‘Edit Quote Details button’
4. Update the Sold To/Bill To information by searching and selecting the correct contacts.
5. After making the edits, click ‘Save’
6. Click ‘Generate PDF Doc’ and proceed with standard process for sending a quote through DocuSign.

View page source - Edit this page - please contribute.