Signal-Based Outbound: How Founders Book Meetings Without Spamming

If you are doing outbound right now, you probably have a list, a sequence and a nagging sense that your messages land in the same pile as everyone else's. Every company gets the same email on the same schedule, whether it just opened the exact role you could help with or has not changed in a year. Sending more does not fix that. Better timing does.

Signal-based outbound means contacting a company because something observable has just changed, such as a new hire, a job post, a funding round or a tool switch, instead of because it appears on a list. The signal gives you a real reason to write today, so you send fewer messages, at better moments, and the reader has a reason to reply.

This guide shows how to run signal based outbound yourself, starting with the tech stack and where the orchestration runs, then which signals to watch, how to verify and score them, the prompts that do the sorting, the message templates, the timing rules, the metrics and a seven-day plan. If you want the wider system around it, start with our guide to AI agents for lead generation, and read what an AI agent is if the term is new.

Start here: the tech stack and where the orchestration runs

Signal-based outbound is a chain of jobs: detect, verify, score, write, send. The thing that runs the chain, hands each result to the next step and stops for your approval is the orchestrator. Choose it first, because it decides where your prompts live, how signals get in and how often the chain runs. There are four sensible choices, and they all use the same prompts and templates later in this guide.

Stack map: pick your orchestrator

Decision rules. If you are unsure, start with path A for the first week; the day-by-day plan at the end works with it. Move to path B or C when a manual step becomes the bottleneck in your KPI table. Many setups mix them: an orchestrator for the thinking steps (verify, score, draft) and a sending platform for delivery. Whatever you pick, a person approves drafts before anything is sent.

Anthropic's guidance on building agents is to use the simplest solution that works and add complexity only when it clearly improves results. That is why path A comes first. (Source: Anthropic, "Building effective agents", accessed 9 November 2026.)

The stack, layer by layer

The descriptions below follow how we describe each tool on our AI Stack page. Check each vendor's own documentation for current features, limits and pricing before you buy. You can do every step with the simplest option in the third column.

Stack map: tools by layer

A concrete setup with Claude Code

Here is the shape of path B. We have not run your accounts, so treat this as a template to adapt.

1. Create a project folder with icp.md (your ideal customer and exclusions), signals.md (your three signals, freshness windows and hypothesis sentences), signal_log.csv, a templates folder (one message template per signal) and suppression.csv.
2. Add a rules file named CLAUDE.md in the project root. Anthropic's docs say Claude Code reads it at the start of every session, so your rules apply every time. Use the starter below.
3. Package the weekly chain as a skill. Per the docs, skills package repeatable workflows. Yours is: verify new rows, score them, draft messages for the "send now" rows.
4. Connect tools through MCP where a connector exists (for example a CRM or your document store), and use CSV files in and out where one does not. Check each vendor's documentation for connector support.
5. Schedule the weekly pass. The docs describe cloud scheduled tasks that keep running when your computer is off. Start by running it by hand until you trust the output.
6. Keep sending separate. The agent writes drafts to a file with the status "needs approval". A person approves, and your sending platform delivers.

Stack map: CLAUDE.md starter

# Signal-based outbound project rules

## Goal
Find companies that match our ideal customer and have a fresh, verified buying signal. Draft one short message per company for human approval. Never send anything.

## Files
- icp.md: ideal customer and exclusion rules
- signals.md: the three signals, freshness windows, hypothesis sentences, send-queue-drop rubric
- signal_log.csv: one row per signal (company, signal_type, summary, date, source_url, verified, decision)
- templates/: one message template per signal type
- suppression.csv: never contact these addresses or domains
- drafts.csv: output, status "needs approval"

## Rules
1. Use only facts found in the source text. If a fact is missing, write "unknown". Never guess dates.
2. Drop any signal older than its freshness window.
3. Score fit first, then signal, using the rubric in signals.md.
4. Check suppression.csv and the exclusions in icp.md before drafting.
5. Drafts: 90 words maximum, one verified fact, the inference phrased as a question, one ask, an opt-out line.
6. No private information. No claims about results or other customers.
7. Write drafts to drafts.csv with status "needs approval". Do not send.

