On this page

Reach the buyer while the signal is warm

The outcome: more replies from the same traffic, by contacting the right people well rather than contacting everyone fast.

Who this is for: whoever owns outbound off inbound signal, and anyone who has been sold "instant intent alerts" and is designing a process around them.

Time: an afternoon to design, then it runs itself.

Before you start

  • You need an API key with the copilot scope, and the pixel live.
  • You need somewhere for the list to land — a Slack channel, a CRM task queue, or a person who reads email. The list is worthless if nobody has a job that includes reading it.

Start by correcting the expectation the category sells you

Intent-data vendors advertise real-time alerts, and teams build around the promise: a rep watching a channel, pouncing within minutes.

Signal does not work that way and you should not design as if it does. A visitor becomes a named person on an hourly cycle, not in the same breath.

It is worth being precise about why, because the two halves have different futures:

  • The anonymous identifier is captured in seconds. The pixel resolves a hashed email while the page is still open and posts it immediately.
  • Turning that hash into a person is not instant, and cannot be. It requires matching against a dictionary supplied to us in batches. No configuration changes that — if the hash is not in the dictionary we hold, there is no name to know yet.
  • The last hop — creating the visitor record — runs hourly. That one is a scheduling choice rather than a physical limit, so it could get shorter.

So "hourly" is what to design against today, and one of the three stages is a cadence rather than a constraint. Do not build a process that only works if it becomes seconds.

None of that is as limiting as it sounds, and the reason matters for how you build:

The thing that decays is not minutes. It is days. A B2B buying committee researches over two to six weeks. Somebody reads your pricing page on Tuesday, sends it to a colleague on Thursday, and the two of them sit in a meeting the week after. Arriving four minutes after the page view instead of four hours changes nothing about that. Arriving four days later changes everything, because by then they have talked to two of your competitors.

So the target is not latency. It is same working day, every day, without exception — and that is a process problem, not a speed problem.

Where minutes genuinely matter, and Signal is the wrong tool: someone who has just submitted a form or started a checkout. That person is in-session, and your form handler already knows who they are. Do not route that through an hourly job.

Stage 1 — Decide who is worth a human, before you see any names

Do this first, in the abstract, or you will do it per-name and be generous every time.

{"question": "Which companies visited in the last 7 days, with their intent scores, and how many visitors each?"}

Look at the distribution rather than the top of the list. You are choosing a threshold, and the only wrong answer is one that produces more names per day than your team will actually contact. A list of forty when you can do eight is a list nobody opens by Thursday.

Two filters do most of the work:

  • Intent score, set where a rep would genuinely pick up the phone.
  • More than one visitor from the same company — two people from one domain in a week is a different signal from one person twice. It usually means it has been forwarded, which means it is being discussed.

Write the threshold down. You will want to change it in a month and you will want to know what it was.

Stage 2 — Batch the hour, route once

The hourly cadence is a feature here: it gives you a natural unit of work.

Once an hour, take what arrived, drop anyone already in flight, and route the rest. Once a day is also fine and often better — one list at 9am that a human works through beats twenty-four interruptions that fragment their attention.

What not to build: a channel that pings on every identification. It trains the team to ignore it, and within a fortnight the channel is muted and the project is dead. That failure is about attention, not about tooling, and no amount of better alerting fixes it.

Alert your team when a target account appears covers the mechanics. Set the filter tight enough that an alert is rare enough to matter.

Stage 3 — Read before you write

This is the step that separates a reply from a delete, and it is the step people skip because it does not scale — which is exactly why the list has to be short.

{"question": "What pages has dana@acme.com viewed, in order, and when?"}

The order tells you more than the pages. Pricing then docs is someone building a case internally. Docs then pricing is someone checking whether it can even do the job. A competitor comparison page means you are in a bake-off and the email should acknowledge that rather than pretend to be a cold introduction.

Reference the subject, never the surveillance. "You were looking at how the API handles rate limits" is useful. "You visited /docs/rate-limits at 14:32 for two minutes" will cost you the deal and deserves to.

Stage 4 — Automate the finding, keep the writing human

The division that holds up:

Automate — pulling the list, deduplicating against what is already in flight, enriching, and producing a draft. That is where the hours go, and your own model does all of it well.

Keep human — the send. Every time, at least until you have watched it be right for weeks. A wrong first email to a company evaluating you is not a neutral outcome; it is worse than silence, and you do not get a second first impression.

The drafting happens in your model, not in Signal. Signal answers questions about your data and has no drafting tool — asking it to write copy is refused rather than attempted. That is the right boundary: it keeps the thing that guards your numbers separate from the thing that writes your prose.

So the loop is: Signal supplies the page history, your model writes the email, a human sends it. The LLM tools workflow wires the first two together.

Stage 5 — Measure the process, not the reflex

Response time is the seductive metric and the wrong one. It will improve while nothing else does.

The three that tell you whether this works — and note where each one lives, because two of them are not Signal data and looking for them here will waste an afternoon:

  1. Contacted-within-one-working-day rate — from your CRM or task queue, not from Signal. The process metric. If this is below 80%, nothing downstream is worth reading yet — fix the routing first.
  2. Reply rate on contacted accounts — from your mail platform. The quality metric. If it is poor while #1 is good, your threshold is too loose or the emails are generic.
  3. Returning-customer or new-opportunity count, month over month — this one is a Signal question. The outcome metric, and the only one anyone outside the team cares about.

If you want to know whether this programme caused a change rather than coincided with a good quarter, that is a specific question with exactly one honest answer — see Prove a change actually worked.

What will go wrong

Someone will ask for real-time and be disappointed. Show them the buying cycle argument. If they still want in-session, that is a form handler's job, not this one.

The list will be dominated by personal on a consumer site. Consumer mailboxes roll up under that one sentinel, so filter it out of anything you are treating as a company, or your biggest "account" will be everyone with a Gmail address.

Reps will work the top of the list and ignore the rest. That is fine and expected. It is an argument for a shorter list, not for a nag.

The threshold will drift because nobody owns it. Put a date on it and revisit it monthly with the three metrics above in front of you.

Next

This page is maintained next to the service it describes and rendered here. Read it as markdown if you are pointing an agent at it.