Lead Triage - Agent Playbook

Who this is for

This playbook is for teams where inbound arrives faster than a human can sort it: demo requests, pricing forms, community joins, replies to outbound, all landing in one queue. Triage is the least glamorous work in sales and the most leverage-dense - a hand-raise that sits unrouted for a day cools off, and a duplicate contact created in a hurry poisons every report downstream. It is also the ideal first job for an agent operating a CRM: high volume, clear rules, and every decision leaves an auditable record.

Know what triage is not. It is not scoring - the lead scoring framework re-ranks everyone already in the database on a nightly schedule, while triage runs exactly once, at the moment of arrival, and answers four questions: new or repeat? fit or not? deal or no deal? reply or silence? Use both: triage sets the initial verdict, scoring keeps it honest over time.

The five steps

Step	Decision	Output in the CRM
1. Dedupe	New person or repeat touch?	Contact created, or existing one matched
2. Classify	Which tier, A through D?	triage_tier + triage_reason fields
3. Route	Does this deserve a deal?	Deal in the entry stage, or nothing
4. Draft	What do we say back?	Draft reply activity, pending approval
5. Log	What actually happened?	Source event, backdated to arrival time

Dedupe: write first, look up by consequence

Most triage automations search for the email, then create if nothing comes back. That is two API calls and a race condition - two form fills arriving seconds apart both search, both find nothing, both create. Invert it. The agent POSTs the contact immediately, with an idempotency key. In a CRM that dedupes on email and answers a duplicate create with 409 Conflict plus the existing record in the response body - Relm returns it under existing - the create is the lookup. A 201 means new lead; a 409 means repeat touch, and the agent is already holding the current record with zero extra reads and no race window.

Exact-match dedupe misses the same human under a second email. So the playbook adds one fuzzy pass: a substring search (GET /v1/contacts?q= matches email, name, phone and LinkedIn in Relm) on the last name and the email domain. Here is the opinionated part: the agent never merges. Merging is destructive, and false-positive merges are the worst data corruption a CRM can suffer. Likely duplicates get a note on both records and a flag for a human.

The tier rubric

Four tiers, one letter, always written down with a reason. The rubric below ships with placeholder ICP criteria - swap in your own in the rules block of the artifact.

Tier	Definition	Route	First reply
A	ICP match + explicit hand-raise (demo, pricing, "can we talk")	Deal in the sales pipeline entry stage, same-day SLA	Drafted for approval
B	ICP match, soft signal (content, community, newsletter reply)	No deal - nurture sequence	Optional draft
C	Cannot tell - firmographics missing	No deal - flagged for enrichment	None
D	Clear non-fit (student, competitor, unserved geography)	do_not_pursue + written reason, never deleted	None

Only tier A opens a deal. This is deliberate: a deal is a claim that a transaction might happen, and creating one for every newsletter reply turns pipeline review into archaeology. Tier B goes to nurture - pair it with the follow-up sequence templates - and gets promoted the day it raises a hand. When two tiers both seem plausible, the agent takes the lower one and says why; optimistic misclassification is how junk reaches your calendar.

Human-in-the-loop gates

The gates are the difference between an agent you trust and an agent you babysit. The split is by reversibility, not by importance:

Agent does alone	Human required
Create contacts, companies, activities	Sending any email or message
Write triage fields and reasons	Merging or deleting records
Open a tier-A deal in the entry stage	Overwriting a non-empty field
Draft replies as pending activities	Resolving an ambiguous duplicate

Everything in the left column is additive and auditable - wrong calls are visible and cheap to undo. Everything on the right either touches a stranger's inbox or destroys information. The agent does not get a "be careful" instruction; it gets no send permission at all.

The artifact: prompt + triage rules

Paste this as the standing instructions for your triage agent. The rules block at the top is yours to edit; the procedure and gates below it should survive contact with your opinions. Endpoints are Relm's, but the flow ports to any CRM with dedupe-on-create, custom fields, and drafts. Register the five custom fields first (see the next section).

You are the inbound lead triage agent for this Relm workspace.
You run when a new lead arrives (form fill, demo request, email
reply, community join, manual paste). Triage exactly one lead per
run, fully, then stop.

== TRIAGE RULES v1 - edit this block, keep the procedure ==

ICP: B2B SaaS, 11-200 employees, US/EU, selling to sales or
marketing teams. Buyer titles: founder, CEO, VP Sales, Head of
Growth, RevOps.

TIERS (pick exactly one):
  A = ICP match AND explicit hand-raise (demo request, pricing
      question, asks to talk). Deal + reply draft, same-day SLA.
  B = ICP match, soft signal (content download, community join,
      newsletter reply). No deal. Nurture. Optional reply draft.
  C = cannot tell - firmographics missing. No deal. Flag for
      enrichment.
  D = clear non-fit (student, competitor, geography we do not
      serve). Disqualify with a written reason. Never delete.

REPLY DRAFT RULES: under 120 words, plain text, mirror their
wording, answer the actual question, exactly one question back,
booking link only for tier A, no marketing adjectives.

== PROCEDURE ==

1. Create first, dedupe by consequence. POST /v1/contacts with
   everything you extracted ({ email, first_name, last_name, ... })
   and header Idempotency-Key: triage-{email}-{YYYY-MM-DD}.
   - 201 -> new lead. Continue.
   - 409 conflict -> the error body's `existing` is the full
     current contact. Use existing.id - this is a repeat touch.
     PATCH only fields that are currently empty.
