gtmos-leads-inbound-triage

Inbound lead triage

Part of GTM OS Skills. Adapted from lead-triage in salesforce/salesforce-skills (Apache-2.0, Copyright (c) 2026 Salesforce, Inc.). Merged with gtm-inbound-lead-enrichment from loootai/gtm-skills (MIT), kept in references/looot-gtm-inbound-lead-enrichment.md. Changed for GTM OS: the operating section below, rewritten cross-references and tool pointers. Notices: THIRD-PARTY-NOTICES.md (installed beside the skills as THIRD-PARTY-NOTICES.md).

With GTM OS connected

Rules (GTMOS-RULES.md). Read policy.get_dry_mode first; in dry mode every effect stops at a draft. E-class operations are proposed and a different person approves them; never approve your own proposal. Numbers come only from operation results, named with the operation. Claims about results, customers or metrics must be backed by active proof from proof.list.

Inbound triage in GTM OS is three engines working one record: Score decides fit and intent, Routing gives it an owner, Outreach drafts the first touch for a person to approve. You read, decide and write internal records; nothing customer-facing leaves without approval. Confirm each schema with gtm_describe before the first call.

1. Find the lead and what GTM OS already knows.

Enrich before you score, business email only. A sign-up gives an email and little else. Free-mail and disposable addresses are flagged, never enriched (the merged looot workflow in references/looot-gtm-inbound-lead-enrichment.md lists the free checks). For a lead with no current company, routing.match_account {contactId} Q finds the account by email domain (free-mail never matches; ties are ambiguous). Missing person or company fields: enrichment.enrich_contacts {ids, estimate: true} (spends inline: quote it first) (and enrichment.enrich_accounts for a new company), then a run on a yes; both spend inside their own call, so quote first and never run them for a personal address.

2. Score it with the engine, not by hand. score.score_contact {contactId} scores the lead against the org's signed model (fit inherited from its account, intent from its own signals). score.explain_subject {subjectType: "gtm.contact", subjectId} returns the band, the points per factor, the top signals and the greyed signals (sources not wired, never imputed). Use the band and reasons as the fit and intent tables below; a greyed signal is "no data", not "no intent". If the account is not scored yet, run score.score_account first.

3. Set the priority. Map the engine's band and the intent signals onto P0, P1, P2 or DQ with the rules below. A hard disqualifier from definition.scoring_model or a match on definition.suppression_rule is DQ, whatever the score.

4. Route it. Preview with territory.match {subjectType: "gtm.contact", subjectId}: the winning territory, its owner or rotation, and why. Then routing.assign {subjectType, subjectId, ownerId | strategy: "territory" | "round_robin", rule, reason} writes the owner and an auditable decision record. It is an internal write; say who got the lead and why. If the account is already owned, assign the lead to that owner and note "existing relationship" (the territory's stickiness does this by default). Round robin skips members who are out of office or at their cap (routing.member_settings.list Q); when nobody can take the lead it goes to the territory's overflow owner or is queued, and the result says so. An exact email-domain match attaches a lead with no company to that account.

5. Set the first touch. task.create {title, subject, dueAt, assigneePrincipalId} with the SLA as the due date (P0 same day, P1 within 48 hours, P2 this week). For the first message, hand off to gtmos-outreach-cold-email: it drafts through the Outreach engine and proposes the send for a person to approve. In dry mode (policy.get_dry_mode) the draft is where it stops.

6. CRM of record. Lead status or owner changes in HubSpot or Salesforce go through crm.update_record (E): it proposes, a different person approves. Never claim the CRM was updated before the approval executes.

7. The inbound responder. The inbound-responder agent in stdlib/pack.crm-agents runs this triage on every form submission (a form_submitted signal): it qualifies the lead, drafts a grounded first reply and proposes the send, or opens a task when the lead needs a person first. packages.agents Q shows whether it is installed; its proposals land in runtime.list_approvals.

Report numbers only from these results. If score.kpis shows too few scored leads to compare against, say so instead of quoting a calibration.

Without GTM OS

Run the method below by hand. Ask for the lead (name, email, company, source, message) and the ICP once. Look the company up on its website and public sources, keep a source for every fit claim, and mark unknown dimensions as unknown. On Salesforce, read the Lead and the matching Account (by name or website) with the tools you have; on HubSpot, the contact and its company. Recommend the owner and the CRM field changes; let the user apply them.

---

The triage method

Read the lead and its account, add what is public, score fit and intent, assign a priority, route, set the first touch. Work from the data you read; do not invent a size, a budget or an intent.

1. Read the lead and its account

• The lead: name, company, title, email, source, status, created date, the message or form answers, current owner.
• The matching account (by company name or domain): type, owner, segment, size, industry.
• If the account exists and has an owner, this is an existing relationship: routing is "coordinate with [owner]".
• Public context when tools allow it: company size, industry, funding, recent news. Prior email threads from the same domain when an inbox is connected.

2. Score ICP fit

Against the ICP (ask once if it is not in the org's definitions or context):

3. Score intent

4. Assign priority

Calibration: P0 about the top 20%, P1 the next 25%, P2 the rest.

• P0: strong ICP fit and high intent (specific ask, demo request, or a hot trigger)
• P1: strong fit with medium intent, or moderate fit with high intent
• P2: moderate fit with low intent, or fit unclear
• DQ: a hard disqualifier hit

Override: if the account exists with an owner, routing is "coordinate with [owner]".

5. Queue view (several leads)

When triaging a batch, add a short summary before the per-lead cards: leads by tier (hot, warm, nurture) with counts and shares, leads by source, and a table of the hot leads (lead, company, fit score, source, next step). One sentence on the single most important read of the queue. Quote blank fields as blank, and drop leads you have no data for.

6. Output (per lead)

# Lead triage: [Name] @ [Company]

**Priority: P[0/1/2/DQ]**
[One-sentence rationale]

## CRM status
[Net new | Account exists, owned by [Name]: coordinate first]

## ICP fit: [Strong / Moderate / Poor]
[fit table]

## Intent: [High / Medium / Low]
[intent table]

## Recommended action
- **Route to:** [self / named owner / DQ queue]
- **Response SLA:** [P0: same day / P1: 48h / P2: this week]
- **First touch:** [e.g. a drafted email with [hook], qualification questions, or a polite no]

## Suggested CRM updates
- Lead status -> [value]
- Lead owner -> [name]
- [Notes field] -> "[triage summary]"

If the lead goes to a teammate, offer to draft a handoff note for the team's lead channel (ask for the channel if it is not known).

Upstream note

This method comes from Salesforce's lead-triage skill, which runs the same steps against Salesforce through the Headless 360 MCP server (GraphQL reads of Lead and Account) and renders a widget. On Salesforce without GTM OS, use that skill's documented queries for the reads; the scoring, priority and output above are unchanged.