## When I say "run the weekly pass"
1. Read signal_log.csv rows where verified is empty.
2. Verify each against its source text and write the result back.
3. Score the verified rows and set the decision.
4. For "send now" rows, draft with the matching template and write to drafts.csv.
5. Print a summary: counts per decision, rows dropped and why, and the 5 drafts I should read first.

A concrete setup with Make or n8n

Path C follows the same chain as a flow. Build one flow per signal type, or one flow that routes by signal type.

1. Trigger: a new row in the signal log, or a daily schedule.
2. Fetch: get the source page text. Check the site's terms first.
3. AI step: run the verification prompt (Asset 3) and ask for JSON back.
4. Filter: continue only when supported is "yes" and still_current is true. Send everything else to a "dropped" tab with the reason.
5. Score: a second AI step with the rubric (Asset 4), or a formula in the sheet.
6. Route and draft: choose the template for the signal type, then run the message prompt (Asset 5).
7. Approval: write drafts to a "needs approval" sheet. A person marks rows approved.
8. Send: add approved rows to a campaign in your sending tool and set it to stop on reply or unsubscribe (Asset 7).

Signal-based outbound versus list-based outbound

List-based outbound starts with who: you buy or build a list of companies that match a profile and message all of them on a schedule. Signal-based outbound starts with when: you wait for evidence that a company has a reason to care now, then message only those companies. The profile (your ideal customer) still matters, because a signal never rescues a bad fit. The signal decides the timing and the first sentence.

The signal menu: what to watch and what each one means

A signal is only useful if you can say what it implies about the buyer's situation. Use this table to choose three signals to start with. Do not try to track all of them. Pick the ones that map most directly to the problem you solve.

Asset 1: Signal menu

Two rules from our own setup. First, we write each signal as its own mini playbook with four parts: how it is detected, subject line options, an email body and a shorter LinkedIn version of the same message. One signal, one angle, one message. Second, we split time-based signals into windows (for example days 0 to 30 versus 30 to 90 for a new hire), because what a person needs in week two differs from what they need in month three.

How the workflow fits together

You do not need a free-roaming agent for this. Anthropic's engineering team separates workflows, where models and tools follow predefined code paths, from agents that decide their own steps, and recommends using the simplest solution that works. They also describe routing, where an input is classified and sent to a specialised follow-up task. Signal-based outbound is a clean fit for a routed workflow that your orchestrator (chosen above) runs: each raw signal is classified once, then sent down the path written for that signal type. (Source: Anthropic, "Building effective agents", accessed 9 November 2026.)

Step 1: Choose three signals and write the hypothesis

Input: your offer and your best three past customers. Action: for each signal in Asset 1, write one sentence that links it to your offer. If you cannot complete the sentence, drop the signal.

The sentence format is: "When a company signal, it probably has problem, which my offer solves by outcome." Example: "When a company posts a job for an operations coordinator, it probably has a manual process that slows delivery, which we solve by automating that process, so the hire is not the only option."

Use this prompt to pressure-test your choices.

Asset 2: Signal hypothesis prompt

You are a B2B go-to-market analyst. Be sceptical. Do not flatter the idea.

My offer: <ONE_PARAGRAPH_OFFER>
My ideal customer: <ICP_ONE_PARAGRAPH>
Typical deal value: <DEAL_VALUE_RANGE>
Candidate signals: <PASTE_3_TO_5_SIGNALS_FROM_THE_MENU>

For each candidate signal:
1. Complete this sentence: "When a company [signal], it probably has [problem], which my offer solves by [outcome]."
2. Name one alternative explanation for the signal that would make it a FALSE positive for my offer.
3. Say how a person could verify the signal in under two minutes using public information only.
4. Rate the link between signal and my offer as strong, medium or weak, with a one-line reason.

Finish by recommending the three strongest signals to start with and the one I should NOT track yet, with reasons.

How to check it worked: every signal you keep has a verification method that takes under two minutes and a false-positive explanation you can screen for. If a signal is "weak", drop it for now.

Step 2: Build the watch list and the signal log

Input: 50 to 100 companies that already fit your ideal customer profile. Action: put them in a table and add the columns below. Output: a log that records each signal with proof.

1. Company, website, contact name, job title, profile link
2. Fit score (from your ideal customer rubric, see the lead generation guide)
3. Signal type (from your three)
4. Signal summary (one sentence, plain facts)
5. Signal date
6. Source link
7. Verified (yes, no), Verified by (person or model)
8. Decision (send now, queue, drop), Next touch date, Status

