Here is the gap almost nobody closes.
Your sequence goes out on Tuesday because Tuesday was next in the queue. Meanwhile the company you wrote to changed its pricing three weeks ago. Or posted its first sales hire. Or shipped the integration that makes your client's offer relevant for the first time.
You had no way to know any of that, so you sent the message you would have sent in any other month. The copy was fine. The month was wrong.
That is not a copywriting problem and no amount of rewriting the first line fixes it. It is an information problem, and it stays unfixed because checking is manual. Nobody is opening four hundred pricing pages a week to find the six that moved.
What we do about it
We read the public pages of every company in your lead pool, keep every version, and compare each new read against the last one. When something real changes, you get the change, the page it happened on, and the date.
It runs on separate infrastructure and costs your LinkedIn accounts nothing. No session, no cookie, no action against a daily budget. The two systems share no address and no queue.
Here is exactly how it works, including what we deliberately refuse to do.
As much of the site as the company is worth to you
Depth follows the tier. A company you are actively working gets up to forty pages, weekly. A warm one gets fifteen, monthly. The long cold tail gets five, quarterly, which is what every company used to get.
The order is decided before the budget is. Home, pricing, careers, about, integrations, customers, changelog: that is where a company states what it sells, what it charges, who it is hiring and what it connects to. Whatever budget is left after those goes on the sitemap and the links we find from there.
The budget is a hard cap and not a target. A site with forty thousand URLs in its sitemap gets the same forty pages as a site with nine, because the thing being rationed is the crawl's whole day rather than one company's completeness.
We changed our mind about the team page
An earlier version of this page said we never read team pages, and made a principle of it. We changed that, and the reasoning is worth showing rather than quietly editing out.
A team page is a company publishing who works there, on purpose, on its own site. It is the same fact our LinkedIn employee read already collects. Refusing to look at it protected nobody; it meant paying twice for something a company had gone out of its way to tell us.
What we do with it depends on whether the page gives us a way to identify someone. Where it links to a LinkedIn profile, that person becomes a lead like any other, and their profile goes into the queue to be read properly rather than guessed at from a bio line. Where there is a name and a title and nothing else, it stays a fact about the company, and becomes a person only if something later identifies them.
We do not pick up email addresses published on a team page. A profile link is an identity. An address is a contact detail with its own rules, and we do not collect those in passing.
The signals you actually get
Seven changes become a signal: pricing changed, a new integration, a product launch, new customer logos on the site, hiring in sales, hiring in marketing, and layoffs or a shutdown.
Each one carries its probability and the page it came from, so you can open the page and judge for yourself before you write. A signal is a reason to look, and looking takes eight seconds.
Alongside those we store five standing facts about each company: whether they sell to agencies, whether they have self-serve signup, whether pricing is public at all, roughly what stage the product is at, and who their primary buyer is.
Those facts are the part agency owners tend to care about more, because they are filters. You can build a target list of companies that sell to agencies, have no self-serve signup and are past the landing-page stage. You cannot express that as a LinkedIn search facet at any price.
The judgment is typed, not written
Once we have the change, something has to decide whether it matters.
We do not ask a chatbot to write a paragraph about it. We ask a model that answers in types only: yes or no with a probability, one option from a fixed list, a level on a named scale. It cannot return prose, so it cannot invent a fact and hand it to you as a finding.
A yes only becomes a signal above a stated probability, and that threshold lives in code where you can read it, not in a prompt where you cannot. The arithmetic stays in code too. The model labels and never counts, because a number produced by a model is a number nobody can check.
It cannot touch your accounts
This is the first thing agency owners ask, so here is the mechanism rather than a promise.
The site crawl runs on its own queue, its own lease, its own circuit breaker and its own rate limit. Your LinkedIn work runs on a separate one. A site crawl that goes badly wrong cannot slow, block or burn anything your accounts depend on, because it has no path to them.
It has its own off switch too, independent of everything else, that stops the entire crawl without stopping anything else and without a deploy.
The paced rate is one fetch every 500 milliseconds, about 172,800 a day. A first pass across a 50,000 company pool takes roughly 35 hours. After that most days are quiet, because most company pages do not change on most days.
Where the limits still are
We used to only read companies already in your pool. Now a seeding job also goes looking, walking market slices you name and adding companies nobody in your workspace has touched. A typed judgment then decides what order the crawl works through the queue, and it may only change the order: it can never drop a company or hide one from you.
A site that blocks us stays unread. We honour robots rules and we do not rotate through addresses to get around a refusal. Blocked companies are counted and reported, not retried until they give in.
A signal is a reason to write, not proof of intent. A company that posted a sales job is likelier to care this month than last month. That is all it is. Treat it as a better-than-random opening and your reply rate will survive the difference.
And we will be wrong sometimes. A pricing page that changed because a designer moved a button can read as a pricing change. We tune the thresholds against what actually happened, and we publish the numbers we tune against rather than the ones that flatter us.
Why it is built this way
The expensive way to do this is to ask a large model to read every page and write about it. At pool scale that costs more than the outreach it supports, and it produces confident prose about pages that did not change.
Reading the change instead of the page, and asking for a typed answer instead of an essay, drops the cost of judging one change to a fraction of a cent. That is what makes it affordable to watch every company you might write to, rather than the twenty you remembered to check.
The output is not magic. It is a list of companies where something happened this week, with what happened and where, so you can go read it yourself before you write.