How GitLab turned intent signals into same-day work for its BDRs
- Company
- GitLab sells a DevSecOps platform to companies, for their software teams to build, secure and deploy code. Visit GitLab ↗
- Sales development
- SDRs handle inbound; BDRs run outbound with an AE
TL;DR
In 2022 GitLab’s BDRs chose all their own priority accounts and could keep them with no time limit. Since 2024 a 6sense intent flag also puts accounts on their list. The BDR has to accept or dispute each one the same day, and each account gets a recycle date two months out. Reps can still add their own accounts with an AE.
The lesson
An intent signal changes what reps do once it sets the account’s status, a rep has to accept or dispute it the same day, and the account gets a recycle date. GitLab got there in four dated handbook edits between 2022 and 2026.
For your team
Let a signal set the account’s status, ask a rep to confirm it the same day, and give every account a recycle date.
What GitLab did
The starting point
In February 2022, GitLab’s outbound reps chose their own priority accounts and could keep them for as long as they kept reaching out.1a
That month GitLab split sales development: SDRs took inbound leads, and BDRs, its business development reps, took outbound. Ed Bao, later listed in Sales Dev Operations, rewrote the team’s handbook page and added a Salesforce status, Actively Working, for the accounts each BDR chose to work.1,2
The handbook left that choice with the rep and their strategic account leader (SAL):
“An account researched and chosen by the BDR and/or SAL- based on alignment to ICP, news insights, company initiative, intent, ABM list etc. This is an account that the BDR will proactively be performing strategic outreach to. There is no limit to how long an account can stay in “Actively working” status as long as outreach is continuing to be made.”
The problem
The handbook never states the problem. Read in order, the edits suggest two: accounts could stay listed indefinitely, and reps had to remember to check intent data.
On June 14, 2023, Ed Bao replaced the “no limit” sentence with a recycle date 10 weeks out.3
After GitLab moved from Demandbase to 6sense in 2023, Panos Rodopoulos, also of Sales Dev Operations, made a 6sense check “mandatory for FY24Q3,” GitLab’s fiscal quarter from August to October 2023, without giving a reason.2,4,5 A 6QA, 6sense’s qualified account, means a Moderate or Strong profile fit and a Decision or Purchase buying stage at GitLab.6
In March 2024 he documented an automation that pushes 6QA accounts into Salesforce, to find “the top accounts we currently have on SFDC that are not being worked by our team.”7
The rule, rewritten in publicb
“Actively Working” Status: An account researched and chosen by the BDR and/or SAL […]
Feb 8, 2022Ed Bao writes it, !98516
There is no limit to how long an account can stay in “Actively working” status as long as outreach is continuing to be made.When an account is moved into Actively Working, a Recycle Date will automatically be populated with a date 10 weeks ahead.Jun 14, 2023Ed Bao sets an end date, !125877
When an account has been automatically moved to Actively Working and Showing Intent, […] you will need to review the account and change this field to Accepted or Disputed within 48 hours.
Sep 5, 2024Panos Rodopoulos hands it to 6sense, !8290
The BDR must then act
within 48 hourson the same day:Aug 19, 2026Elsje Smart makes it the same day, !20777
The decision
September 5, 2024
6sense intent starts putting accounts on the BDR’s list, and reviewing them becomes mandatory.
A 6QA moves the account into Actively Working, and the BDR gets 48 hours to accept or dispute it.
Panos Rodopoulos gave his reason in one line of the merge request: “In conjunction with our initiative to drive more 6QA adoption […] adding more clarity and SLAs to our handbook.”8
September 2024

August 2026, merge request !20777 by Elsje Smart

The redesign
The BDR has to review every account 6sense flags the same day, and every account gets a recycle date.
Three weeks later, Rodopoulos wrote out the process. Accounts flagged as 6QA, “whether they already exist on our system or not,” become Actively Working, and “team members need to still review and accept or dispute a 6QA account.” A dispute needs a reason, such as an open opportunity or, since January 2025, “Low LAM Dev Count,” meaning small potential value.10,11,12
On August 19, 2026, Elsje Smart, Regional Director of GitLab’s EMEA BDR team, who had also merged Ed Bao’s 2022 rewrite, cut the review to the same day. Her merge request’s whole description is “KPI update and tidy up.”9,11
Every Actively Working account also carries a recycle date two months out, set when the status changes.11
A BDR can still pick accounts with an AE, under strategies such as job-change tracking or Event Follow-up, and the same rules apply.11c
Actively Working also decides who gets the account’s inbound leads and website chats, however it got there.11,13,14
The result
The handbook sets a target of 75 or 125 new Actively Working accounts per BDR per quarter, for Enterprise and Mid-Market.15
Bill Staples, GitLab’s CEO, made first orders, companies with no commercial relationship yet, a company priority in 2025, after they had slowed.16 GitLab reports first-order growth, but credits a dedicated first-order team and product-led growth. “Our dedicated first order organization is building more repeatable sales motions, while our product led investments are widening the top of the funnel.”17
What it took
Turning intent signals into same-day work took GitLab four and a half years of small, dated handbook edits, mostly by Sales Dev Operations.2,18
6sense scores intent against a written threshold, Salesforce holds the status, and a lead-routing tool, a website chat tool and a contact-data tool act on it.6,11,13,14 Since September 2026 an AI research agent called Atlas also writes account research back to Salesforce when the status changes.18
Each week, managers clear the queue of waiting accounts, review overdue recycle dates and recheck weak 6QAs.11
Each handbook edit is a public merge request, with the date, the author and the lines changed.18
What to borrow
- Have the signal change a field on the account. At GitLab, lead routing and website chat read Actively Working as well as the BDR, so one 6sense flag changes who gets the account’s inbound too.
- Ask a person to confirm it the same day, with a reason when they decline. GitLab’s dispute reasons show where the signal misses, such as an account already in an open deal.
- Set the end date on the day the field changes. By that date the account has moved forward, been given more time for a stated reason, or been recycled.
How to build a version of this in Unify
Build it in Unify
Everything above is GitLab’s own system. This section is our suggestion for a version in Unify.
GitLab joined 6sense intent, Salesforce fields, a contact-data tool and routing rules itself. Unify combines your CRM, warehouse and product usage data with enrichment from 40+ sources, with warehouse data synced in through a sync tool or the API.
A first version needs one Audience and one Play. Build the Audience from accounts that fit your profile and show a Signal. When an account enters it, the Play assigns an owner, finds people across your personas and starts a Sequence whose first step is an Action item due the same day, to accept or dispute the account with a reason. Emails wait for the rep’s approval, and the recycle date stays in your CRM.
One account, from signal to next step
- Account
- Origin LabsIn your Audience: fits your profile, no open opportunity.
- Signal
- Two people viewed pricing this week, and three SDR roles went upFrom Signals: website visits and hiring.
- Why it matters
- A company hiring SDRs is building outbound now, and someone there is comparing pricesAI Research writes this on the owner’s task.
- Next step
- The owner accepts or disputes it today, then calls the Head of Sales Development. Emails wait for approval.From the Play: owner assigned, people found, Sequence started.