Source the signals from places you are allowed to use: the company's own site and press page, public job posts, news coverage, and your own CRM. Check the terms of any platform or data tool before you automate collection from it. Many platforms restrict scraping and automated activity in their terms, and breaking them can cost you the account.

In our setup we do not scale anything before a pilot. Run the whole table on 10 to 20 companies first, read every row, and estimate the cost of running the next 100 before you do. Re-run only the rows that failed, never the whole table.

Step 3: Verify the signal before you use it

The most expensive error in signal-based outbound is writing "congrats on the new role" to someone who changed jobs a year ago, or referencing a job post that was filled last month. Verification is a separate step with its own prompt.

Asset 3: Signal verification prompt

You verify buying signals. Use ONLY the source text below. If the text does not support a claim, answer "unsupported". Never guess dates.

Today's date: <TODAY>
Company: <COMPANY>
Claimed signal type: <SIGNAL_TYPE>
Claimed signal: <ONE_SENTENCE_CLAIM>
Source text: <PASTE_SOURCE_TEXT>

Return JSON only:
{
  "supported": "yes" | "no" | "unsupported",
  "about_this_company": true or false,
  "event_date": "YYYY-MM-DD or unknown",
  "days_old": number or null,
  "still_current": true or false,
  "evidence_quote": "short exact quote from the source text",
  "risk_of_false_positive": "one sentence"
}

Decision rules: if supported is not "yes", drop the row. If days_old is outside the freshness window for that signal (Asset 1), set the decision to "drop". If about_this_company is false (a similarly named company, a subsidiary, a parent), drop it.

Step 4: Score fit and signal, then decide send, queue or drop

Fit comes first. Signal strength second. A strong signal at a poor-fit company is a drop, not a send.

Asset 4: Send-queue-drop rubric

• 8 to 10 points: send now.
• 5 to 7 points: queue. Re-check in a week. Either a second signal arrives or the first one expires.
• 0 to 4 points, or any exclusion hit: drop. Exclusions are existing clients, competitors, partners and anyone who has asked not to be contacted.

Two signals at one company are worth more than one strong signal alone, but only count a second signal if it is independent (a job post and a funding round, not two job posts for the same team).

Step 5: Write the message, one signal and one ask

Rules that keep a signal message from sounding like surveillance:

• Reference public, professional information only, and only the one fact that matters.
• State the fact plainly, then the inference as a question, not a certainty ("often means... is that the case for you?").
• Give a reason you are relevant in one sentence. No company history.
• One ask, low effort: a short call, or permission to send a two-line idea.
• Stay under about 90 words for the first email.

Asset 5: Signal-to-message prompt

You write first-touch B2B outreach. Use ONLY the facts supplied. Do not invent anything about the company or the person.

Sender: <SENDER_NAME>, <SENDER_COMPANY>
Offer in one sentence: <OFFER>
Signal type: <SIGNAL_TYPE>
Verified signal fact: <FACT>  (date: <DATE>)
Recipient: <FIRST_NAME>, <TITLE> at <COMPANY>
Template to follow: <PASTE_TEMPLATE_FOR_THIS_SIGNAL>

Rules:
- Maximum 90 words.
- Mention the fact once, in plain words, without flattery.
- Phrase the inference as a question.
- One ask only.
- No claims about results or other customers.
- No phrases such as "I hope this finds you well", "just following up", "game-changing".

Return: 3 subject lines (under 6 words each, lowercase), the email body, and a LinkedIn note of 40 words or fewer with the same idea.

Now the templates. Edit the wording until it sounds like you. These are fictional and use placeholders.

Asset 6: Three signal templates

TEMPLATE A: Hiring signal
Subject: <ROLE> role at <COMPANY>

<FIRST_NAME>,

Saw <COMPANY> is hiring a <ROLE>. Teams hiring for that role are often trying to fix <PROBLEM>, and a hire takes a while to pay off.

We help with <PROBLEM> by <ONE_LINE_METHOD>, either instead of the hire or until the person starts.

Is <PROBLEM> the reason for the role? Happy to share how we would approach it in 15 minutes.

<SENDER_NAME>
If this is not relevant, tell me and I will not follow up.

