lead-scoring

Lead Scoring

Framework(s) used: ICP scorecard (100-pt weighted), BANT, CHAMP — ICP scorecard is the primary; BANT and CHAMP are layered on top for sales-readiness checks. If multiple frameworks apply, trigger Clarification Protocol so the user picks.

Score each enriched Lead against the 100-point ICP scorecard from icp-definition, layer in BANT and CHAMP qualification, weight by trigger strength × recency, write the result onto the person record (score, priority, icp_tier), and emit a scoring run interaction with the full math. Pure compute — no external API keys needed.

Clarification Protocol

When you encounter any of the following, STOP and ask the user — do NOT make a silent assumption, and do NOT flatly refuse:

• Ambiguous or missing input
• A fork in approach (multiple valid frameworks, segments, scopes, or sources)
• A rule that would block progress
• An assumption that materially shapes the output
• Unverified data that a downstream step depends on

Present 2–4 concrete options with trade-offs and your recommendation.

Format:

Decision needed: <what's being decided> Options:

• A) <option> — trade-off
• B) <option> — trade-off
• C) <option> — trade-off My recommendation: <X> because <reason>. Confirm or pick a different option before I continue.

Refusing to proceed is NEVER the final answer. Every "block" must come with an override option. If the user picks an override, honor it on the first request — do not re-prompt the same block multiple times in one run.

Scope

This skill ONLY produces scored lead records with score, tier, reasons, and BANT/CHAMP status. Do not expand into adjacent topics. If the user's request implies adjacent scope, trigger Clarification Protocol with options to (A) stay in scope, (B) note the adjacent need as a follow-up, (C) hand off to a different skill.

When to Use

• "Score these enriched leads against our ICP"
• "Tier 1 / 2 / 3 our weekly sourcing batch"
• User needs SAL hand-off for candidates
• Re-score leads sourced 60+ days ago — triggers may have decayed
• Retroactively score closed-won deals to validate ICP cutoffs
• Pre-outreach prioritization after data-enrichment

Legend — Tier bands and Confidence

• Tier 1 — score ≥75 (SAL-ready candidates)
• Tier 2 — score 55–74
• Tier 3 — score 40–54
• Anti-ICP — score <40
• [H] confidence — fully enriched, no [unverified] critical fields
• [M] confidence — partial enrichment, one or two [unverified] non-critical fields
• [L] confidence — [unverified] critical field(s) present, score capped at 60

Quick Reference

Concept	Value
Rubric weights	Pain 25 / Trigger 20 / WTP 20 / Reach 15 / TTV 10 / Strategic 10 = 100
Tier cutoffs	T1 ≥75 / T2 55–74 / T3 40–54 / Anti-ICP <40
Trigger formula	trigger_score = base_strength × decay(days_since_event, half_life)
BANT / CHAMP	Each dimension: `confirmed
SAL gates (Tier-1)	ICP fit + trigger present + decision-maker IDed + no hard disqualifiers
Score-cap rule	[unverified] field → cap at 60 (Tier-2 max), route to review
Healthy distribution	10–20% T1 / 30–45% T2 / 25–35% T3 / 5–15% Anti-ICP
CRM score mapping	75–100 → 5; 55–74 → 4/3; 40–54 → 2; <40 → 1

Procedure

1. Check for the scoring script. Look at ${HERMES_SKILL_DIR}/scripts/scoring.py.
   • If it exists and matches the documented contract, use it.
   • If it does NOT exist, generate it ONCE per the documented contract (see ${HERMES_SKILL_DIR}/references/scoring-script-spec.md), persist it to ${HERMES_SKILL_DIR}/scripts/scoring.py, then ask the user to confirm/commit.
   • Do NOT regenerate the script if it already exists. 1a. Validate inputs. Confirm Lead records have required fields and ICP scorecard is loaded. Reference ${HERMES_SKILL_DIR}/references/scoring-deep-reference.md for rubric dimension definitions. If lead input is not fully enriched, trigger Clarification Protocol: "Lead input is not fully enriched. Options: (A) enrich first via data-enrichment, (B) score on partial data with reduced confidence (output flagged partial-data, score capped at 60), (C) abort. Recommend A unless time-sensitive." Honor user override on first response — do not re-prompt the same block.
2. Apply 100-pt scorecard per dimension. Compute Pain (P-T-O chain), Trigger (strength × decay), WTP (firmographic + funding), Reach (verified email/phone/linkedin), TTV (role + stage + stack friction), Strategic (logo, vertical anchor). Per-dimension rationale one-liner. After every tool call, summarize what you received and what you'll do next — never return an empty response after a tool call. If a tool result is empty or errored, surface that to the user with options.
3. Apply BANT and CHAMP in parallel. Populate Budget/Authority/Need/Timing AND Challenges/Authority/Money/Prioritization (confirmed | inferred | unknown). Apply BANT adjustment to base score.
4. Compute final score, tier, priority. final_score = scorecard_total + bant_adjustment (capped 100). Apply tier cutoffs from icp-definition.
5. Apply SAL criteria (Tier-1 only). Check 4 gates: ICP fit ≥75 / trigger within half-life / decision-maker identified / no hard disqualifiers. Pass all → sal_eligible: true.
6. Tier distribution + per-record rationale. Aggregate tier counts; flag suspicious distribution (>50% T1 = rubric too lenient; <2% T1 = source too wide). Compose 2–3 sentence rationale per record.
7. PATCH person + emit run interaction. Run ${HERMES_SKILL_DIR}/scripts/push_to_crm.py. PATCH score, priority, tier tags. Emit interaction:research with full math. [unverified] records to review queue. Run ${HERMES_SKILL_DIR}/scripts/dedup_leads.py if needed.

Pitfalls

• Scoring [unverified] records as if verified — score-cap is the feature; never bypass
• Tuning rubric weights inside the scoring run — that's icp-definition's job; drift ruins comparability
• Ignoring trigger decay — "raised Series B 14 months ago" scoring 80 means decay isn't running
• Treating Tier-1 count as a target — T1 ratio is an output, not an input
• Skipping the SAL gate — Tier-1 by score doesn't mean SAL-ready; 4-gate check is the contract
• Mixing rubrics across product lines — each ICP gets its own scoring run
• Regenerating scoring.py when it already exists at the documented path (${HERMES_SKILL_DIR}/scripts/scoring.py) — check first; generate ONCE only
• Returning an empty response after a tool call — always summarize the result, even if errored or empty

Verification

1. Re-running same record set with same rubric produces same scores ± trigger-decay drift
2. Every score rationale references actual record signals — no invented details
3. Tier distribution is justified by source — sourcing output and scoring ratios are coherent
4. SAL eligibility computed per Tier-1 and failed gates named
5. Rubric weights match icp-definition artifact verbatim
6. Every tool call is followed by a summary of what was received and the next step — no empty responses

Output Format

• Sections required: Scored CSV, Summary Report, Assumptions to Validate
• Tables / fields: Per record — lead_id, score, tier, reasons[], bant, champ, confidence; Summary — score-distribution histogram, top-10 reason explanations, flagged-low-confidence count
• Length target: Summary ≤500 words
• File type: CSV (UTF-8, RFC 4180) for scored leads + markdown for summary
• Mandatory closing sections: Summary Report (distribution, top reasons, low-confidence count), Assumptions to Validate, Recommended Next Skill (cold-email or SAL hand-off)