Mktgops - 20260406

</summary>

- `MktgOps::00: Triage`: General label for any issue that needs MktgOps attention, request for work and/or involvement

- `MktgOps::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 yet

- `MktgOps::02: Ready for Assignment`: Issues that are acknowledged (in review), gathering requirements, no milestone, and not assigned to MktgOps team member

- `MktgOps::01: Scoping`: Issues that are assigned, but need to be scoped in order to start work or add to the backlog.

- `MktgOps::02: On Hold`: Issues that are currently on hold due to timing or otherwise

- `MktgOps::03: Backlog`: Issues that are ready to work, to be slotted to a milestone in the future or in a current milestone waiting to be worked

- `MktgOps::03: Assigned`: Issues that are ready to move forward, slotted to a milestone, and assigned to MktgOps team member

- `MktgOps::04: In Progress`: Issues that are in the current milestone, assigned to MktgOps team member, and are actively being worked

- `MktgOps::04: In Progress`: Issues that are assigned to MktgOps team member and are actively being worked

- `MktgOps::05: Business Owner Review`: Issues in current milestone that needs to be reviewed by the business owner(s) to sign-off

- `MktgOps::06: Ready to Deploy`: Issues in current milestones, sign-off(s) given by business owner, ready to be deployed by MktgOps team member

- `MktgOps::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::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. There should be a corresponding `Mktgops-Blocked` label added to add more context.

- `MktgOps::08: Completed`: MktgOps has completed their task on this issue although the issue may not be closed.

</details>

<details>

<summary markdown='span'>

Blocked Labels

</summary>

- `Mktgops-Blocked:: Blocked by related issue` - Blocked by another issue. That issue should be linked.

- `Mktgops-Blocked:: Pending review / approval` - Blocked for MktgOps team - requires business owner review or approvals

- `Mktgops-Blocked:: Needs more information` - Issue requires more information from requestor or others in order to move forward

</details>

### Milestones

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.

At the end of every milestone, if not complete, the assignee should add context as to why an Issue is moving to a new milestone. 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.

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.

<div class="flex-row" markdown="0">

  <div>

The current enrichment criteria is the following:

1. `Owner Profile` contains `SDR, Sales Development` *AND* `Initial Source` equals `AE Generated, Cognism, DiscoverOrg, Email Request, etc.`, `Lead Status` equals `Accepted`, *AND* `Created By` not equal to `Marketo Integration, Outreach Integration`;

2. `Last Interesting Moment Date` equals `Last 30 Days` *AND* `[PQL] Product Qualified Lead` equals `True` *AND* `[PTPT] Score Group` equals `4,5`;

3. `Initial Source` equals `Zoominfo` *AND* (`Phone` equals `blank` *OR* `Email` equals `blank`) *AND* `Demographic Score` greater than `59`;

4. `Initial Source` equals `Request - Contact` *AND* (`Phone` equals `blank` *OR* `Email` equals `blank`) *AND* `Lead Owner` does not contain `disq,inel,jihu`.

5. `Lead Status` equals `MQL, Accepted, Qualifying` *AND* `Vartopia Partner Account` equals `blank` *AND* Campaign Field - `Member First Responded Date` equals `Current FY` *AND* Campaign Field - `Campaign Type` equals `Trial` *AND* `[Cognism] Automatically Enriched` equals `False` *AND* `Account Demographics: Region` equals `EMEA`.

1. Owner Profile contains `SDR, Sales Development` *AND* Initial Source equals `AE Generated, Cognism, DiscoverOrg, Email Request, etc.`, Lead Status equals `Accepted`, *AND* Created By not equal to `Marketo Integration, Outreach Integration`;

2. Last Interesting Moment Date equals `Last 30 Days` *AND* [PQL] Product Qualified Lead equals `True` *AND* [PTPT] Score Group equals `4,5`;

3. Initial Source equals `Zoominfo` *AND* (Phone equals `blank` *OR* Email equals `blank`) *AND* Demographic Score greater than `59`;

4. Initial Source equals `Request - Contact` *AND* (Phone equals `blank` *OR* Email equals `blank`) *AND* `Lead Owner` does not contain `disq,inel,jihu`.

5. Lead Status equals `MQL, Accepted, Qualifying` *AND* Impartner Partner Account equals `blank` *AND* Campaign Field - Member First Responded Date equals `Current FY` *AND* Campaign Field - Campaign Type equals `Trial` *AND* [Cognism] Automatically Enriched equals `False` *AND* Account Demographics: Region equals `EMEA`.

6. WIP to enrich APJ phone numbers - `Account Demographics: Territory` contains `APJ` *AND* (Phone is `NULL` *OR*  Mobile is `NULL`) *AND* Account Demographics: Territory does not contain `SMB` *AND* Account Demographics: Employee Count is greater than `101`

## Cognism Licensing Policy & Procedures

|*Attended Webcast | Webcast > Attended, <br> Webcast > Attended On-demand | +40 | Every time|

|*Conference Booth | Conference > Visited Booth| +20 | Every time|

|*Content Syndication downloaded| Content Syndication > Downloaded| +10| 1/30 days|

|*Content Syndication - Double Tap (currently inactive)| Gated Content > Downloaded (second asset download detected) |+20|1/30 days|

|*Gated Content - High|Gated Content > Downloaded (must contain Forrester or Gartner)| +35|Everytime|

|*Gated Content - Med|Gated Content > Downloaded|+15|  Everytime|

|*Paid Social | Paid Social > Responded  |+10| Everytime|

---

title: "GitLab for Startups Program Workflows"

description: "This page explains at a high level how **GitLab for Startups** applications move through **Marketo, Salesforce, and Traction**, and how applicants are routed to the Community team and Sales Dev."

---

## Systems and roles

- **Marketo**: Captures Startup applications, manages program membership, Interesting Moments, and scoring.

- **Salesforce (SFDC)**: Stores leads/contacts, Startup Program fields, Total Funding, and campaign membership.

- **Traction**: Routes MQLs and high‑priority leads to Sales Dev and AEs.

**Primary DRIs**

- **Community / Startups Program** – reviews applications and sets program decisions.

- **Marketing Operations** – owns Marketo program, forms, sync to SFDC, and Traction routing rules.

- **Sales Dev** – works qualified but **rejected** Startup applicants.

---

## Key fields and values

### Shared Marketo/SFDC fields

- **Source**: `Startup Application`  

  - Set for all Startup application form fills.  

  - Used in Traction to branch into the Startup‑specific routing path.

- **Startup Program Status** (on lead/contact) – main statuses:

  - **Under Review** – application submitted and being reviewed by Community.

  - **Qualified for Seed Y1** – approved with Seed‑level Startup pricing.

  - **Qualified for Early Y1** – approved with Early‑stage Startup pricing.

  - **Denied from Startups Program** – not a fit and no Sales Dev follow‑up.

  - **Rejected Startup Lead Re‑engage** – not approved for the program but should be routed to Sales Dev.

- **Total Startups Funding** (SFDC) / **Total Funding** (Marketo)  

  - Captures company funding band on the application.  

  - Drives reporting and potential future segmentation.

---

## End-to-end Workflow

### 1. Application submitted

1. Prospect fills out a **Startup application form** (Marketo).

2. Marketo:

   - Creates/updates the person.

   - Adds them to the **Startup Application** program.

   - Logs an **Interesting Moment** for the form fill.

3. Marketo syncs the record to SFDC:

   - **Source = Startup Application**

   - **Startup Program Status = Under Review**

   - **Total Startups Funding** populated.

---

### 2. Program decision

The Community / Startups Program team reviews the application and updates **Startup Program Status**:

- **Approved**  

  - **Qualified for Seed Y1** or **Qualified for Early Y1**  

  - Startup pricing is granted; opportunities and owner/AE workflows follow the Startups Program’s standard process (documented on the broader Startups Program page).

- **Denied**  

  - **Denied from Startups Program**  

  - Leads remain visible for reporting but do **not** intentionally feed Sales Dev follow‑up via this workflow.

---

### 3. Rejected but good fit for Sales Dev

If an applicant is **not** approved for Startup pricing but is still a good fit for GitLab:

- Status is set to **Rejected Startup Lead Re‑engage** (replaces legacy “Denied – Sales Dev to re‑engage”).

- A Marketo smart campaign:

  - Watches for this status.

  - Ensures the lead **MQLs via scoring** (no direct status jump).

  - Logs an **Interesting Moment** to give Sales Dev context.

Once the lead reaches **MQL**:

- Marketo updates Lead Status per global lifecycle.

- Lead enters **standard Traction MQL routing** (same FY27 rules as other MQLs).

- Ownership is assigned based on territory and account coverage (BDR/SDR/AEs), while **Startup Program Status = Rejected Startup Lead Re‑engage** preserves context.

| 3A. Contact leaves Company with Opportunity is in stage 3 and beyond                                                                         | Contact        | AE and Renewal Manager         | UG - No Longer at Company = True<br>Count of Open Opps GREATER THAN 0<br>Stage != 0-Pending Acceptance,1-Discovery,2-Scoping                                                                                             | Active |

| 3B. Contact leaves Company with Opportunity is in stage 1 or 2.                                                                              | Contact        | AE and Renewal Manager  | UG - No Longer at Company = True<br>Count of Open Opps GREATER THAN 0<br>Stage = 0-Pending Acceptance,1-Discovery,2-Scoping                                                                                              | Active |

#### UserGems Lead Routing 

- **Summary**

  - UserGems may only assign/reassign a narrow pilot cohort of leads (owned by integration users), must honor existing “Do not route” logic, and can only be enabled/changed with Gillian’s approval.

- **Ownership Constraints**

  - UserGems may **assign or reassign leads only when the current owner is**:

    - `Marketo Integration` (or equivalent Marketo integration user)

    - `UserGems Integration` user

    - Queue owned leads.

  - UserGems **must not change ownership** for leads already owned by a named rep, or any non-integration user.

- **“Do Not Route” protection**

  - The **existing “Do not route” logic must be honored in all UG workflows**.

  - If a lead is marked “Do not route” (or equivalent field/flag), **UserGems must not assign or reassign** that record.

  - Routing workflows must explicitly check this flag before any UG-driven assignment.

- **Approval & governance**

  - **Gillian’s approval is required** before:

    - Turning on UG-powered lead assignment/reassignment in production.

    - Expanding UG routing to any new segments, or objects.

  - Any changes to UG routing logic must be documented and shared with Gillian and Marketing Ops before deployment.

- **Scope of UG routing**

  - UG routing is used **only for UserGems-sourced or UserGems-managed cohorts** (e.g., UG campaigns / signals), not as a global replacement for all lead routing.

### Dynamic Layouts

On both the lead & contact object, on the top right side, if this is a UserGems Lead or a UserGems Past Contact, you'll be able to reference, at a glance relevant information like: Current Lead Link, Past Contact Link, Current Account, Current Account Type, Current Title, Current Email along with many other fields that are relevant.