TEMPLATE B: New leader (days 0 to 30)
Subject: first weeks as <TITLE>

<FIRST_NAME>,

Noticed you joined <COMPANY> as <TITLE> recently. New leaders in that seat often inherit <COMMON_INHERITED_PROBLEM>.

We help with that by <ONE_LINE_METHOD>. No pitch deck, just a short outline of what we would look at first.

Want me to send the outline?

<SENDER_NAME>
If this is not relevant, tell me and I will not follow up.

TEMPLATE C: Funding or expansion
Subject: after the <EVENT>

<FIRST_NAME>,

Congratulations on <EVENT_IN_PLAIN_WORDS>. Growth like that usually puts pressure on <AREA>.

We help companies at that stage with <ONE_LINE_METHOD>. Is <AREA> on your list for the next quarter?

<SENDER_NAME>
If this is not relevant, tell me and I will not follow up.

Step 6: Set the timing and the stop rules

Signals decay. Send quickly, keep the cadence short and stop early.

Asset 7: Touch plan

If a second, independent signal appears after the sequence ends, you have a new reason to write. Start a fresh, shorter sequence that mentions only the new fact. Do not restart the old one.

Step 7: Handle replies and keep a suppression list

Every reply is classified and routed by a person within a working day. A model can draft the classification, but a human owns anything labelled interested or unsure.

Asset 8: Reply classification prompt

Classify this reply to a cold outreach message. Return JSON only:
{"label": "interested" | "not_now" | "not_relevant" | "wrong_person" | "unsubscribe" | "out_of_office" | "unsure",
 "confidence": "high" | "medium" | "low",
 "suggested_action": "one sentence",
 "forward_to": "name or role mentioned, if any"}

Rules: any request to stop, remove or not contact is "unsubscribe" regardless of tone. If unclear, use "unsure".

Reply: <PASTE_REPLY>

Unsubscribe and "not relevant" go straight to the suppression list that every campaign checks before drafting anything. "Not now" gets a re-check date. "Wrong person" gets one polite reply asking who owns it, and the row is closed whatever the answer.

A worked example (illustrative)

This is a fictional example with invented names, shown to make the flow concrete. No real company or result is described.

Setup. Priya runs Northwind Analytics, a small consultancy that builds automated reporting for logistics firms. Her offer: "We replace manual weekly performance reports with automated dashboards in six weeks." Her ideal customer: logistics companies with 50 to 300 staff in the Gulf. Her three chosen signals: a job post for a reporting or data analyst, a new Head of Operations, a new depot or route announcement.

Step 1 output (hypothesis). "When a logistics company posts a job for a reporting analyst, it probably spends analyst hours building reports by hand, which we solve by automating the weekly reports, so the hire can do analysis instead." The model flags a false positive: the role may be a pure backfill. Priya adds a screen: the job description must mention reporting, spreadsheets or dashboards.

Step 2 output (log row). Company: Harbourline Freight (fictional). Signal type: reporting analyst job post. Source: careers page link. Signal date: 2026-11-03. Decision: pending.

Step 3 output (verification). Today is 2026-11-09. The model returns: supported yes, about this company true, event date 2026-11-03, days old 6, still current true, evidence quote "build and maintain weekly operations performance reports in spreadsheets". Risk of false positive: the post could be a replacement hire.

Step 4 output (score). Fit 3 (logistics, 120 staff, in region), owner of problem 2 (Head of Operations is the contact), signal 3 (verified, six days old), signal-to-offer link 2 (strong). Total 10, so: send now.

Step 5 output (draft, from Template A).

Subject: reporting analyst role at Harbourline

Karim,

Saw Harbourline is hiring a reporting analyst. Teams hiring for that role are often trying to fix weekly reports that eat analyst time, and a hire takes a while to pay off.

We help by automating those weekly reports, either instead of the hire or until the person starts.

Is the reporting load the reason for the role? Happy to share how we would approach it in 15 minutes.

Priya
If this is not relevant, tell me and I will not follow up.

Notice what is missing: no flattery, no "I came across your company", no statistic and no claim of past results. It names one fact, asks one question and makes it easy to say no.

Step 6 and 7 output. Touch 1 goes on 9 November. The reply, if any, is classified and routed to Priya. If the job post disappears before touch 2, touch 2 is cancelled because the signal is no longer current. That is the point of the freshness check.

