Marketing Operations

Welcome to the Marketing Operations Handbook.

Up one level to the Demand Generation Handbook


On this page


Overview

General Lead Gen Information

Overview

Scope of Responsibility <a name=“sor”></a>

Marketing Operations (Mktg OPS) supports the entire Marketing team as well as other teams within GitLab. Mktg OPS works closely with Sales Operations to ensure information between systems is seamless and we are using consistent terminology in respective systems.

Marketing Tech Stack <a name=“mktgtechstack”></a>

Our current marketing tech stack consists of the following tools:

Tech stack contract details, admins and other miscellaneous information.

Leads <a name=“leads”></a>

Lead Routing

This information will be updated shortly and live in the BDR section of the handbook so it is not duplicated.

MQL Definition

A Marketing Qualified Lead (MQL) is a lead that reached a certain point threshold based on collection of demographic information, engagement and/or behavioural data. We have two MQL "buckets": (1) hand raisers and (2) passive leads.

Hand Raisers (A Leads)

Hand raisers are leads who have filled out a Sales Contact Us form or signed up for a free Enterprise Edition (EE) Trial. These leads are automatic MQLs regardless of demographic information because they have exhibited clear interest in GitLab's ability to fulfill a software need.

Passive Leads

Passive leads are leads who have not completed an A Lead action (filling out contact form or taking out a EE Trial). For a passive lead to become an MQL, they must meet our minumum lead score of 90 points. A passive lead becomes an MQL via a combination of demographic score and behaviour/engagement score. See lead scoring model below.

Qualifying by Demographics

We have determined values for specific demographic information (i.e. job title, company name, industry, valid work email, company size) based on our target buyer. Currently, our marketing inbound lead generation funnel is focused on serving up Small Business (SMB) decision makers to our Business Development Representatives (BDRs). Assigning positive points to specific demographic information (e.g. job title is "Head, Director, Senior, etc.") allows us to surface leads who are more likely to be a decision maker, and is built to make it more difficult for individual developer/engineer roles to MQL.

Qualifying by Behaviour and Engagement

Behaviour is tracked by how and where our leads are engaging with us. This system is intentionally set up to surface people showing stronger buying intent signs than others.

We recognize that not all people who engage with our webcasts, content campaigns or open our emails should become MQLs, so the system is set up so somene has to engage multiple times in order to MQL from these activities. Visiting specific pages (i.e. product, features, comparison pages, visited page but didn't complete EE Trial form) shows a higher level of intent thus scored higher.

Lead Scoring Model

This model is based on a 100-point system. Positive and negative points are assigned to a lead based on their demographic and firmographic information, and their behaviour and/or engagement with the GitLab website and marketing campaigns.
This model was implemented on 13 February 2017 and only impacted leads moving forward. For reporting purposes, it was decided not to retroactively adjust scores and MQL dates.

Inbound Lead Flow

  1. Lead comes into BDR team via one of the named Inbound Lead routes above.
  2. Lead is input into Marketo.
  3. Lead is assigned according to assignment rules.
  4. If region is EMEA, lead goes directly to EMEA BDR team.
  5. If region is APAC, lead goes directly to APAC Sales Director.
  6. All other regions go directly to NA BDR team.
  7. All other leads pass through BDR lead qualification process.

Lead qualification process

  1. Unless a specific request is made, provide a useful resource that will help the person have a better GitLab experience.
  2. Ask Discovery Questions to qualify lead
  3. The following criteria is used to determine if a lead should be passed to sales or recommended CE resources. Once determined, BDR team passes all leads to sales for followup via Salesforce assignment and email notification.
  4. If further qualification is needed to understand SQL Qualification requirements, BDR team will email or schedule a phone call with lead to understand their project and initiatives.
  5. Once a lead has met the criteria for an SQL, the BDR will schedule a discovery call with the prospect and an AE. On the call, the BDR will provide a warm introduction and handoff the prospect to the AE.
  6. If SQL criteria isn't met and there are questions, BDR team will answer all questions or route to support.
  7. If there are no questions and lead isn't qualified yet, the lead status is updated appropriately. See "lead status" above.
  8. All Account Executives and Senior Account Executives are part of the regular Lead round robin rotation but if a lead is from a Fortune 500 company, it will be assigned to a Senior Account Executive. For larger opportunities outside the US, lead will be passed to senior account executive or sales director in region.
  9. If a lead is an existing customer or a prospect that's owned/operated by an existing customer but is not using EE, BDR team will determine account owner and pass lead.
  10. If a lead is from an existing account and is using EE, the BDR will convert the lead to a contact in SFDC (making sure to check the “Do not create a new opportunity” box) and @mention the lead owner in SFDC to let them know of the new contact. No need to connect the lead with the owner via email.
  11. If a lead is from a company that is already in Salesforce, BDR team will determine account owner and pass lead.

What counts as an MQL, SQL, or SAL?

SQL Qualification Criteria

  1. Current Defined Need: Does the prospect have an identified need for GitLab? List out the current need.
  2. Current Defined Need: What is the prospect currently doing to address their need? What other technologies are they using?
  3. Budget: Does the prospect have a realistic chance of securing the budget for GitLab? Is there already a budget secured for the project?
  4. Buying Process: Who is the decision maker for GitLab?
  5. Buying Process: What is the buying process for procuring GitLab?
  6. Buying Process: What is role does the prospect play in the current evaluation (function, job title)?
  7. Timeline: What is the timeline to make a decision? Are you currently in an existing contract that needs to expire before you can move forward? If yes, when does the contract expire?
  8. Product Fit: Are they interested in GitLab EE? Is GitLab EE a good fit for their need? Needs to be YES
  9. Product Fit: Do they currently use another version of GitLab? Are they familiar with our product family?
  10. Scope: How many seats are they interested in purchasing? This will be needed to add in the opportunity amount field "example 100 x $39 = $3900"
  11. Scope: How many developers total (potential additional seats) do they have? Anything over 100 potential seats is assigned to an AE. Leads under 100 potential seats will be assigned to BDR Manager to track.
  12. Next Steps: Is there a meeting set with an AE to discuss next steps? Meeting needs to be set before lead can be qualfiied.
  13. Existing Client Is the contact from a new business unit? If existing business unit refer to AE responsible for the account.

Lead status

Passing Qualified Leads

  1. BDR checks AE availability and send invite to prospect(s) and AE with invite naming convention of Meeting Invite Naming Convention: Gitlab Discovery Call - with call in details and agenda of meeting (from summary email and notes)
  2. BDR emails prospect, cc'ing AE. Email consists of a summary of the lead qual data captured above (current state, problems to solve, what they would like to learn and desired state). This email also introduces the AE and confirms the meeting day with the prospect and informs them that a meeting invite will be sent shortly.
  3. BDR converts lead to opportunity. BDR adds into revenue into the amount field, within the opportunity object, based on the lead criteria uncovered of number of seats and/or products interested in purchasing now.
  4. If technical resources will be needed for any calls, AE will be responsible for inviting necessary resources. Typically, the frst call, which isi Discovery, should not contain technical discussion or resources as we are gathering information from prospect to present information at a later date.
  5. BDR joins Discovery call and provides warm handoff

Nurture campaign process

Coming soon once process is defined. Will be signup campaign for GitLab.com, leads that don't meet Soft-BANT requirements, etc.

Subscriptions and Newsletter

Inbound leads receive appropriate marketing emails, such as newsletters, onboarding tips (coming soon), etc. What they receive depends on how they came to find us and what we believe will be most helpful to them. For example, a person who downloaded an EE trial will receive different resources than a person who registered for a webcast. Our non-operational emails have a one-click unsubscribe button. You can manually unsubscribe a person by clicking the "Opt Out" checkbox in SFDC. SFDC also has a manual 30-Day Opt Out checkbox for a 30-day unsubscribe from non-operational emails.

Inbound Leads

New license flow

Current state

  1. "Buy Now" button on https://about.gitlab.com/pricing/ is submitted.
  2. Zuora intakes order and sends account information to Salesforce.
  3. Account owner is notifed.
  4. If no current account owner, sales admin is the account owner.

Marketo Tools Server

Sales and Community Group Emails

Marketo Training Videos

Here are links to the recordings of Marketo trainings that we've done: