How the score is calculated

Last updated: 26 May 2026. Rubric iterated weekly as we accumulate diagnostic submissions.

Full algorithm, weights, and threshold tables published below. This is the entire scoring rubric — same code that runs in production at lib/scoring.ts. We don't gate the methodology behind a sales call. If you can replicate the score on a spreadsheet from this page, that's a feature, not a bug.

The diagnostic is free; the execution is what you pay for

If the entire rubric is published openly, what's the BIGM product? Not the score. It's getting your account into the healthy band and keeping it there at scale.

The diagnostic tells you a 50-connections/day account with 12% acceptance, no IP rotation, and templated touch 1 sits at 20/100 with high ban risk. That's information. Acting on it requires:

• Re-provisioning + aging a pool of 4-6 accounts with residential IPs
• A per-prospect AI rewrite pipeline that doesn't read templated to LinkedIn's classifier
• Live inbox triage so hot replies don't cool off
• Maintaining all of the above as LinkedIn's risk model updates silently each quarter

That execution stack is what Founding 10 + Enterprise pay for. Most cemetery accounts scoring 75+ healthy are NOT running BIGM — they built the stack themselves over 18-24 months, burned 4-8 LinkedIn accounts in the process, hired the right ops people. BIGM is for teams that want the end-state without the 18-month learning curve.

Transparency on the rubric is the moat, not the secret. Copy the algorithm; you still have to ship the execution and maintain it. The published rubric proves we understand the problem; the price tag covers solving it.

Sample-size honesty

The score is a weighted average over 8 inputs you self-report. The weights are anchored to: (a) public 2024 industry benchmarks (Apollo, Lemlist, Lavender, Hunter.io), (b) restriction-event pattern data from outbound platform aggregates, (c) operating experience of the BIGM founding team running LinkedIn outbound at scale.

We do NOT currently have a large enough primary-research dataset to publish per-input correlation coefficients with downstream outcomes (restriction events, reply rate distributions per band). That arrives once the diagnostic accumulates enough submissions to be defensibly publishable. Until then this is best-effort scoring built on cited public sources + practitioner judgement, not original longitudinal research. We say so up-front.

The 8 inputs

1. Connections per day — your average new connection requests sent
2. Acceptance rate — % of those requests that get accepted
3. Restricted recently — any account restriction in the last 90 days
4. Reply rate — % reply rate on cold outbound messages
5. Account count — 1 vs 2-3 vs 4+ accounts in the outbound pool
6. IP rotation — none / VPN / residential / managed automation
7. Personalization tier — template / first-name / AI-rewritten / manually researched
8. Account age — <6mo / <1y / 1-2 / 2-4 / 4+ years

Weighting

Each input becomes a 0-10 subscore. The subscores are weighted:

Then:

• flat -15 if the account was restricted recently
• flat +3 if Sales Nav is in use
• flat -5 if monthly tool spend > $500 AND reply rate < 5%

Final score is the weighted average normalized to 0-100.

Per-subscore threshold tables

Each input becomes a 0-10 subscore using the exact bands below. Replicate-on-spreadsheet friendly.

Volume (connections per day)

Acceptance rate

Reply rate

Account pool

IP rotation

Personalization tier

Account age

Verdict bands

Where the numeric thresholds come from

• Volume ceiling 20-25/day: derived from observed restriction events on LinkedIn outbound platforms in 2024-25
• Acceptance bands (25-35% healthy): industry baseline reported by multiple managed-outbound vendors
• Reply rate 5-12%: B2B cold LinkedIn benchmark from 2024-25 operational data (Apollo, Lemlist, Lavender)
• Restriction recovery + second-restriction interval: pattern observed on dozens of restricted accounts BIGM has touched

The thresholds are calibrated against operational data, not a single research paper. As the diagnostic accumulates more real submissions (see the Cold Outreach Cemetery for the in-progress primary dataset), the calibration will update.

Who actually runs your pool

BIGM is a service before it's software. The persona-agent engine is the tool; the differentiator is the human who configures it per-pilot and tunes it weekly. Founding 10 pilots get weekly 1:1 with one of the two co-founders for the duration of the pilot — we're not handing you to an offshore account manager. If the persona needs retuning mid-flight, the same human who set it up does it.

Pre-contract intro call available before any pilot signature. Founder names + backgrounds are on the trust + security page; book via oguz@bigm.live.

Data residency + GDPR

EU customer data hosted in eu-west-1 (Frankfurt) on request, US-East default otherwise. Founding 10 pilots get eu-west-1 provisioning at no additional charge. Full residency posture + DPA terms + GDPR Article 28 sub-processor list live on the trust + security page. Sign-able PDF version on request from press@bigm.live. SOC 2 Type II customer-driven, starts when first paid pilot's procurement requires it.

What the tool does NOT do

• It does not call LinkedIn or scrape your profile. You self-report numbers; honesty in = useful out.
• It does not predict ban dates. The "ban risk: high" type language is a heuristic read on the combination of signals, not a clock.
• It does not capture data without consent. The score is computed server-side from the answers you submit; we only log the result against an email if you submit one via the email-gate form.