Not spamming: the rules we hold ourselves to

• One verified reason per message. If you cannot state the reason in one sentence, do not send.
• Three touches maximum per signal, then stop.
• Cap daily volume well below what your tool allows, and grow it slowly.
• Honour opt-outs immediately and permanently across every campaign.
• No private information. Use only professional, public facts. If a fact would feel invasive if the reader saw how you found it, leave it out.

On email deliverability, Google's sender guidelines require all senders to meet the sender guidelines when emailing personal Gmail accounts, and set stricter requirements for bulk senders (those sending close to 5,000 or more messages a day to personal Gmail accounts): authenticated domains with SPF, DKIM and DMARC, spam rates kept below 0.30 percent in Postmaster Tools (with a recommendation to stay below 0.10 percent), and one-click unsubscribe for marketing messages. A signal-based programme sends far below that volume, but the principles are the right ones: authenticate your domain, keep complaints low and make opting out easy. (Sources: Google, "Email sender guidelines" and the sender guidelines FAQ, accessed 9 November 2026.)

Laws on cold email and outreach differ by country, and by whether the recipient is a person or a company. This is not legal advice. Check the rules for every market you contact, and ask a qualified adviser if you are unsure.

Decision rules and common mistakes

Decision rule summary: if the signal is older than its window, drop it. If fit is low, drop it. If fit is high but the signal is weak, queue it. If two independent signals appear, move it to the front. If the reader replies "not relevant", suppress and close.

What to measure and how to read it

We deliberately give no target numbers here, because benchmarks vary widely by market, deal size and list quality. Set your own baseline in the first two weeks and compare each change against it.

Asset 9: KPI table

Pre-launch QA checklist

• I wrote a hypothesis sentence for each of my three signals and each has a two-minute verification method.
• Every row in the pilot has a source link, a date and a verified flag.
• I opened at least 10 source links by hand and they matched the log.
• The freshness window is enforced and a stale test row was dropped correctly.
• The rubric ranks a strong-signal poor-fit company as "drop".
• I read 10 drafts aloud and none mention private or non-professional information.
• No draft contains a statistic, a result or a customer claim I cannot prove.
• Sending domain is authenticated and is not my main domain; every email has an opt-out line.
• The suppression list is connected to every campaign.
• A named person owns replies, with a response-time target.
• The cost of the next batch is estimated from the pilot.

Your first week, day by day

1. Day 1: Write your offer and ideal customer paragraphs. Run Asset 2 and choose three signals.
2. Day 2: Build the watch list of 50 companies and the signal log columns. Collect signals for 20 of them.
3. Day 3: Run Asset 3 on all 20. Open 10 source links by hand. Fix the prompt where it disagreed with you.
4. Day 4: Score with Asset 4. Pick the "send now" rows. Generate drafts with Asset 5 and edit them by hand.
5. Day 5: Authenticate the sending domain, connect the suppression list and send touch 1 to 10 to 20 approved rows.
6. Day 6: Set up Asset 8 for replies. Write your handover rule and the response-time target.
7. Day 7: Fill in the KPI table. Decide which signal to keep, rewrite or drop, and size next week's batch from the cost you saw.

Frequently asked questions

Sources and further reading

• Anthropic, "Building effective agents" (workflows versus agents, routing, starting with the simplest solution). Accessed 9 November 2026.
• Anthropic, "Claude Code overview" (surfaces, MCP, CLAUDE.md, skills and scheduled tasks). Accessed 9 November 2026.
• Google, "Email sender guidelines" (authentication, spam rate and one-click unsubscribe for bulk senders). Accessed 9 November 2026.
• Google, "Email sender guidelines FAQ" (definition of a bulk sender; all senders should follow the guidelines). Accessed 9 November 2026.
• SFC AI Stack page (tool descriptions; some links are referral links).
• SFC internal prompt library, enrichment SOP and signal playbook structure (methods adapted and anonymised).

What to do next

Do Day 1 today: pick your three signals and write the hypothesis sentences. If you would rather have the system built and running in your own accounts, we build AI outbound agents that watch signals, verify them, score fit and draft outreach for your approval, and you can book a short call to talk through your pipeline. When replies start arriving, our guide to the AI appointment setter covers turning them into booked calls.