Methodology

How OrgDrift decides who’s sales-eligible

When you scan HR against a commissions system, the headline question is: who’s on a comp plan, and who should be? Getting that right means filtering HR down to the people who’d be on a comp plan in the first place — otherwise every non-sales employee reads as “missing from ICM,” and the findings list drowns in noise.

We use a three-layer cascade. The output is fully visible — which columns, which values, which rows. You can override any of it.

The cascade

Three layers, in order of confidence

Layer 1 · Strongest

Compensation columns on the HR file

If your HR file has a commission target, quarterly bonus, or annual bonus column with a non-zero value for a row, that row is clearly on a comp plan. This is unambiguous — it’s real money the comp plan paid out.

OrgDrift maps these columns canonically, so we recognize them under any header (Commission Target, Variable Comp, Annual OTE Bonus, etc.). When this layer fires, we don’t need the layers below it.

Layer 2 · Tenant-specific

Learned from people already in your ICM file

The HR rows that already match a record in your commissions system are, by definition, on a comp plan. We compare what those people have in common — across departments, job titles, cost centers, job families, locations — to everyone else in HR. The columns that separate the two groups cleanly become the eligibility profile for that scan.

This is the layer that handles your tenant’s naming conventions. If your sales org sits under “GTM,” “Field,” “Strategic Accounts,” or anything else outside the standard sales lexicon, this layer learns it from your data. No keyword list to maintain.

Needs at least a few dozen labeled positives in your ICM file to learn a stable profile. Below that floor, we fall through to Layer 3.

Layer 3 · Fallback

Job-title and job-family keywords

When neither comp columns nor a learnable ICM profile is available — common on a tenant’s very first scan, or when the file lacks job-family and comp data — we look for common sales keywords in the title and family columns: AE, BDR, account manager, sales engineer, customer success, RevOps, and so on.

This is the least precise layer. We surface a banner on the scan canvas when this layer is the active filter, nudging you toward Configure cohort to set explicit eligibility for your org.

Layer 0 · Always wins

Your saved cohort configuration

Anything you save in Configure cohort overrides every layer above. Once you tell OrgDrift “these are the dimensions that define eligibility for my organization,” we use that on every subsequent scan. The learned profile keeps showing up in the inspector for comparison, but won’t reset what you saved.

Transparency

What you can see in your own data

Every decision the eligibility filter makes is visible to you. Open the Relationship Inspector on the scan canvas and the “How we figured out who’s sales-eligible” panel shows:

Which columns drove the decision

Department, Job Family, Cost Center, FLSA code — whichever columns separated the matched-to-ICM crowd from the rest of HR most cleanly.

Which values landed in the accept-set

For each predictor column, the actual values we accept (e.g. Sales, Account Management, Customer Success) plus how many matched rows hit each.

How well the profile fits

The share of your ICM-matched HR rows that the predictors capture, so you can sanity-check whether the learned profile is stable for your data.

Which rows pass the filter

Every finding in your scan traces back to the specific row in the file it came from. Eligibility is just one filter on top of that — every row included or excluded is auditable.

The boundary

What we don’t publish

We don’t publish the specific scoring weights, lift thresholds, support floors, or bootstrap minimums the algorithm uses. They’re tuned across many tenants and shift as we improve.

The output is fully transparent — every column, every value, every row visible to you and overridable through Configure cohort. The parameter knobs are the only thing held back, and they’re not what defends a finding to an auditor: the columns and values are.

For your auditor

What this looks like in a SOX / audit walkthrough

The methodology is the cascade itself: comp columns first, then learned-from-data, then keywords, then your saved override. The order, the inputs, and the fallback behavior are all stable across tenants.

The evidence is what the cascade picked for your tenant: the columns it learned from, the values it accepted, the rows that passed and failed. All of it is visible in the scan canvas and exportable from any finding.

The override is Configure cohort. Anything you set there is sticky — your auditor can verify the same dimensions are in effect on every subsequent scan.