Signal-based outreach is a governed workflow that turns a verified event into a permitted, supportable message and reconciled response. A signal is a reason to investigate—not proof that a person is buying, wants contact, has budget, or has a problem your product solves.
This page owns the trigger → evidence → permission → message → response workflow. Use B2B buying signals for definitions/examples, signal detection tools for product selection, and the intent-data quality test for provider measurement. Cadence architecture, personalization technique, channel execution, and outcome metrics remain separate canonicals.
Define the signal-to-outreach operating boundary
Start with one bounded proposition: “When source S reports event E for an eligible account, verify identity and evidence, evaluate permitted action P, let owner O approve message version V, and reconcile response R.” This is narrower and safer than “contact every account showing intent.”
Write owners for source onboarding, identity, CRM authority, privacy/legal review, suppression, claims, message approval, sending, replies, incidents, and deletion. Define eligible accounts/people, excluded populations, channels, entities, jurisdictions, working hours, retention, and rollback. A signal record should never bypass a stronger customer, employee, partner, legal-hold, complaint, opt-out, or do-not-contact state.
Keep this workflow independent of channel tactics. The cold-email sequence guide owns email progression, the LinkedIn outreach guide owns platform execution, and the phone-prospecting guide owns phone execution. Signal evidence may admit a record to a channel-specific review; it does not define that channel's rules.
Write the trigger evidence contract
Every signal type needs a versioned contract before it can create work. Record:
- Event: exact proposition, entity, effective time, observation time, and expiry/review rule.
- Source: URL or record ID, publisher/provider, retrieval method, access time, terms, and permitted use.
- Identity: provider ID, domain, CRM account/contact IDs, parent/subsidiary relation, and confidence basis.
- Evidence state: verified fact, source assertion, model inference, contradiction, or unknown.
- Action boundary: eligible channel, prohibited wording, required approval, and abstention condition.
- Lineage: transformations, enrichment, human corrections, model/rule version, and final disposition.
The W3C's PROV-O Recommendation provides a formal vocabulary for provenance entities, activities, and agents. A sales team need not implement RDF to use the core idea: preserve what the evidence was, how it changed, and who or what changed it.
Do not convert a public announcement into private intent. “Company announced a new office on date X” may be a supported fact. “The VP needs our software now” is a hypothesis. The message may test a relevant problem carefully, but it must not present the hypothesis as known buyer behavior.
Resolve permission before drafting
Permission is evaluated for the actual person, channel, entity, location, data source, purpose, and current suppression state. A public signal does not create consent, erase an objection, or make personal data unrestricted.
The UK ICO's direct-marketing guidance tells organizations to identify whether activity is direct marketing, plan a data-protection basis from the start, collect information fairly, and respect preferences including objections/opt-outs. This is UK guidance, not a universal rule. Qualified owners must map every jurisdiction and subscriber type.
For US commercial email, the FTC's CAN-SPAM guide says the law covers commercial messages including B2B email and addresses accurate headers, non-deceptive subjects, address/opt-out requirements, timely opt-out handling, and responsibility for vendors. Compliance with one regime is not global permission.
| Gate | Evidence | Fail action |
|---|---|---|
| Identity | Person, account, role, channel endpoint, authoritative IDs | Quarantine for review |
| Purpose/source | Approved use, provenance, source terms, collection notice | Do not use |
| Channel/jurisdiction | Applicable policy and legal approval | Block channel |
| Suppression | Current person/domain/account/customer exclusions | Stop across consumers |
| Relevance | Evidence supports a bounded problem hypothesis | Abstain |
Build a claim-safe message packet
The message packet should contain the verified trigger, allowed paraphrase, relevance hypothesis, approved product proof, prohibited inferences, sender/entity, channel requirements, call to action, expiry, and reviewer. The rep should see the source—not merely a score or generated opener.
The FTC's advertising substantiation policy says advertisers need a reasonable basis for express and implied objective claims before dissemination. Apply that control to product claims, performance claims, customer comparisons, and “teams like yours” statements. A trigger source substantiates the trigger only; it does not substantiate your product outcome.
Use a three-column review:
| Message statement | Required support | Example treatment |
|---|---|---|
| Observed trigger | Opened source and exact entity/date | State narrowly; link internally to evidence |
| Problem relevance | Clearly labeled hypothesis | Ask, do not assert hidden need |
| Product capability | Current approved first-party documentation | Use bounded language |
| Performance/customer claim | Claim-matched approved substantiation | Omit if not available |
| Personalization | Permitted, necessary personal information | Avoid sensitive or surveillance-like detail |
Detailed copy technique belongs in cold-email personalization. Here the requirement is simpler: every factual phrase maps to evidence, every inference reads as a hypothesis, and the recipient is never told that hidden intent is known.
Run outreach as a governed state machine
Model explicit states: detected, identity-review, evidence-review, permission-review, eligible, draft, approved, queued, sent, delivered, replied, opted-out, bounced, complained, stale, superseded, suppressed, failed, and closed. Define transitions and one authoritative system for each consequential state.
Signals can change while work is queued. Re-evaluate identity, account ownership, contact employment, customer status, suppression, signal expiry, and approval immediately before send. A stale queue must not win over current CRM or suppression authority. Deduplicate by stable event/account/person/action key so retries do not create multiple messages.
Automation can retrieve and draft, but a model should not invent the event, choose a sensitive inference, override suppression, or silently send when policy requires review. Store model/rule version, input references, output, reviewer, correction, and decision.
Reconcile response and CRM state
A reply changes the workflow. Stop queued automated follow-ups until a human or approved classifier resolves the response. Preserve the original message, reply, thread identity, received time, classification, reviewer, next action, and suppression implications.
Handle positive, negative, referral, correction, not-responsible, out-of-office, unsubscribe, complaint, bounce, and ambiguous responses separately. A contact saying “I left that company” is both a response and an identity correction. A referral requires a fresh permission and identity check for the new person.
CRM writes need append/overwrite authority. The current signal proposition may append as sourced evidence; it should not overwrite buyer-confirmed data, account ownership, opportunity stage, consent, or suppression. Salesforce documents that Opportunity History records selected changes and actors, subject to configuration. History proves a change occurred, not that the value is true.
Reconcile each event: accepted signals = blocked + expired + approved work + unresolved errors. Then reconcile approved work: approved actions = canceled before send + sent once + unresolved send errors. Any unexplained remainder is an operational defect.
Test failures before rollout
Seed a golden test set with common-name companies, subsidiaries, acquisitions, former employees, role changes, customers, open opportunities, opted-out people, suppressed domains, restricted accounts, stale sources, conflicting sources, duplicate events, and sensitive personal facts.
Inject delayed/out-of-order events, webhook replay, timeout before and after acknowledgement, source correction/deletion, CRM merge, owner transfer, expired credentials, deprovisioned rep, permission reduction, suppression outage, generated unsupported claim, hostile source instructions, reply before queued follow-up, and rollback during processing.
Hard gates include zero prohibited sends, zero suppression bypass, zero wrong-person/account sends, no unsupported objective claim, no silent consequential overwrite, one action per deduplication key, visible unresolved errors, and proven pause/rollback. Conversion cannot compensate for a failed safety gate.
Pilot with hard gates and rollback
Run a canary on a small representative set with manual approval and daily reconciliation. Freeze signal contract, sources, eligibility, message version, channels, observation window, and owners. Do not change source, scoring, audience, message, and channel together.
Worked example—not a performance benchmark: 120 signal records enter review. Twenty are duplicates, 15 fail identity/evidence, 10 fail permission/suppression, and five expire, leaving 70 eligible drafts. Reviewers reject eight for unsupported claims and approve 62. Before send, four become stale or newly suppressed; 58 send once. Reconciliation is 120 = 20 + 15 + 10 + 5 + 70, then 70 = 8 + 4 + 58. These counts test workflow accounting, not outreach effectiveness.
Rollback pauses new detections and queued sends, preserves suppression/replies/evidence, disables write paths, revokes unnecessary credentials, reconciles in-flight events, restores prior routing, and monitors delayed callbacks. Delete only test-created disposable work; never delete legitimate opt-outs, complaints, replies, or audit evidence.
Gangly may be evaluated as a first-party signal-to-workflow layer using this protocol, but this article makes no reply, meeting, timing, pipeline, or customer-outcome claim. For outcome measurement, use the multichannel outreach metrics canonical with frozen denominators and attribution.
Signal-based outreach checklist
☐ Define one trigger proposition, source, population, action, and owner
☐ Preserve event/effective/observed times, IDs, source, transforms, and expiry
☐ Separate fact, source assertion, inference, contradiction, and unknown
☐ Resolve channel, jurisdiction, purpose, source terms, and suppression
☐ Map every objective message claim to pre-send substantiation
☐ Recheck identity, ownership, status, permission, and freshness before send
☐ Deduplicate retries and enforce one consequential action authority
☐ Pause on replies; reconcile correction, referral, opt-out, and complaint
☐ Inject stale, duplicate, merge, outage, permission, and hostile-source failures
☐ Canary with human approval, hard gates, accounting equations, and rollback