Preventing churn in set-and-forget products

How to measure and cultivate engagement when your product is active but your users aren’t.

Learn how to deliver AI-powered, self-serve analytics customers will pay more for, backed by new research from the 2026 Embedded Analytics Opportunity Report.

71% of teams embed analytics but 57% see no ROI, top teams hit 150%+ returns, and 91% plan to launch AI vs. just 14% in production.

The gap nobody’s frameworks cover

A company I advised had a particular type of growth problem that isn’t talked about much.

Activation was strong. Retention was fine (but not trending in the right direction). They were sitting on a ton of usage data so they pointed a data scientist at the problem to find behavioural predictors of long-term retention. Which signals in the first 30 days predict who’s still paying in 12, 18, 24 months?

The answer: nothing. No feature, no usage pattern, no frequency threshold. With hundreds of thousands of customers, they couldn’t find a single behavioural signal that predicted long-term retention.

But the issue wasn’t with the data. It was much more fundamental - the category they’re in. Their product is effectively set-and-forget: you configure it once, and if it works, you never come back. They were searching for human-behaviour predictors in a product where humans don’t behave.

I’ve written a lot about engagement and retention e.g. user growth accounting, growth state models, engagement states. Nearly all of it assumes that a healthy user is one who keeps showing up. For a whole category of products, that assumption isn’t valid. And if you run growth for one of them, most written advice out there (my past content included) leaves you with a gap: what happens between activation and the renewal invoice?

Set-and-forget is a category, not a flaw

Take email and notification plumbing. Transactional email delivery, bounce handling, webhook routing, alert deduplication, escalation policies, notification fan-out. A developer signs up, grabs an API key, wires it into the codebase, tests that the password-reset email lands, and ships. Maybe they configure an escalation policy and a bounce webhook. That’s the whole relationship. If the product does its job, that developer has very little reason to ever log in again.
It’s part of the value proposition. “You’ll never think about email deliverability again” is the pitch. Something is very broken if there are users who log in daily to check whether their emails are sending. It means those users don’t trust you.

The category is bigger than you’d think: uptime monitoring, backups, DNS, cert management, dependency scanning, feature flags at steady state. If your roadmap has ever included the phrase “give users a reason to come back,” and it felt like pushing water uphill, you’re probably in it.

No habit loop, no DAU worth measuring, no session-based engagement model. Do we just give up on engagement and wait for the renewal to tell us how we did?

No. We change who (or what) we’re measuring.

Redefine the actor

No need for panic; your engagement frameworks still work, but you need to point them at a different actor.

After that developer ships the integration and moves on, something is still using the product every day: the integration itself. Emails send, bounces get handled., webhooks route, and alerts get deduplicated at 3am. The deployment has a heartbeat, and it beats far more regularly than any human user ever would.

So the simple solution is to track usage from two different perspectives, i.e. run two ledgers.

The machine ledger tracks the deployment: is the integration live, is it processing volume, is that volume trending in line with the customer’s business? This ledger is continuous, high-frequency and honest (seasonality and the odd staging environment aside). It can’t be flattered by a well-timed email campaign.

The human ledger tracks the people: logins, dashboard sessions, report opens. In this category it’s sparse by design, and that’s fine. It has a different job (more on that later).

Growth accounting works on the machine ledger with one change: swap the unit. Instead of new, retained, resurrected and churned users, you count new live integrations, retained live integrations, resurrected integrations (volume came back) and churned integrations (volume went to zero).

Use the same states as the growth state model, but a different actor. “Active” means the integration is live and processing, not that a human showed up.

Do that and the mystery from the intro dissolves. The company I advised couldn’t find behavioural predictors of retention because they were looking at the human ledger while the signal was in the machine ledger the whole time.

Churn already happened but you didn’t get the news yet

The machine ledger is so important because monetary churn is a lagging indicator. By the time the cancellation hits your dashboard, the decision was often made months earlier. And in a set-and-forget product, that earlier moment usually leaves a trace.

Think about how churn actually happens with email plumbing. It’s rarely someone logging in, looking around and cancelling. More often: the customer replatforms and the integration doesn’t survive the migration. Or a new engineering lead consolidates vendors and swaps your SDK for a competitor’s. Or the customer’s own product is declining and send volume decays with it.

In each case the commercial event (cancellation, non-renewal) is just the paperwork catching up with an operational event that already happened: your product stopped doing work.

Each of these is visible in the machine ledger long before it’s visible in revenue. Send volume dropping to zero means the integration was ripped out. Volume decaying quarter over quarter means the customer’s business is shrinking. An error rate spike followed by silence means a migration broke the integration and nobody came back to fix it (because nobody comes back, remember).

Of these, the replatform deserves a special mention as the canonical silent churn event in dev tools. Nobody decided to leave you. Your integration just wasn’t important enough to survive the rewrite.

And volume going up isn’t automatically good news either. Usage growth means invoice growth, and if you’re on volume pricing that isn’t competitive, a rising bill is often the trigger that puts you under evaluation. The customer’s finance team notices the line item, someone gets asked if there’s a cheaper option, and an integration that was invisible for two years is suddenly on a spreadsheet next to three alternatives. With price-sensitive customers, that growth looks like expansion revenue right up until it becomes the reason they leave.

Something to be aware of - you won’t know in advance which of these signals actually predict churn for your product. That’s exactly why you capture them now. When the negative events happen (and they will), you can look back, correlate the signals with the outcomes, and build the early-warning system that gets you ahead of the next one. But only if the data is there to correlate.

So the retention playbook here isn’t a re-engagement campaign. It’s pre-churn detection: alerting on the machine ledger the way your customers alert on their own infrastructure. An integration that went quiet three weeks ago is a renewal conversation you still have time to change. A cancellation notice is not.

Value delivered ≠ value felt

There’s a second problem the machine ledger can’t solve on its own. Even for customers whose integrations are perfectly healthy, value in this category is delivered continuously but felt never.

This is the same structural problem insurance has. You pay every month, the product works silently in the background, and the value only becomes visible on the day something goes wrong. In the meantime, the one recurring touchpoint you reliably have with the customer is the invoice. The only time you show up is when you charge them, and that’s a bad position to be in when renewal comes around.

The fix isn’t getting people to log in more. What works instead is engineering moments where the value gets felt, with zero effort required from the user. A quarterly digest: 2M sends delivered, 40k bounces caught before they damaged your sender reputation, 12 incidents deduplicated before they woke anyone up. A short note when you handled something automatically: “we rotated your DKIM records, nothing needed from you.” The customer reads it in 20 seconds, thinks “glad that’s handled”, and gets on with their day.

I want to be clear about something though - these aren’t marketing emails and you shouldn’t treat them as such. They’re receipts for work performed. The goal isn’t to fight set-and-forget - it’s to turn set-and-forget into set-and-felt. And in this category, engagement with those receipts is a real metric rather than a vanity one; it’s the measurable trace of value being felt, not just delivered. (Measure clicks and replies rather than opens given what Apple’s Mail Privacy Protection did to open rates.) That trace is what you want sitting in the customer’s recent memory when the renewal invoice lands.

Don’t poke the bear?

“Any touchpoint invites a cancellation decision. Why would we remind people they’re paying us?”

I’ve had this conversation more times than you might think, because it’s a fair concern. And it’s half right. But it conflates two very different kinds of touchpoint. An activity nudge (“come back and check out your dashboard!”) asks the user to do work, and implicitly invites them to ask why they’re paying for something they never use. Value reinforcement (“here’s what happened while you weren’t looking”) does the opposite: it makes the invisible work visible and lowers the perceived case for cancelling. And if you’re still nervous, this is a testable claim, not a matter of opinion: hold out a segment, send the digest to everyone else, and compare renewal rates instead of debating hypotheticals.

The two ledgers also tell you which accounts are which. A healthy integration with a dormant human is fine: reinforce quietly, ask for nothing. A dead integration with a dormant human is not a bear you might wake. They’re already gone; the only question is whether you find out now (when a win-back conversation is still possible) or at renewal (when it isn’t). The bear to worry about isn’t the one you might wake. It’s the one that already left the cave.

Engagement is an expansion prerequisite

The strongest reason to care about any of this only shows up when you need to grow revenue from your existing base.

Most set-and-forget companies eventually face NRR (Net Revenue Retention) pressure. The core product is priced per integration or per volume tier, natural expansion is limited, and the answer is usually a second product: the email plumbing company adds SMS, push notifications, an alerting product. At that point the engagement question flips. It stops being “does engagement predict retention?” (in my experience, only if you’re measuring the right things), and becomes “do we have any surface on which to sell the next thing?” And that’s the human ledger’s different job I promised earlier: it measures whether expansion is even possible.

Cross-selling push notifications to an account that hasn’t touched your dashboard in 18 months is possible, but it’s a cold outbound motion with none of the product-led advantages you built the business on. The value digest becomes the road back to the product, and the product is where expansion conversations happen. In set-and-forget, engagement is more than just a retention lever. It’s an expansion prerequisite.

Set-and-forget is the customer’s privilege. It can’t be yours as a vendor. So, pick your machine heartbeat metric, define “active” at the integration level, rebuild your growth accounting on it, alert when volume goes quiet (or spikes beyond what the customer’s pricing tier makes comfortable), and put a first receipt-for-work-performed in front of your dormant-but-healthy accounts.

The humans may not come back but the signal is still there. Make it felt.

Book a free 1:1 consultation call with me - I keep a handful of slots open each week for founders and product growth leaders to explore working together and get some free advice along the way. Book a call.

View the State of AI Search for Dev Tools 2026 benchmark report - 126,814 citation records across 1,075 representative tool-evaluation scenarios, 43 developer-tool categories, and five AI search platforms

View your free public Dev Tool AI Market Presence Report - 500+ dev tools across 47+ verticals and growing, all in the Dev Tool AI Search Landscape.

Sponsor this newsletter - Reach over 11,000 founders, leaders and operators working in product and growth at some of the world’s best tech companies including Paypal, Adobe, Canva, Miro, Amplitude, Google, Meta, Tailscale, Twilio and Salesforce.

Thanks again to this weeks sponsor: ThoughtSpot