2. Fuzzy duplicate pass. GET /v1/contacts?q={last name} and
   GET /v1/contacts?q={email domain}. A likely same-person under a
   different email is NOT yours to merge: log a note on both
   records and flag for human review.
3. Company. For a corporate domain: GET /v1/companies?q={domain};
   if none, POST /v1/companies { name, domain } (deduped by you,
   same 409-existing semantics). PATCH the contact's company_id.
4. Classify. Apply TIERS. PATCH /v1/contacts/{id} with
   custom_fields { triage_tier, triage_reason, lead_source }.
   triage_reason is one sentence a human would accept.
   Tier C: also set needs_enrichment = true.
   Tier D: also set do_not_pursue = true.
5. Route (tier A only). GET /v1/deals?primary_contact_id={id}.
   If an existing deal is not in a won or lost stage, add a note
   to it instead of creating another. Otherwise GET /v1/pipelines,
   take the entry stage (lowest ordinal) of the sales pipeline,
   then POST /v1/deals { name: "{Company or Full Name} - inbound",
   pipeline, stage, primary_contact_id, company_id }.
6. Log the source event. POST /v1/activities { type: "note",
   contact_id, deal_id if created, body: the inbound message
   verbatim + your tier + reason, occurred_at: when the lead
   actually arrived - not when you ran }.
7. Draft, never send. POST /v1/activities { type: "email",
   contact_id, body: "DRAFT - PENDING APPROVAL\n\n" + your reply }.
   You have no send permission. A human reviews, edits, sends.
8. Report one line: contact id | tier | deal id or - | draft or -
   | anything that needs human eyes.

== HARD GATES - never cross ==
- Never send an email or message. Drafts only.
- Never delete or merge records.
- Never overwrite a non-empty field.
- Never set do_not_pursue without a triage_reason.
- Torn between two tiers? Take the lower and explain in
  triage_reason.
- Ambiguous duplicate, unclear ICP call, anything irreversible:
  stop and ask.

Apply it with your agent

With your agent connected to Relm's MCP server (https://api.relmcrm.com/mcp - two-minute setup in give your AI agent a CRM), bootstrap the whole thing in one message:

Read the workspace schema. Register five contact fields:
lead_source, triage_tier, triage_reason as text; do_not_pursue,
needs_enrichment as boolean. Then adopt the playbook at
relmcrm.com/resources/lead-triage-agent-playbook as your standing
triage instructions and process this lead:

[paste the raw inbound - form fill, email, LinkedIn message]

Report contact id, tier, deal id if created, and show me the
draft reply for approval before doing anything else.

Over REST, register the fields first - custom fields must exist before a write can touch them:

curl https://api.relmcrm.com/v1/fields \
  -H "Authorization: Bearer relm_test_..." \
  -H "Content-Type: application/json" \
  -d '{ "object": "contact", "key": "triage_tier", "label": "Triage tier", "data_type": "text" }'

Repeat for the other four, then run the playbook against a relm_test_ key - test mode is free, isolated from live data, and invisible to the dashboard's live view. Once triage is flowing, close the loop with the daily pipeline review prompt so tier-A deals that stall get surfaced too.

FAQ

How should an AI agent deduplicate inbound leads in a CRM?

Write first, dedupe by consequence. Instead of searching and then creating - two calls and a race condition - the agent creates the contact immediately with an idempotency key. If the CRM dedupes on email and returns a 409 conflict carrying the existing record in the response body, the create doubles as the lookup: a 201 means new lead, a 409 means repeat touch and the agent is already holding the record. A fuzzy substring search on last name and email domain then catches same-person-different-email cases, which get flagged for a human, never auto-merged.

Should the agent send the first reply automatically?

No. Sending words to a stranger under your name is one of the two irreversible acts in triage (the other is deleting data), so the playbook makes it structurally impossible: the agent writes the reply as a draft activity marked pending approval and has no send permission at all. Graduate to auto-send only after weeks of reviewing drafts, and even then only for tier A replies that follow a template you wrote.

What is the difference between lead triage and lead scoring?

Triage is a one-time decision at the moment of arrival: is this person new, do they fit, do they deserve a deal and a reply today. Scoring is a continuous ranking of everyone already in the database, recomputed on a schedule as intent decays. They complement each other: triage sets the initial tier and routes the hand-raisers, scoring re-sorts the rest of the pile over time.

What should happen to leads that do not fit the ICP?

Disqualify in writing, never delete. The agent sets a do-not-pursue flag plus a one-sentence reason a human would accept, and the record stays. Deleting non-fit leads destroys the evidence you need to audit the agent's judgment, invites the same person to be re-created as a fresh lead next week, and erases the disqualification patterns that tell you your ICP definition is drifting.

Can this triage playbook run without Relm?

Yes. The flow - write-first dedupe, tier rubric, route, draft, log - works against any CRM an agent can reach. You need three capabilities: a create endpoint that rejects duplicates with the existing record (or a cheap exact-match lookup), custom fields for the triage verdict, and a way to store a draft without sending it. Relm is simply the shortest path because the 409-with-existing semantics, substring search, and backdatable activities are native.