Marketing Operations (MktgOps) supports the marketing organization to streamline processes and manage related tools. We work closely with multiple teams to ensure information between systems is seamless, data is as accurate as possible, and terminology is consistent in respective systems. Our team's primary functions are:
The team is split into 3 main pillars, click on them below for additional information and who is a member of each. Currently enablement falls under Awareness & Consideration.
Slack channels
We do not use or create tool-specific Slack channels (e.g. #marketo).
Salesforce
The Marketing Operations team has created the '@mktgops-support' Chatter in Salesforce to help you make changes or manage Lead objects in Salesforce. Please note, the more information you can provide in your support request, the faster the request can be resolved. Use the '@mktgops-support' Chatter for support with:
Emergency Comms
If an emergency communication needs to be send out, Marketing Ops will need to assist. Follow directions on this page to initiate the emergency response and view the coverage matrix. You can also follow the security incident communication plan for security related issues.
Important: Before submitting an issue that may contain Personally Identifable Information (PII) data (including screenshots), please ensure the issue is marked confidential. You can use quick actions to accomplish this in the issue description priort to submitting.
The MktgOps team works from issues and issue boards. If you are needing our assistance with any project, please open an issue or for small checks and questions, use the ~MktgOps::0 - To Be Triaged label anywhere within the GitLab repo.
If you have a bug, error or discrepancy you'd like the team to help and investigate, please use the bug-request template.
With Agile Delivery being one of the solutions that GitLab (as a product) addresses, the Marketing Operations team aims to follow many of the agile methodologies.
Please do not reopen issues that have been closed in a previous milestone. If you find that you have additional questions about a closed issue, comment in the issue and ping the marketing ops DRI who worked the issue. The DRI within our team will determine whether an issue needs to be reopened and pulled into a current milestone.
To track progress on and provide visibility to team OKRs each quarter, Marketing Operations creates a parent epic to organize our team-wide work. We use OKR Labels to help organize issues.
Check out our quarterly highlights trackers to learn more about the key results we've accomplished.
If an issue includes a weight of 21 or more, that issue may be promoted to an epic in order to properly scope the work across multiple issues. Epics will also be used by our team if it relates to an OKR and requires multiple issues in scope to complete the work. Tool implementations also often are tracked within epics.
We use labels for four purposes:
MktgOps/Systems-Request: Used on issues that require Sales Systems supportMktgOps - FYI: Issue is not directly related to operations, no action items for MktgOps but need to be aware of the issueMktgOps - List Import: Used for list imports of any kind - event or general/ad hoc (do not also use To Be Triaged scoped label)Marketo, Bizible, Demandbase, Drift, LeanData, LinkedIn Sales Navigator, Outreach-io, PathFactory, ZoomInfo, Smartling, OneTrust, On24: used to highlight one of our tech stack toolsMktgOps - bug: A bug issue to be addressed or identified by MktgOpsMktgOps - changelog: Used to track issues or epics that would need to be logged in the marketing changelog to track major changes across marketingMktgOps-Support: Internal label used by MktgOps team to track non-issue work and supportMktgOps-Future Feature: Something to consider for a future project as time allows. Timeframe: As time allowsdg-campaigns, ABM, lifecycle-mktg: Used on issues created by these teams for easier tracking of their requests.MktgOpsPriority::High: Issue that is related to a breaking change, OKR focus, any other prioritized project by MktgOps leadership. This category will be limited because not everything can be a priority. Timeframe: Immediate action needed.MktgOpsPriority::Medium: Issue has a specific action item for MktgOps to be completed as it is an OKR. Timeframe: Within weeksMktgOpsPriority::Low: Issue is a feature to help the team or a specific action item for MktgOps that would be helpful, but can be pushed for other issues.Timeframe: Within monthsMktgOps::00: Triage: General label for any issue that needs MktgOps attention, request for work and/or involvementMktgOps::01: Needs More Information: Issues awaiting for information from the requester, needs more clarity in requirements, no milestone, and not assigned to MktgOps team member yetMktgOps::02: Ready for Assignment : Issues that are acknowledged (in review), gathering requirements, no milestone, and not assigned to MktgOps team membeMktgOps::03: Assigned: Issues that are ready to move forward, slotted to a milestone (not current), and assigned to MktgOps team member's queueMktgOps::04: In Progress: Issues that are in the current milestone, assigned to MktgOps team member, and are actively being workedMktgOps::05: Business Owner Review: Issues in current milestone that are near the finish line, needs to be reviewed and demoed to the business owner(s) to sign-offMktgOps::06: Ready to Deploy: Issues in current milestones, sign-off(s) given by business owner, ready to be deployed by MktgOps team memberMktgOps::07: Blocked: Issue is blocked and no other actions can be taken by MktgOps. Waiting for someone else/another team to complete an action item before being able to proceed. May also be blocked due to external party such as a vendor to complete an action before closing.MktgOps::08: Completed: MktgOps has completed their task on this issue although the issue may not be closed.MktgOps-Current-OKR - Current OKR that the MktgOps team ownsMktgOps-Proposed-OKR - Proposed OKR for the future, used to help track and plan for next quarterMktgOps-Support-OKR - Current OKR for another team, but MktgOps is highly involved in supporting itThe MktgOps team works in two week iterations which are tracked as milestones at the GitLab.com level. Each individual contributor (IC) is responsible for adding issues to the milestone that will be completed in the two-week time frame. If needed, the IC will separate the main issue into smaller pieces that are workable segments of the larger request.
At the end of every milestone, we will post a thread in the #mktgops Slack channel with links to the Issues that we are moving to the next milestone. Context as to why an Issue is moving to a new milestone will be posted in the Issue (not in the Slack thread). The goal of this is to proactively and transparently communicate to our business partners and to empower marketing operations team members to intentionally and thoughtfully manage their work in each milestone.
A milestone cannot be closed nor marked complete until the milestone's accompanying merge request has been merged. Within every milestone there is a WIP merge request with all commits being changes to our handbook. All team members contribute their changes to the milestone merge request. The merge request should be tagged with marketing operations labels and the current milestone.
When making an update to a handbook page for ABM, FMM, MOps, or SDR handbook pages (or sub-pages), we have a Zapier workflow set up that will push the MR (upon merge) to the related Slack channel to ensure our teams are aware of any change that is made to the page. In order for the merged MR to show up in the respective Slack channel, you must add one of the following corresponding labels on the MR. Slack updates will also trigger for MktgOps MRs when created.
| Label you add | Slack channel the merged MR pushes to |
|---|---|
MktgOps - HB Update |
#hbupdate-mktgops #mktgops |
FMM-HB Update |
#fieldmarketing-FYI |
SDR-HB Update |
#hbupdate-sdr |
ABM-HB Update |
#hbupdate-abm |
The marketing operations team uses collective merge requests, known as our milestone MRs, to make multiple updates across our handbook, see high-level updates in 1 MR, and avoid conflicts with each other. Here is an example. We list all major changes with our GitLab username in the description after a commit and link any relevant issues that the commit closes out. If you have an update for the marketing operations handbook, please feel free to use our milestone MR to make a commit and tag us for review to avoid conflicts.
The Marketing Operations team had started an experiment on 2020-04-20 to commit to no internal meetings one day of the week. Now the entire Marketing team has moved to Focus Fridays. Please try not to schedule meetings for team members on Fridays, so they can devote time for deep work in milestone-related issues.
Periodically Marketing Operations and other teams through the marketing org make significant changes to our system and processes that affect overall tools, data and reporting or uncovers significant changes that affected reporting. As such we have a shared changelog. The MktgOps and Strategy/Perf teams update this document as needed as changes are made. If you are working on an issue or epic that will have a significant impact across marketing, add the label MktgOps - changelog so marketing oeprations can track changes across GitLab.
For information regarding the tech stack at GitLab, please visit the Tech Stack Applications page of the Business Operations handbook where we maintain a comprehensive table of the tools used across the company. Below are tools that are primarily owned and managed by marketing operations.
Align with Procurements and Finance:
Marketing Operations role:
To request access to an existing tool in the stack, please follow the access request process as outlined in the business operations handbook.
If you are working with a contractor or consultant that requires access to a tool in our stack, please follow the professional services access request process as outlined in the procurement handbook.
If you are interested in or would like to request a new tool be added to the tech stack, please submit an issue using the tools eval issue template in the Marketing Operations repository. Marketing Operations should be included in new tool evaluations to account for system integrations, budget, etc. Any new tools desired after the budget is set will be handled by transferring budget from the other department to Marketing Operations.
For budgetary reasons, Marketing Operations will be performing quarterly, and for some tools bi-quaterly, audits on the user activity of marketing tools. If a team member has not been actively taking advantage of a tool for 45 days or more, they will have access to that tool revoked with 5 business days of notification via email. Activity will be determined by user reports pulled by the tools' admins. These reports can be found by viewing issues from the Marketing Ops project with the issue label Mktg Tool Audit. The reports will utilize the audit issue template from the Marketing Ops project. To regain access to revoked tools, the team member will need to submit a new access request and follow standard access request procedures. However, user seats will be on a first-come-first-serve basis unless it is determined additional seats should be purchased.
author and admin roles)The communication plan applies to tools like Zoominfo and Outreach and is created to detail the communications that are sent regarding remaining licenses. It speaks to what communications go out, when they take place and in what format.
| Communication | Format | Details | Owner |
|---|---|---|---|
| Update on Mops Handbook whenever comms, format or the owner details get adjusted. | Update Mktgops Handbook and post a notification in #sdrleadership_mktgops slack channel. | Tool owners will update the Mktgops Handbook page whenever the comms, format or owner detail change. In addition, tool owners will post a memo in the #sdrleadership_mktgops slack channel. | Rob Rosu / Gillian Murphy |
| Monthly Zoominfo/Outreach License Gsheet Update | GSheet | Zoominfo/Outreach owner will update the License Gsheet on a monthly basis. Sales leadership will have access to the GSheet. | Rob Rosu / Gillian Murphy |
| 5 Licenses Remaining Notification (Zoominfo/Outreach) | In #sdrleadership_mktgops slack channel | When we’re down to 5 Zoominfo/Outreach licenses remaining, a notification will be sent to sales leadership via the #sdrleadership_mktgops slack channel. | Rob Rosu / Gillian Murphy |
| Quarterly Sales Reps Hiring Plan Update | SSOT SDR SFDC Hierarchy of Roles | Sales leadership will update the Sales Rep Hiring plan on a quarterly basis. | Ramona Elliott |
The MktgOps team frequently works with the Sales Systems team to deploy new/updated fields and permission sets. See the below information regarding the process for working with Sales Systems for these changes and SLAs we adhere to.
Video: Marketing Salesforce.com Sandbox Training
If a field needs to be created in Marketo AND SFDC, you must create in SFDC first and add it to the Marketo User Permission set. **Use documentation for Marketo for field types. For updating a permission set only, see step 1.B.
| Steps | Owner | SLAs |
|---|---|---|
| 1.A Create the new field builds within the marketing sandbox and create the changeset. Document SLA for testing/approving in sandbox. 1.B OR to update permission set only, identity this within the systems issue and add note to add to Marketo Permission set. This is a separate part of the process that will bypass prompting to change set steps below and Systems will have a 72 hour SLA to complete. Once done, confirm field in Marketo. Suggest a weight 1 in the issue comment and tag David Brown, Jack Brennan, and Sheela Viswanathan. David to flag the issue in the prior Slack channel. |
MktgOps | - 72-hour SLA to deploy permission set updates - 1-week SLA to deploy new/updated fields |
| 2. Create a systems issue explaining the context of the field builds/changes and to promote changeset. Add notes above about pagelayout, etc. Add note to add to Marketo Permission set (Systems does not promote permission sets in their change sets and will take place after Salesforce field is created). Suggest a weight 1 in the issue comment and tag David Brown, Jack Brennan, and Sheela Viswanathan. David to flag the issue in the prior Slack channel. |
MktgOps | |
| 3. Promote the change set in the marketing sandbox to staging | Sales Systems | |
| 4. Push the change set to staging sandbox first & then push the same to Production Sandbox | Sales Systems | |
| 5. Systems team member will deploy the change set in production assuming no errors/challenges within sandbox. | Sales Systems | |
| 6. Update the issue & close out | Sales Systems | |
| 7. Once done, confirm the field in Marketo/Salesforce | MktgOps |
SLAs when working with Sales Systems:
Other helpful links:
| GL Code | Account Name | Purpose |
|---|---|---|
| 6060 | Software Subscriptions | All software subscriptions |
| 6100 | Marketing | Reserved for Marketing GL accounts |
| 6110 | Marketing Site | All agency fees and contract work intended to improve the marketing site |
| 6120 | Advertising | All media buying costs as well as agency fees and software subscriptions related to media buying |
| 6130 | Events | All event sponsorships, booth shipping, event travel, booth design, event production as well as agency fees and software costs related to events |
| 6135 | Swag | Any swag related expense |
| 6140 | All 3rd party email sponsorships as well as agency fees and software costs related to mass email communications and marketing automation | |
| 6150 | Brand | All PR, AR, content, swag and branding costs |
| 6160 | Prospecting | Not used - All costs related to prospecting efforts |
Invoices submitted to Coupa will be routed for approval. Details regarding this process can be found on the Coupa End Users Guide page. Campaign tags are used to track costs related to events and campaigns.
A Marketing Qualified Lead is a lead that has reached a certain threshold, we have determined to be 100 points accumulated, based on demographic/firmographic and/or behavioral information. The Person Score is comprised of various actions and/or profile data that are weighted with positive or negative point values. You can find more details about the scoring model on the Marketo Page
Campaigns are used to track efforts of marketing tactics - field events, webcasts, content downloads. The campaign types align with how marketing tracks spend and align the way records are tracked across three of our core systems (Marketo, Salesforce and Bizible) for consistent tracking. Leveraging campaigns aligns our efforts across Marketing, Sales and Finance.
Go to the Campaigns and Programs Page to view all of the campaign types, their progression statuses and cost tracking. That page also includes directions for set up in Marketo and Salesforce.
Marketing Ops is responsible for maintaining the email marketing database. Go to the Email Management Page for policies and more detailed information.
Initial Source is the first "known" touch attribution or when a website visitor becomes a known name in our database, once set it should never be changed or overwritten. For this reason Salesforce is set up so that you are unable to update the Initial Source field. If merging records, keep the Initial Source that is oldest (or set first). When creating Lead/Contact records and you are unsure what Initial Source should be used, ask in the #mktgops Slack channel. Initial Source in Marketo is named Person Source, and should only update when empty.
We use Source Buckets to group Sources into acquisition channels. These groups are: core, inbound, outbound, paid demand gen, purchased list, referral, virtual event, and web direct. When using the TD - Marketing Metrics dashboard reports can be filterd by these source buckets.
The values listed below are the only values currently supported. If you attempt to upload or import leads or contacts into Salesforce without one of these initial sources you will encounter a validation rule error. If you think that there needs to be a new Initial Source added to this list and into Salesforce please open an issue with the marketing ops team. When a new initial source is added, the bucket must also be updated in a SFDC workflow to properly show in Sisense.
Status in the table below means:
| Source | Source Bucket | Definition and/or transition plan | Status* |
|---|---|---|---|
| CE Download | core | Downloaded CE version of GitLab | Active |
| CE Usage Ping | core | Created from CE Usage Ping data | Active |
| CORE Check-Up | core | Created from In-App Contact us (Handraise PQL/In-App Health Check) | Active |
| Demo | inbound | Filled out form to watch demo of GitLab | Active |
| Education | inbound | Filled out form applying to the Educational license program | Active |
| Email Request | inbound | Used when an email was received through an alias (will be deprecated) | Active |
| Email Subscription | inbound | Subscribed to our opt-in list either in preference center or various email capture field on GitLab website | Active |
| Gated Content - General | inbound | Download an asset that does not fit into the other Gated Content categories | Active |
| Gated Content - eBook | inbound | Download a digital asset categorized as an eBook | Active |
| Gated Content - Report | inbound | Download a gated report | Active |
| Gated Content - Video | inbound | Watch a gated video asset | Active |
| Gated Content - Whitepaper | inbound | Download a white paper | Active |
| GitLab.com | inbound | Registered for GitLab.com account | Active |
| Newsletter | inbound | Active | |
| OSS | inbound | Open Source Project records related to the OSS offer for free licensing | Active |
| Request - Contact | inbound | Filled out contact request form on GitLab website | Active |
| Request - Professional Services | inbound | Any type of request that comes in requesting to engage with our Professional Services team | Active |
| Security Newsletter | inbound | Signed up for security alerts | Active |
| Trial - Enterprise | trial | In-product or web request for self-managed Enterprise license | Active |
| Trial - GitLab.com | trial | In-product SaaS trial request | Active |
| Web | inbound | Active | |
| Drift | inbound | Active | |
| Request - Community | inbound | Active | |
| Request - Public Sector | inbound | Active | |
| Other | Other | Active | |
| AE Generated | outbound | Sourced by an Account Executive through networking or professional groups | Active |
| outbound | Active | ||
| Prospecting | outbound | Active | |
| Prospecting - General | outbound | Active | |
| SDR Generated | outbound | Sourced by an SDR through networking or professional groups | Active |
| Zoominfo | outbound | Sourced by SDR/BDR/AE/SAL/ASM | Active |
| Cognism | outbound | Sourced by SDR/BDR | Active |
| Conference | paid demand gen | Stopped by our booth or received through event sponsorship | Active |
| Owned Event | paid demand gen | Events that are created, owned, run by GitLab | Active |
| Virtual Sponsorship | paid demand gen | Active | |
| Purchased List | purchased list | Active | |
| Employee Referral | referral | Active | |
| Channel Qualified Lead | referral | GitLab partner sourced, previously partner |
Active |
| Word of Mouth | referral | Active | |
| Existing Client | referral | Active | |
| External Referral | referral | Active | |
| Webcast | virtual event | Register for any online webcast (not incl Demo) |
Active |
| Workshop | virtual event | Active | |
| Web Direct | web direct | Created when purchase is made direct through the portal (check for duplicates & merge record if found) | Active |
| Investor | outbound | Sourced by our investors (i.e. - GV, Khosla, ICONIQ). The Investor value is coupled with the Investor Name custom field |
Active |
| GitLab DataMart | core | Created by the GitLab Marketing Database data pump. Contains leads from various internal sources | Active |
| GitLab Subscription Portal | Signed up for customers portal account, but did not upgrade | Active | |
| Free Registration | core | Sign up via Free User registration | Active |
| Paid Social | inbound | Sourced from Paid Social Campaigns | Active |
| Source | Source Bucket | Definition and/or transition plan | Status* |
|---|---|---|---|
| Web Chat | inbound | Engaged with us through website chat bot | Inactive |
| Startup Application | inbound | Inactive | |
| Consultancy Request | inbound | Inactive | |
| Promotion | paid demand gen | Inactive |
In Q1 FY22 the Demand Generation team began running paid campaigns to drive trial signups. Currently, we don't have the "trial" source bucket split out by paid vs. organic because we don't have Google Analytics tracking on the signup form. Fortunately, this will soon be changing!
Until then, if pulling metrics around source buckets for CAC calculations please use the Demand Gen dashboard in Sisense (you can filter by trials).
The Lead & Contact objects in Salesforce have unified statuses with the following definitions. Also reference Re-MQL workflows for how to move from status to status. To learn more on how we manage our lifecycle including lead/contact status and Lifecycle Classifications, please see here.
| Status | Definition |
|---|---|
| Raw | Untouched prospect, default status |
| Inquiry | Action was taken by the record to specifically give their contact information to GitLab |
| MQL | Marketing Qualified through systematic means |
| Accepted | Actively working to get in touch with the lead/contact |
| Qualifying | In 2-way conversation with lead/contact |
| Qualified | Progressing to next step of sales funnel (typically SAO created & hand off to Sales team) |
| Disqualified | Contact information is not now or ever valid in future; Spam form fill-out |
| Recycle | Record is not ready for our services or buying conversation now, possibly later |
| Bad Data | Incorrect data - to potentially be researched to find correct data to contact by other means |
| Ineligible | All leads/contacts that are ineligible to go through the sales process after an initial review |
One of the following must occur to have a lead move from Raw to Inquiry
Marketing Operations has the responsibility for cleaning and enriching our database of leads/contacts with the most complete and up to date information.
The cleaning part of this process is being done with the Cleanse functionality of the lead/contact deduplication tool, Ringlead.
The enrichment part of the process is done using the data appending/enrichment tool, Zoominfo, our SSOT when it comes to account/lead/contact data.
This cleaning & enrichment process has 3 main priorities:
Contact Us, Self-Managed Trials, SaaS Trials forms.For more information regarding our data deduplication process visit the Ringlead Handbook Page.
Cleaning & Enrichment Frequency: While the enrichment jobs for net new leads, from our forms, work on a continuous bases, when it comes to enrichment of our existing leads & contacts in SFDC, this is done via scheduled enrichment jobs as follows:
You can find more details on the enrichment process in our Zoominfo Handbook Page.
Testing processes and automation are critical for quality assurance in our systems.
As a tester, you create test leads to ensure processes work as expected. These test leads are mixed among real records, causing inaccuracies in our reporting. Marketing Operations has created best practices that make it easier to spot and delete test leads.
The next time you test a program, remember set Job Title = Test and they will be removed promptly.
Notice any test leads? Please open an issue with the Marketing Operations team.
Internal DNC List are maintained using the Do Not Call checkbox on the lead/contact record layouts. The sales development organization has a clear process on how and in what context should the box be checked. Please visit the Sales Development Handbook page - Cold Calling Checklist section to find out more about it.
To be compliant with international DNC (Do Not Call) regulations and minimize the risk of litigation, a process was implemented for making sure the records that appear on external DNC lists are not contacted via phone (this applies to both Direct Dial Phone Numbers and Mobile Phone Numbers).
This information gets passed to us with the help of Zoominfo, which populates the [ZI] Do Not Call - Direct Phone and [ZI] Do Not Call - Mobile Phone fields with the Yes value whenever a phone number is found to be on an external DNC list.
With Marketo automation we are then using these two fields to hide the phone number information on the following fields: [ZI] Phone Number, Phone (standard field - only if it matches the [ZI] Phone Number value), [ZI] Mobile Phone Number and Mobile Phone (standard field - only if it matches the [ZI] Mobile Phone Number value).
For more information, please visit this mural.
Zoominfo is our SSOT when it comes to data enrichment of our leads/contacts and accounts.
To be compliant with the latest privacy policies and safeguard our database from potential litigation, Zoominfo's recommendation for contacts that have opted out of their database is to:
If you have downloaded any of these contact records from ZoomInfo or uploaded them to your internal systems, you must remove >them unless you have an independent lawful basis to possess and use such person's personal data.
Note: This only applies for leads/contacts that do NOT currently have an existing business relationship
After collaborating with Gitlab's privacy department, it was decided to create a process for removing said contacts from our database.
The current process takes place on a weekly basis and is implemented with the help of a Marketo Program. It takes advantage of the Zoominfo Non-Matched Reason field which is populated by Zoominfo. All leads/contacts that have the OPT_OUT value, enter the process and are checked for additional activites that could qualify as independent lawful basis to be kept. If they lack said activites they will be removed from our database.
For more information, please visit this mural.
If you have any questions or concerns feel free to open an issue with the Marketing Operations team.