Skip to content
Snippets Groups Projects
Commit 61777ee6 authored by Chet's avatar Chet
Browse files

Merge branch 'mktgops3' into 'master'

Mktgops3

See merge request !6263
parents 99e97c6d dcc83fb4
No related branches found
No related tags found
1 merge request!6263Mktgops3
Pipeline #
......@@ -4,47 +4,25 @@ title: "Marketing Operations"
---
Welcome to the Marketing Operations Handbook.
 
[Up one level to the Demand Generation Handbook](https://about.gitlab.com/handbook/marketing/lead-generation/)
[Up one level to the Lead Generation Handbook](https://about.gitlab.com/handbook/marketing/lead-generation/)
 
----
 
## On this page
* [Overview](#overview)
* [General Lead Gen Information](#leadgeninfo)
* [Marketing Tech Stack](#mktgtechstack)
* [Leads](#leads)
* [Email Management](#email)
 
----
 
## Overview <a name="overview"></a>
- [Scope of Responsibility](#sor)
- [Marketing Tech Stack](#mktgtechstack)
## General Lead Gen Information <a name="leadgeninfo"></a>
- [Leads](#leads)
- [Lead Routing](#leadroute)
- [MQL Definition](#mql)
- - [Lead Scoring Model](MQLmodel)
- [Inbound Lead Flow](#leadFlow)
- [Lead Qualification Process](#leadQual)
- [What counts as an MQL, SQL, or SAL?](#SQL)
- [SQL Qualification Criteria](#sqlQual)
- [Lead Status](#leadStatus)
- [Passing Qualified Leads](#leadPassing)
- [Nurture campaign process](#nurture)
- [Subscriptions and Newsletter](#newsletter)
- [Inbound Leads](#inbound)
- [New license flow](#licenseFlow)
- [Marketo Tools Server](#marketoTools)
- [Sales and Community Group Emails](#groupEmail)
- [Marketo Training Videos](#mktotraining)
## 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>
## Marketing Tech Stack <a name=“mktgtechstack”></a>
 
Our current marketing tech stack consists of the following tools:
- Clearbit: Enrichment tool to add details to customer & prospect record to aide in sales process and overall database segmentation.
......@@ -53,179 +31,77 @@ Our current marketing tech stack consists of the following tools:
- Google Analytics: Web analytics tool that tracks and reports website traffic
- Google Tag Manager: Tool to add/update website tags, incl. conversion tracking, site analytics, remarketing, without needing to edit website code
- InsideView: Lead enrichment tool
- Lean Data: Lead routing and account matching tool
- Marketo: Marketing automation and database management tool
- On24: Webcast software providing live and on-demand recordings
- Outreach.io: Email communication tool for the BDR/SDR/AEs to manage communication with leads/contacts
- Piwik: Open source web analytics platform used to measure web performance
- Salesforce: Customer Relationship Management (CRM) tool used to manage all customer & prospect data.
- Unbounce: Custom landing page tool specific for driving conversions
- Salesforce: Customer Relationship Management (CRM) tool used to manage all customer & prospect data
- Unbounce: Custom landing page tool specific for driving conversions
- Zoom: Video and Web Conferencing tool used for webcasts and online demos
 
[Tech stack](https://about.gitlab.com/handbook/marketing/lead-generation/marketing-operations/marketing_tech_stack/) contract details, admins and other miscellaneous information.
 
## Leads <a name=“leads”></a>
## Leads <a name=“leads”></a>
Marketing OPS is responsible for setting up and maintaining the lead routing for all inbound leads and also managing the database. There are two main tools used for lead routing: Marketo for form fillouts, lead enrichment and scoring, and Lean Data for account matching and routing based on account type (customer, prospect, strategic, etc), region and sales segment.
 
### Lead Routing <a name="leadroute"></a>
[Lead routing rules](https://about.gitlab.com/handbook/sales/sales_ops/leandata/#lead-routing-rules) can be found in the Sales Operation section of the handbook.
 
This information will be updated shortly and live in the [BDR section](https://about.gitlab.com/handbook/marketing/business-development/) of the handbook so it is not duplicated.
As leads are created they are scored based on a collection of demographic information, engagement and/or behavioural data. Once a lead reaches a score of 90 points or more they are considered a Marketing Qualified Lead (MQL). Currently there are two MQL buckets: (1) hand raisers (A leads) and (2) passive leads. Detailed information about the [Lead definition](https://about.gitlab.com/handbook/marketing/business-development/#mql) can be found in the Business Development section of the Handbook.
 
### MQL Definition <a name="mql"></a>
The [MQL Scoring Model](https://docs.google.com/a/gitlab.com/document/d/1_kSxYGlIZNNyROLda7hieKsrbVtahd-RP6lU6y9gAIk/edit?usp=sharing) 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.
 
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)
## Email Management
Email database management is a core responsibility for Marketing Operations. Ensuring GitLab is following email best practices, in compliance with International spam laws and overall health of active database are all priorities.
 
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.
### Requesting an Email
To request an email, create an issue in Marketing and assign it to JJ Cordz and tagging Mitchell Wright (in addition to whomever else needs to be aware of email). Required request information, please be as complete as possible in providing detail related to the email:
- **Sender Name**: Typically we use GitLab Team for most outgoing communications; for Security Alerts we use GitLab Security. Choosing a name that is consistent with the type and/or content of email being sent is important, if unsure make a note and we will make recommendation
- **Sender Email Address**: What email address should be used? [List of available email aliases](#emailalias)
- **Subject Line**: 50 character max is preferred
- **Email Body Copy**: Can be a text snippet within issue, clearly identified comment on issue or attach a Google doc with copy
- **Target Date to Send Email**: at a minimum a few days notice is perferred because we need to balancing the number of emails being sent to our database so they are not perceived (or marked) as spam; however, a simple email can be turned in a few hours if absolutely necessary
- **Recipient List**: Emails can be sent to one of the [existing segments](#emailsegment) or a recipient list can be provided as a .csv file
 
#### 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](#MQLmodel) below.
### Email Segments <a name="emailsegment"></a>
Reoccuring database segments and how someone is subscribes to specific segment:
 
#### Qualifying by Demographics
- **Newsletter**: All users who sign up for a GitLab.com account are automatically added to this segment and users can subscribe to the newsletter through the blog, Contact Us page and CE download page.
- **Security Alerts**: Subscribe on the GitLab [Contact Us page](https://about.gitlab.com/contact/)
- **Webcasts**: When someone registers to a live or on-demand webcast
- **Live Events**: When someone registers to attend a live event, meet up or in-person training. Use of this segment is narrowed down by geolocation so notification and invitation emails are specific to related area.
 
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
### Aliases <a name="emailalias"></a>
Current list of email aliases used in Marketo to send email:
- News@ company domain: external email address used to send newsletter. Replies go to Online Marketing Manager
- SecurityAlerts@ company domain: external email address used to send security alerts. Replies go to Online Marketing Manager
- Webcasts@ company domain: external email address for sending webcast related emails. Replies go to Content Marketing Team and Online Marketing Manager
- Events@ company domain: external email address for sending live, VIP &amp; in-person training related emails. Replies go to Feild Marketing Manager and Marketing OPS Manager
- Community@ company domain: external email address for sending alert emails related to GitLab products. Replies are forwarded to Zen Desk support.
- Leads@ company domain: external email address for Lead alerts. Replies go to Marketing OPS Manager and Online Marketing Manager
- Support@ company domain: external email address for sending Breaking Change and/or support related customer communications. Replies go to Zen Desk support.
 
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.
### Types of Email
**Breaking Change Emails**
These are operation emails that can be sent on a very selective as needed basis. This is an operational-type email that overrides the unsubscribe and does not provide the opportunity for someone to opt-out. Usage example: GitLab Hosted billing change, Release update 9.0.0 changes, GitLab Page change and Old CI Runner clients.
It is very important to have Engineering and/or Product team (whoever is requesting this type of email) help us narrow these announcements to the people that actually should be warned so we are communicating to a very specific targeted list.
 
### Lead Scoring Model<a name="MQLmodel"></a>
**Newsletter**
Sent bi-monthly (every 2 weeks). Content Team is responsible for creating the content for each Newsletter.
**Security Alerts**
Sent on an as needed basis containing important information about any security patches, identified vulnerabilities, etc related to the GitLab platform. These emails are purely text based.
**Webcasts**
Invitation and/or notification emails sent about future webcasts.
 
This [model](https://docs.google.com/a/gitlab.com/document/d/1_kSxYGlIZNNyROLda7hieKsrbVtahd-RP6lU6y9gAIk/edit?usp=sharing) 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<a name="leadFlow"></a>
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<a name="leadQual"></a>
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](https://about.gitlab.com/handbook/sales-qualification-questions/) to qualify lead
3. The following [criteria](#sqlQual) 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](http://fortune.com/fortune500/), 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?<a name="SQL"></a>
* SQL is any lead which meets the [SQL Qualification Criteria](#sqlQual)
=> when converting a qualified lead, make sure that you are creating an opportunity upon conversion. This is required to map the BDR to the opportunity. It also helps us to track the age of an opportunity from discovery call to closed.
=> if the lead is not a new opportunity, convert to a contact and uncheck the box to create a new opportunity.
* SAL is an SQL which has been accepted by the sales team
* MQL is any lead with a lead score of 20 or greater in Marketo (lead score is calculated based on behavioral and demographic data). Some examples of bahavior or demographic data that increase lead score are:
* Signing up to receive the newsletter (behavioral)
* Signing up for an account on gitlab.com (behavioral)
* Filling out other web forms (contacts us, webinar registration, etc) (behavioral)
* Starting an EE Trial (behavioral)
* Working at a Fortune 500 (demographic)
* Job title (demographic)
### SQL Qualification Criteria <a name="sqlQual"></a>
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<a name="leadStatus"></a>
- Raw => Newly synced lead from Marketo to SFDC
- Open => Lead not yet contacted
- Attempt 1 => One message sent without response; after 21 days, auto-updates to Nurture
- Attempt 2 => Two messages sent without response; after 21 days, auto-updates to Nurture
- Attempt 3 => Three messages sent without response; after 21 days, auto-updates to Nurture
- Attempt 4 => Four messages sent without response; after 21 days, auto-updates to Nurture
- Qualified => Soft-BANT criteria met. Action: pass to sales team.
- Progressing => Communication is two-way, but Soft-BANT still undetermined. Any response that doesn't immediately put the lead into "Qualified", "Unqualified", or "Nurture" status should put the lead in this status.
- Unqualified => Soft-BANT criteria not met (e.g. a developer using GitLab for personal projects, a student, etc.). Action: send appropriate resources if requested; avoid sending salesy messages.
- Bad Data => Invalid email address. Note: only mark as bad data if there is no communication channel. For example, a lead who provided "Spam Spamson" as their name but still provided a valid email address is not Bad Data.
- Nurture => May become "Qualified" in the future, but communication is closed. Will receive useful marketing emails.
### Passing Qualified Leads<a name="leadPassing"></a>
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)
1. 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.
1. 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.
1. 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.
1. BDR joins Discovery call and provides warm handoff
### Nurture campaign process<a name="nurture"></a>
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<a name="newsletter"></a>
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<a name="inbound"></a>
- https://about.gitlab.com/pricing/ => Currently when someone clicks "Buy Now" it creates an account in Zuora and Salesforce. The account owner is notified, if account does not exist the account owner is sales admin.
- https://about.gitlab.com/free-trial/ => Free trial submits flow to BDR team. lead submits form, form sends data to Marketo, Marketo requests license key from the licensing app, lead gets email with license key from Marketo. BDR follows lead qualification process (documented below).
- https://about.gitlab.com/sales/ => When a lead submit a form to contact sales, that lead flows through marketo and notifies BDR team. BDR follows lead qualification process (documented below).
- https://about.gitlab.com/contact/ Email to community@gitlab.com - Email sends to marketing team. Leads for EMEA are handled by EMEA BDR, Leads for NA are handled by NA BDR, APAC leads are first notice, first route. When lead is followed up, please BCC community@gitlab.com so everyone knows it has been handled and we don't duplicate work. BDR follows lead qualification process (documented below).
- https://about.gitlab.com/contact/ Newsletter signup - lead is added to our semi-monthly newsletter.
- https://about.gitlab.com/contact/ Security signup - Signs up lead for security notices.
- Emails to sales@gitlab.com => Email to sales@gitlab.com - Email sends to sales team. Leads for EMEA are handled by EMEA BDR, Leads for NA are handled by NA BDR, APAC leads are first notice, first route. When lead is followed up, please BCC community@gitlab.com so everyone knows it has been handled and we don't duplicate work. BDR follows lead qualification process (documented below).
- https://about.gitlab.com/press/ press@gitlab.com => Forwards to CMO for handling with our PR team.
- https://about.gitlab.com/development/ => When a lead submit a form to request development help, that lead flows through Marketo and notifies BDR team. BDR follows lead qualification process (documented below).
- https://about.gitlab.com/training/ => When a lead submit a form for training, that lead flows through Marketo and notifies BDR team. BDR follows lead qualification process (documented below).
- https://about.gitlab.com/consultancy/ => When a submit a form for consultancy, that lead flows through Marketo and notifies BDR team. BDR follows lead qualification process (documented below).
- GitLab.com lead signup =>
- https://about.gitlab.com/downloads/ GitLab CE Downloads newsletter signups=> Lead flows through BDR team for lead qualification process (documentation below).
- Webcast leads => Leads registered for a webcast are sent confirmation, reminder, and followup (recording link and attendee survey) emails. A new lead flows through BDR team for lead qualification process.
- Any other forms that are created simply flow through the BDR team for lead qualification process (documentation below).
### New license flow<a name="licenseFlow"></a>
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<a name="marketoTools"></a>
- This is a simple Sinatra application that receives several webhooks and forwards the relevant information to Marketo via its REST API.
- URL: http://marketo-tools.gitlap.com/ (can't access via browser)
- [Software running on it](https://gitlab.com/gitlab-com/marketo-tools/)
- [Readme of the cookbook for deployment](https://gitlab.com/gitlab-com/cookbook-marketo-tools/blob/master/README.md)
### Sales and Community Group Emails<a name="groupEmail"></a>
- Always CC or BCC the group email list (sales@gitlab.com or community@gitlab.com) so others on the list know it's been handled.
- If a request is a new lead with questions about EE, pricing, etc., handle directly.
- If an email is a quote, forward to appropriate sales people.
- If an email is a refund or other billing request, forward to ar@gitlab.com.
- If an email is a license issue or question, forward to support@gitlab.com.
- If an email is received (contact request, account questions, etc. etc.), check in sfdc if there is an account owner. If there is, forward the email to the owner and change the case into their name if there is an open case. If the account owner is Chad or Hank, this is the default. Forward all inquiries/requests to Chad and he will take care of them. Also switch the sfdc case into Chad's name as well.
## Marketo Training Videos<a name="mktotraining"></a>
Here are links to the recordings of Marketo trainings that we've done:
* [Email Creation and Tokens](https://drive.google.com/open?id=0B1_ZzeTfG3XYZjUwa3ZFb2ZWeWc)
* [How to Use Smart Lists and Reporting](https://drive.google.com/open?id=0B1_ZzeTfG3XYcGV2VUFiR0dNaWM)
**Live Events**
Invitation emails to attend a live event (VIP or Executive Lunch), meetup, or in-person training. These emails are sent to a geolocational subset of the overall segment. This type of email is also used when we are attending a conference and want to make people aware of any booth or event we may be holding and/or sponsoring.
\ No newline at end of file
---
layout: markdown_page
title: “Marketing Operations“
title: “Marketing Operations Tech Stack Contracts &amp; Tool Details
---
 
## Tech Stack Details
## On This Page
- [Contract Details](#contracts)
- [Tool How-Tos & FAQs](#howto)
 
### [Tools](#tools)
## Contract Details <a name="contracts"></a>
### Clearbit
[Executed contract copy](https://drive.google.com/open?id=0BzllC63GKDQHMTk2VnE5eWx3NHFTNjBwdHdmWXNCbG10d3pn) (can only view if GitLab Team Member &amp; signed into your account)
Effective Date: 22 March 2017
End Date: 21 March 2018 (12-month term)
Cancellation Clause: 30-day notice to non-renew
**GitLab Admins**: JJ Cordz or Francis Aquino
### InsideView
[Executed Contract copy](https://drive.google.com/open?id=0BzllC63GKDQHRWJLaFhiV3VOVmlUOXBLQmhmTnJrcjVRMVo4) (can only view if GitLab Team Member &amp; signed into your account)
Effective Date: 1 October 2016
End Date: 30 September 2017 (12-month term)
Cancellation Clause: 30-day notice to non-renew _Notice of non-renew given on 22 May 2017_
**GitLab Admin**: JJ Cordz
### Lean Data
[Executed Contract copy](https://drive.google.com/open?id=0BzllC63GKDQHQTRYdjZGYk00TDRZMXZYTzJrSXNmNF9BM0xv) (can only view if GitLab Team Member &amp; signed into your account)
Effective Date: 1 May 2017
End Date: 30 April 2018
**GitLab Admins**: JJ Cordz or Francis Aquino
### Marketo
Effective Date: 1 October 2016
End Date: 30 September 2017
**GitLab Admins**: JJ Cordz or Mitchell Wright
## Tool How-tos &amp; FAQ<a name="howto"></a>
- [Clearbit](#clearbit)
- DiscoverOrg
- [DiscoverOrg](#discoverorg)
- FunnelCake
- Google Analytics
- Google Tag Manager
- [Google Analytics](#ga)
- [Google Tag Manager](#gtm)
- [InsideView](#insideview)
- [LeanData](#leandata)
- [Marketo](#marketo)
- On24
- Outreach
- [Outreach.io](#outreachio)
- Piwik
- Salesforce
- Unbounce
- [Salesforce](#salesforce)
- [Unbounce](#unbounce)
- [Zoom](#zoom)
 
## Clearbit<a name="clearbit"></a>
[Executed contract copy](https://drive.google.com/open?id=0BzllC63GKDQHMTk2VnE5eWx3NHFTNjBwdHdmWXNCbG10d3pn) (can only view if GitLab Team Member &amp; signed into your account)
Effective Date: 22 March 2017
End Date: 21 March 2018 (12-month term)
Cancellation Clause: 30-day notice to non-renew
**GitLab Admins**: JJ Cordz or Francis Aquino
<br>
Details:
- 500.000 records: database enrichment size can be increased in batches of 100k
- 35 user licenses: as of 11 April, 33 licenses used. Additional licenses can be purchased in groups of 5 users.
 
### Frequently Asked Questions
### Clearbit<a name="clearbit"></a>
Clearbit is a data enrichment tool that will be used to fill in important information for new leads created in Salesforce. This information could include address, phone number, industry, IT employees and other important values when assessing both the quality of the lead as well as routing. The technology uses proprietary logic to match prospects to companies in their extensive database.
#### Frequently Asked Questions
 
1. **What standard fields does Clearbit write to?** Clearbit will write to any standard field that is either blank or has a value of '[[unknown]]' if there is data to populate.
 
......@@ -66,17 +92,66 @@ Details:
 
2. **What fields does Clearbit use to identify people and companies?** The integration looks at the _email_ and _website_ fields on **leads** and **contacts**, and the _website_ field on **accounts**.
 
3. **Does Clearbit data update automatically?** YES - Clearbit data is automatically researched whenever a lead/contact/account is created, even if the record is not manaully opeened by a user. This happens through a Salesforce background job. The lead will also be triggred when the lead is viewed.
3. **Does Clearbit data update automatically?** YES - Clearbit data is automatically researched whenever a lead/contact/account is created, even if the record is not manaully opeened by a user. This happens through a Salesforce background job. The lead will also be triggred when the lead is viewed.
 
## InsideView<a name="insideview"></a>
[Executed Contract copy](https://drive.google.com/open?id=0BzllC63GKDQHRWJLaFhiV3VOVmlUOXBLQmhmTnJrcjVRMVo4) (can only view if GitLab Team Member &amp; signed into your account)
Effective Date: 1 October 2016
End Date: 30 September 2017 (12-month term)
Cancellation Clause: 30-day notice to non-renew _Notice of non-renew given on 22 May 2017_
**GitLab Admin**: JJ Cordz
### DiscoverOrg<a name="discoverorg"></a>
DiscoverOrg provides our Sales Development Representatives and Account Executives with access to hundreds of thousands of prospects and their contact information, company infomation, tech stack, revenue, and other relevant data. Individual records or bulk exports can imported into Salesforce using extensive search criteria such as job function, title, industry, location, tech stack, employee count, and company revenue.
 
 
## Marketo<a name="marketo"></a>
Effective Date: 1 October 2016
End Date: 30 September 2017
**GitLab Admins**: JJ Cordz or Mitchell Wright
\ No newline at end of file
### FunnelCake
### Google Analytics<a name="ga"></a>
Google Analytics captures all the analytics for GitLab pages outside of the actual app on https://gitlab.com. This tool is managed by the [Online Marketing Manager](https://about.gitlab.com/jobs/online-marketing-manager/) and detailed use information can be found in [Online Marketing section](https://about.gitlab.com/handbook/marketing/lead-generation/online-marketing/) of the Handbook.
### Google Tag Manager<a name="gtm"></a>
Google Tag Manager is used to manage the firing of the different JavaScript tags we deploy on our website. All marketing tags should be deployed through Google Tag Manager except in cases such as A/B testing software. This tool is managed by the [Online Marketing Manager](https://about.gitlab.com/jobs/online-marketing-manager/) and detailed use information can be found in [Online Marketing section](https://about.gitlab.com/handbook/marketing/lead-generation/online-marketing/) of the Handbook.
### InsideView
InsideView is a lead enrichment tool. When a lead is created in Marketo, before synced to Salesforce, a InsideView webhook would be called to enrich specific fields of data.
Will be discontinued at end of contract
### Lean Data<a name="leandata"></a>
When a lead is created in Salesforce, LeanData will be the tool that routes it to the appropriate user. Routing rules include sales segmentation, region, lead source, and owned accounts. For example, if a lead from a named account is created, it will be routed directly to the owner of the named account. Also, LeanData provide cross-object visibility between leads and accounts and contacts. When in an account record, a user can view "matched" leads by company name, email domain, and other criteria.
[Operation Information about Lean Data](https://about.gitlab.com/handbook/sales/sales_ops/leandata/)
### Marketo<a name="marketo"></a>
Marketo is our marketing automation platform managed by our Marketing OPS team. Anyone who signs up for a trial, requests contact from GitLab, attends a webinar or trade show, or engages in any other marketing activity, will end up in Marketo. These prospects will receive scores based on their level of engagement and these scores will be used by the Business Developement Representatives and Account Executives to prioritize which prospects to follow up with. Marketo is also our primary tool for delivering marketing communciation to prospects and customers. You can read more about the Marketo and the other tools in the Marketing stack here.
Important Documentation Links
- [Marketo Webhooks](http://developers.marketo.com/webhooks/)
#### Marketo Training Videos
Here are links to the recordings of Marketo trainings that we've done:
- [Email Creation and Tokens](https://drive.google.com/open?id=0B1_ZzeTfG3XYZjUwa3ZFb2ZWeWc)
- [How to use Smart Lists and Reporting](https://drive.google.com/open?id=0B1_ZzeTfG3XYcGV2VUFiR0dNaWM)
#### Marketo Tools Server
This is a simple Sinatra application that receives several webhooks and forwards the relevant information to Marketo via its REST API.
- URL: http://marketo-tools.gitlab.com/ (can't access via browser)
- [Software running on it](https://gitlab.com/gitlab-com/marketo-tools/)
- [Readme of the cookbook for deployment](https://gitlab.com/gitlab-com/cookbook-marketo-tools/blob/master/README.md)
### Outreach.io<a name="outreachio"></a>
Outreach.io is a tool used by the Sales team (RD/AE/BDRs) to automate emails in the form of sequences. Users can track open rates, click through rates, response rates for various templates and update sequences based on these metrics. These email sequences and communications are synced back to the Activity History in Salesforce.
### Piwik
### Salesforce<a name="salesforce"></a>
Salesforce is our CRM of record and the _one source of truth_ for customer data. It integrates with all of the other applications in our business &amp; marketing tech stacks. Salesforce stores prospect, customer, and partner information. This includes contact information, products purchased, bookings, support tickets, and invoices, among other information.
### Unbounce<a name="unbounce"></a>
Unbounce is for the creation of landing pages - PPC traffic, webcasts, live events, trainings, gated content. The login information is in the marketing vault of 1Password. Currently, the only landing pages within Unbounce are for our PPC traffic.
**Before** any Unbounce landing pages are published, the design team needs to review &amp; approve to ensure the page meets our brand standards.
### Zoom<a name="zoom"></a>
Zoom is the video conferencing software used by GitLab for company-wide meetings. In June 2017, we are trialing the web conferencing service (replacing On24) to host our webcasts. Zoom is managed by People OPS. Detailed information about how to set up a personal account on Zoom can be found in the [Tools and Tips](https://about.gitlab.com/handbook/tools-and-tips/#zoom) section of the handbook.
......@@ -15,7 +15,7 @@ Welcome to the Online Marketing Handbook.
----
 
## Other Important Pages
* [Google Analytics Crash Course](/handbook/marketing/demand-generation/online-marketing/ga-training)
* [Google Analytics Crash Course](/handbook/marketing/lead-generation/online-marketing/ga-training)
 
----
 
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment