SaaS and product teams
Your product knows things no marketing tool can observe.
Who finished onboarding and who stalled at step three. Who invited a colleague. Who hit the limit twice this week. Who has not opened the thing in a fortnight. Every one of those is a better trigger than anything derived from an e-mail open, and all of them are two lines of code away from being one.
Events are the whole integration.
POST /v1/events with your own token: a name you chose, a contact, a payload, an idempotency key. That is the entire connection. There is no SDK to keep current, no mapping screen, and no vocabulary of ours you have to translate your product into.
Each event lands on the contact's append-only log, and from there it is three things at once. A trigger, so a funnel starts when it arrives. A predicate, so a segment can say "has done this in the last fourteen days" or, more usefully, "has not". And a goal, so a sequence ends the moment somebody does the thing it was nudging them towards.
That third one is what makes lifecycle messaging bearable to receive. The nudge to finish setting up your account should stop existing the second the account is set up, and in most tools it does not, because the sequence and the product are not talking to each other.
- ⚡Trigger
api_event—signup.completed, planfree. - 2Send e-mailThe one thing to do first. Not a tour of eleven features.
- 3Wait 2 days
wake_aton the run. Nothing queued, nothing to unpick if you rewrite this tomorrow. - ?ConditionHas
project.createdarrived? No → the help branch. Yes → the goal below. - 4Help branchOne message, offering the specific thing they did not do. Then a second wait.
- 5Goal
project.createdarrives. The run exits. No further onboarding mail, ever, for this person.
Your event namesYour definition of activated
Five funnels
The lifecycle,
in the order it actually happens.
1 · Activation
Trigger: sign-up. Two or three messages, each about one action, each with a goal that ends the sequence when that action happens. The most valuable funnel you will build, and the one most worth rewriting three times.
2 · The stall
Trigger: segment_enter — signed up, no meaningful event in seven days. One message that asks rather than tells, and one that offers a specific thing. Then stop. A fourth message to somebody who has ignored three is a message to nobody.
3 · The expansion moment
Trigger: an event that means they are getting value — hit the limit, invited a third colleague, exported for the second time. This is the only moment an upgrade message is welcome, and it is a moment your product can name precisely.
4 · Renewal and dunning
Trigger: date_field before renewal, or a payment event. Notice, reminder, and — if a payment fails — a short sequence that stops the instant it succeeds. Goal nodes are not optional in dunning; they are the difference between a reminder and harassment.
5 · Win-back
Trigger: segment_enter — cancelled or dormant for sixty days. Two messages, honest ones, then a tag and silence. What changed since they left is a better message than a discount.
And the internal one
notify_team tells a human when an account worth a human crosses a line. A funnel does not have to end in an e-mail to a customer; sometimes the right action is telling somebody on your side to pick up the phone.
Nobody churns on purpose.
They just stop opening it.
Why a developer might actually like this
The parts that matter
when you are the one integrating.
No private endpoints
Every screen is buildable from the public API, because there is no other kind. If you want to embed a campaign report in your own admin, nothing is in your way and nothing has to be reverse-engineered.
Idempotency keys everywhere
On every mutating route. Your retry logic, your at-least-once queue and your flaky network all become somebody else's problem — specifically, a unique index's problem.
Simulate before you ship
POST /v1/simulate dry-runs a contact through a funnel and returns the path and every message it would send. Put it in CI if you like: a funnel is a graph, and a graph can be tested.
An MCP server
Point an agent at /mcp and let it author and check funnels. Send-capable tools need an explicit confirmation and are capped by quota, so a misread prompt cannot become fifty thousand e-mails.
Webhooks out
Signed, retried with backoff, at least once. The same event vocabulary the reports use, so your warehouse and your dashboard do not disagree about what "delivered" means.
Erasure that actually reaches
A deletion request removes the contact and their message history here and fans out to every sibling service that held a copy. One request, one outcome, and something you can point at when asked.
Where the boundary sits.
ClickSomo holds a mailing list and what that list did. It is not your user database and it is not trying to be: a contact never carries a credential, never signs in, and never becomes an account. Your users live in your product; contacts live here, and the two are joined by an e-mail address and the events you choose to send.
That separation is deliberate and it is the reason the consent model works. You are the data controller for your users; we process on your behalf. A design where a marketing tool quietly becomes the identity store is one that cannot be untangled later, and it is exactly the failure this one is built to avoid.
The practical version: send the events, send the attributes you want to segment on, and keep everything else where it is. If you find yourself pushing your whole schema in here, the segment you are trying to build is probably a query in your own database that should arrive as one boolean attribute instead.
Tell us what you send today,
and to how many.
We will show you what it looks like here — usually with the funnel drawn, because that is faster than a paragraph about it.
Open ClickSomo Talk to a person