Your product knows which accounts are worth a call. Now your CRM does too.

It listens to your PostHog events and applies your rules: when enough different people at one company start using the product, or when somebody keeps failing onboarding, it opens a follow-up with the actual events attached and creates one task on the right company in your CRM. No model decides who gets chased. The rules are arithmetic over events your product really sent, so the same activity always produces the same answer, and every follow-up shows you exactly which people did what.

What it does

Take every event PostHog sends, keyed so a redelivery is not a second row.
Count the different people at each company inside your window.
Open one follow-up, with the events attached, and create one CRM task.

What you get

A follow-up when enough people at one company start using the product.
A help follow-up when somebody keeps failing onboarding, cleared when they finish.
One CRM task per company per reason, with the event rows in the body.

What it needs

The PostHog property that says which company an event belongs to
The events that mean somebody is really using the product
Your onboarding failed and completed events

The moment an event arrives, and on the hour to notice what has gone quiet.

You set the rules and approve every task. Every follow-up shows the events behind it.

Who runs it

One agent, and it is deliberately not the one deciding who to chase.

Tally: Connects PostHog, matches your product accounts to CRM companies, and writes the tasks the app composed. It proposes every match for you to confirm, because a confident wrong match writes a task onto somebody else's account.
The rules, not a model: Which companies get a follow-up is arithmetic over events your product really sent. Three people is three people. Ask why a company was flagged and the answer is a list of events with names and timestamps, not a judgement nobody can re-run.
You approve: Nothing reaches your CRM until somebody says so. Turn that off once you trust it, per your own scope, and turn it back on the first time it surprises you.

What stays yours

Your rules, in your words: Three different people in seven days, or two failed onboarding attempts. Change either number, or the events they read, and every follow-up is re-decided the moment you save.
Your events: It reads the events you already send. Name the property that carries your company id and the events that mean real use, and it works with the data you have rather than asking for new instrumentation.
Your CRM: HubSpot, Attio, Close, Pipedrive, or your own through an MCP server. Connect nothing and it still works: follow-ups open and wait for you to say which company each one is.

Questions

Do I need to build a data pipeline?: No. You add an HTTP Webhook destination in PostHog pointing at the app, sign it with a secret, and give that secret to your agent. There is nothing to host and nothing to schedule.
Will it spam my CRM?: It creates at most one task per company per reason, for the life of the installation. A rule fires continuously; the task is created once. And nothing is created at all until you approve it, unless you turn that off yourself.
What happens if a company stops using the product?: A follow-up nobody has acted on clears itself when the activity behind it falls out of your window. Somebody who finishes onboarding takes their own help follow-up off the board. You do not tidy up after it.
What if a CRM write fails halfway?: It stops. If it cannot tell whether the task was created, it parks the follow-up and asks you to look, because a duplicate task on a customer record is worse than a late one. Nothing retries a write it could not confirm.
Can it tell my test workspace from a real customer?: Only because you tell it. No follow-up opens for a company until somebody has reviewed it and said it is worth chasing, so your own staging account never produces a task by accident.
Does a model decide who gets contacted?: No. The rules are arithmetic over stored events, so the same activity always produces the same answer. Your agent does two things, and neither is choosing: it matches an account id to a CRM company, and it writes the task the app composed.

Your product already knows which accounts are worth a call.

This is the shortest path from the events you already send to a task on the right company, with the reason attached and a person in the loop.

Browse all Bolter blueprints