signal-triggered-outbound

Signal-Triggered Outbound

Overview

This skill turns repeat ScraperCity pulls and free outside feeds into a queue of accounts with a dated reason to reach out this week. Each signal has a detection rule (what changed between two pulls or feeds), a date anchor, a half-life after which its score halves, a maximum age after which it is dropped, a touch window, a score, and a play: who gets it, the touch plan, and a first email that names the event in the first line.

The mistakes it prevents: calling a list "intent" when it is a static filter, emailing about a "new" listing that opened a year ago, attributing funding rounds or job posts to a tool that does not show them, opening with "congrats on the raise" instead of what the money is for, re-paying for the same records every week, and letting a hot signal sit in a spreadsheet until it is stale.

Signals S1 to S13 come from ScraperCity tools. S14 to S28 start outside ScraperCity: website visits (RB2B, Vector, Warmly), job changes and new leaders (also found by re-pulling the Lead Database), funding (Crunchbase, Form D on EDGAR), job posts (Greenhouse, Lever and Ashby public job boards), earnings and filings (EDGAR), competitor and account launches (page monitors, press feeds), events (exhibitor and speaker lists), social engagement (Octolens, F5Bot), third-party category intent (G2 Buyer Intent) and webinar or content engagement (the user's own webinar and marketing tools). Negative signals (layoffs, a hiring freeze, a competitor just signed) lower a score and pause the account. All of them score on the same formula and carry other source: <feed> unless a Lead Database re-pull found them. ScraperCity then finds and validates the buyer at each account, and for a competitor change pulls the competitor's install base with Tech Stack Search.

When to Use

• "Find businesses that just opened", "alert me to new dentists in Phoenix every week".
• "Who just installed Klaviyo", "stores that started using Recharge", "sites that dropped HubSpot".
• "Which restaurants' ratings dropped", "contractors whose reviews stalled".
• "Businesses for sale in my area", "new pre-foreclosures in Tampa every Monday".
• "Set up a daily feed of new leads", "only give me records I don't already have".
• "Make our outbound trigger-based", "why-now lists", "signal scoring", "stack signals".
• "Reach companies that just raised", "Form D alerts", "companies hiring SDRs", "new VP Sales outreach".
• "A champion changed jobs", "our main contact left a customer".
• "Use their 10-K or earnings call in outreach", "competitor raised prices, who uses them", "they just launched a product".
• "Conference prospecting", "follow up after the trade show", "RB2B visitor follow-up", "social listening for buying signals".
• "Use our G2 intent data", "follow up with webinar attendees", "who downloaded the guide".

Use something else for nearby jobs:

Prerequisites

1. ICP: category or platform, geography, size band.
2. Which events plausibly create a buying window for this offer (step 1).
3. Where snapshots live: a folder of CSVs, SQLite, Postgres, Google Sheets or Airtable.
4. Scheduler: cron on a server, n8n, Zapier, or a person running the pull every Monday.
5. Destination: sequencer (Instantly, Smartlead, Lemlist, EmailBison, ManyReach), CRM (HubSpot, Pipedrive, GoHighLevel), or a dialer.
6. ScraperCity plan. Growth ($149/mo) for the Local Business Database, Lead Database and Ecommerce Database; any plan for the scrapers.
7. Outside tools the user already pays for (visitor ID, G2, webinar platform, Crunchbase). Where none is named, the program picks one per feed and prices it from the vendor's page, for example RB2B: Free with 150 monthly resolutions, Starter $79 a month with 300, Pro from $149 (pricing page, checked 2026-10-13).
8. Owner roles for the build, tier A and tier B work; the Launch Plan dates start from today.

Authoritative Foundations

Workflow

1. Pick signals that create a buying window for this offer

When the user asks for "anything else that works", include every signal family above that fits the offer and the tools the user has or can buy, priced; list the rest in one "Not used" line with a reason each. Do not defer a fitting family to "next quarter" without a reason the user would accept.

Full detection rules, false positives, touch windows, angles and negative signals: references/signal-catalog.md. Who to contact, touch plans and a full first email per outside signal: references/signal-plays.md.

2. Define each signal precisely

For each signal write: tool or feed and parameters, the diff key (domain, phone, place, listing URL, property address, accession number, posting id), the change that counts (appeared, disappeared, field crossed a threshold), the date anchor, the half-life, the max age, the touch window and the angle.

The date anchor is the date your pull first saw the change unless the source row carries its own date. A weekly pull dates every event to within 7 days; say "in the last week", never "yesterday".

3. Take a baseline, then pull on a schedule

The first pull is a baseline and produces no signals. Every later pull is diffed against the stored snapshot. Default cadence:

The cadence sets the age resolution of every signal, so pick it per signal against its cost.

4. Score, tier and route

Run the exclusion check first: competitors, vendors, partners, agencies, customers, open deals and do-not-contact domains get tier X and no score (references/scoring-and-freshness.md section 5a). Then score.

Score = fit + signal strength decayed by age + reachability, minus negative points, out of 100. Signal strength = base points x 0.5^(age in days / half-life); each further live signal adds a bonus. A negative signal (catalog section "Negative signals") subtracts its points and pauses the account for the days the program sets; at least one negative row goes in every Scoring Model. No published study gives weights, base points, half-lives or tier cut-offs for these signals, so the program sets each one, writes them in its Scoring Model and Signal Catalog, and re-fits them from its own meeting rate by age bucket. Formula, decay lookup and a worked example: references/scoring-and-freshness.md.

Webhook signals (S14 visits, S19 social) can be worked in minutes; weekly pulls cannot. No benchmark exists for minutes-to-touch, so log it and compare buckets.

Routing settings every program writes down: an owner per tier, what the workflow does when the owner misses the SLA (reassign, or move to the next day's batch), and who gets each signal. An identified visitor below the buyer (a rep, SDR or coordinator) is routed to the buyer at that domain with the fit-based email, which does not mention the visit; a second visitor from an account already in sequence adds to the score and goes to the second thread.

5. Enrich only what you will contact

Enrich after scoring, so money goes to tier A and B. Order: Lead Database by companyDomain (included on Growth), then scrape_website_finder for a named role, find_emails for a known name, validate_emails on everything, find_mobiles for tier A calls.

6. Write the angle into the first line

Name the event and its date range in plain words, connect it to the offer, ask one question (Berman: a dated reason in the first line, connected to the offer). For funding, open with what the money is for. For filings, quote management's phrase with its section. Angles per signal are in references/signal-catalog.md; full first emails in references/signal-plays.md. State the number you saw and ask about it; never claim a cause the data does not show.

Copy rules for every first email:

• Write it as a sequencer template: the event fact is a merge field ({{open_sales_roles}}, {{round}}, {{start_month}}), and a "Fields:" line under the email names each field's source column and one example value.
• A claim about the prospect's world ("managers hear one or two calls a month", "teams usually...") is either asked as a question or comes from the sender's own data in a field. Never state it as fact.
• Product capabilities restate what the user said about the product. Any other capability, and every proof result, goes in one "Claims to confirm" line for the user to sign off; proof results are a {{proof_result}} field from the user's results sheet.
• Events: shows such as NAMM bar non-exhibitors from soliciting exhibitors on the floor, and booth staff are working their own prospects. Pre-event emails go to the sales leader not on booth duty and ask for a meeting in the week after the show; a booth visit is an optional drop-by.

7. Suppress and cool down

One account gets one signal-triggered sequence per 90 days, whatever new signals fire; Instantly (March 2026) advises pausing two to three months before re-engaging a contact. Signals on customers, open opportunities and opted-out contacts are logged and not contacted. Stop the sequence on any reply, and remove anyone who asks the same day, across every tool.

8. Measure per signal

Track reply, positive reply and meeting rate by signal type and by age bucket. Once a signal reaches the contact count the program sets, retire it if it does not beat your static-list baseline from the same ICP and weeks; shorten a half-life when old signals convert at the static rate. Without a static baseline yet, compare with Hunter's 3% average reply rate for sales outreach sequences (2025 data) and Instantly's 3.43% across all sequences (2026).

ScraperCity Implementation

Three things about repeat pulls that change cost:

1. Re-fetching a Local Business Database or Lead Database record the account already owns is free, so a weekly re-pull of the same segment costs nothing on Growth. The database's refresh schedule is not published: re-pull a sample of known records on a later cycle and count changed reviews_count values before relying on it for review movement. If none changed, measure reviews with scrape_maps or scrape_yelp.
2. Store Leads, Maps, Yelp, BizBuySell, Distress List and Zillow Agents bill per row on every pull, including rows you saw last week. Keep those pulls narrow.
3. excludeDelivered=true returns records new to your account, which says nothing about when the business opened. Pair it with maxReviews to approximate new businesses; never call a record "just opened" from that flag alone.

MCP calls (these ids, parameters and file names stay in the agent's calls; the deliverable describes each pull in plain words):

{"tool": "query_local_business_database",
 "keyword": ["med spa"], "location": ["Scottsdale AZ", "Phoenix AZ", "Tempe AZ"],
 "maxReviews": 5, "hasPhone": true, "excludeDelivered": true, "limit": 100, "page": 1}

{"tool": "scrape_builtwith", "technology": "Klaviyo", "fileName": "techstack-klaviyo-20261019"}

Cron with the CLI and REST, n8n workflows, webhook handling and a stdlib diff script: references/repeat-pull-recipes.md. The CLI db-local and db-leads commands print only the first three rows, so scheduled database pulls use REST (GET /api/v1/database/local-businesses) and scrapers use the CLI or REST start, poll, download.

Worked cost estimate (4-week cycle, Shopify retention agency)

Over $5: run check_wallet, show this table, wait for a yes. Test the universe with totalLeads: 100 ($0.39) first and confirm the visits filter behaves as expected. Rounding: per-line costs are rounded to the cent; the unrounded total is $63.821.

Output Format

One Markdown signal program from templates/output-template.md, answer first. A title, then one paragraph: offer, ICP, buyer, the stack with one named tool per outside feed, and a single line saying which numbers are the program's starting settings and that no pulls have run (said once, nowhere else). Then these sections in order:

1. Signal Catalog: one row per signal with source, detection rule, date anchor, half-life, max age, base points and touch window; one "Not used" line with a reason per signal family left out.
2. Scoring Model: fit, strength, reachability, at least one "Negative:" row with minus points and a pause in days, the tier cut-offs, and one example line of arithmetic for one account.
3. Exclusions: class, match rule, list source (competitors, vendors, partners, agencies, customers and open opportunities, do not contact).
4. Routing and SLAs: owner, SLA and missed-SLA action per tier; first contact and second thread per signal; the visitor-below-the-buyer rule when S14 is tracked; the cadence and cool-down in one line.
5. First Emails: one "Claims to confirm" line, then per signal an "Angle:" line, a template (subject plus a body of 90 words or fewer, first sentence 30 words or fewer, the event fact as a merge field) and a "Fields:" line with each field's source column and an example value.
6. Pulls and Cost: each pull described in plain words (for example "Lead Database: VP and C-level sales contacts at watched domains"), its frequency, cost per run and cost per 4 weeks, outside tools at their checked price or "your plan", and a total row.
7. Launch Plan: dated weeks starting from today, each with a step and an owner role: tool sign-up, baseline pulls, first cycle, first review.

• Each fact appears once. The catalog is the only signal list and the emails carry their own angle lines, so leave out summary tables, angle tables, queues of invented accounts and score-check arithmetic. A Signal Queue goes in only when real pulls were run or the user supplied accounts.
• The reader gets plain words only: no tool ids, parameter names, JSON or code blocks, file names, repo paths or skill names. Another skill is named only in a closing handoff line.
• Fit the request: a user who asks for one play (funding, hiring, events) gets that signal and its stack partners only.

Quality Check

python3 scripts/check-output.py signal-program.md enforces:

• All seven sections present, no [fill] left, no Program Summary, Message Angles or other repeating section, no 10-word sentence stated twice, "assumed" and "illustrative" at most twice each.
• No tool ids, backticked parameters, code blocks, repo paths or skill names; no legal content.
• Every catalog signal names a ScraperCity product or is labeled other source; funding, hiring, filing, launch, event, visit, intent, webinar and social signals carry the label; a job change or new leader row carries it or the Lead Database.
• Every catalog signal has a touch window with a number and a unit, a numeric half-life and a max age at least as long.
• The Scoring Model states the A and B cut-offs and at least one negative row with minus points and a pause in days.
• Exclusions cover competitors, vendors, partners and agencies, each with a match rule.
• Routing states the missed-SLA action, and routes a visitor below the buyer when S14 is tracked.
• Every catalog signal has a first email with an Angle line, a subject, a 15 to 90 word body, a first sentence of 30 words or fewer, an event merge field, a Fields line covering every field, no generalization stated as fact ("usually", "typically", "most teams") and no booth meeting ask; the section has a Claims to confirm line.
• Every pull has a frequency and a dollar cost, with a total row; the Launch Plan has at least three dated rows with owners.
• A Signal Queue, when present, has ISO dates, ages within max age, scores from 0 to 100 and tiers that match the cut-offs.

Also check by reading: the baseline pull produced no signals; each angle names an event the data shows; funding emails name what the money is for; filing emails quote the filing with its section.

Common Pitfalls

Execution Artifacts

Related Skills

• cold-email-strategy and cold-email-copywriting build the signal-specific campaigns.
• cold-calling and multi-channel-outreach work tier A accounts.
• ecommerce-by-techstack and local-business-list build the universes that signals are diffed against.
• decision-maker-finder finds the person at each scored account.
• scrapercity-integrations, scrapercity-cli and scrapercity-api cover scheduling and automation detail.
• scrapercity-real-estate-data covers distress and owner data.
• outbound-unit-economics compares cost per meeting of signal programs with static lists.