Product Thinking

The churn was decided three signals ago

An account doesn't die at renewal. It dies when usage drops, the tone sours, and the tickets spike, three weeks earlier, in three different tools nobody reads together.

ASR

Apollo Space Research

Apollo Space

· 11 min read

The renewal email bounces back with a polite “we’ve decided to go another direction,” and everyone acts surprised. Nobody should be. The account didn’t decide to leave that morning. It decided three weeks earlier, when daily logins fell off a cliff, the support thread turned cold and clipped, and a champion who used to reply in minutes went quiet. The signals were all there. They were just in three different tools, and no single human was reading them together.

That’s the whole problem in one sentence. Churn is rarely a surprise. It only feels like one because the warning was distributed across systems that don’t talk.

The account doesn’t die at renewal. It dies three signals ago, and the only question that matters is whether anyone was watching when it happened.

This post is about the operational role that does the watching: the one that correlates the usage drop, the sentiment shift, and the ticket spike into a single flag, with the reason it fired and the play to run, before the renewal, not after.

The naive version: a dashboard nobody opens at the right time

The obvious answer to “are our customers healthy?” is a health-score dashboard. You’ve seen it. A column of accounts, a colored dot next to each, green-yellow-red, sorted by a number someone computed from logins and feature adoption. It looks like the answer.

It isn’t, for a reason that has nothing to do with the math.

A dashboard is a place you go. It waits for you to open it, and you open it when you remember to, which is roughly never on the Tuesday that matters. The red dot was red on Tuesday. You looked on Friday, after the cancellation. The score was right; the timing was fatal. Worse, the score is usually built from one stream, product usage, because that’s the stream that’s easy to pipe into a number. So the account where usage looks fine but the last three support tickets were furious shows up green, and you trust the green, and you lose it anyway.

Let me name the two failures plainly, because they’re different. The first is that a dashboard is reactive: it holds the truth but never hands it to you, so you find out by walking over to it after the fact. The second is that a single-signal score is blind: usage alone misses the account that’s still logging in out of habit while its patience runs out in the support queue. A green dot on a dying account isn’t a small error. It’s the most expensive kind, because it tells you to relax.

The bottleneck was never computing the score. It was that the score sat in a box, fed by one pipe, waiting to be visited.

What “customer health” actually decomposes into

Strip away the dashboard and ask what a sharp customer-success person is actually doing in their head when they sense an account going sideways. They’re not reading a number. They’re correlating three streams that each tell a third of the story.

Usage is the behavioral signal: are they still in the product, doing the thing the product is for? A drop here means the habit is breaking. Sentiment is the emotional signal: how does the last round of conversation sound, the support replies, the meeting tone, the email that used to end with “thanks!” and now ends with a period. A shift here means the goodwill is draining. Tickets are the friction signal: how many problems, how severe, how fast resolved? A spike here means the product is actively costing them effort.

Any one of these, alone, lies. Usage drops during a holiday week and nothing is wrong. A single terse email is just a busy Tuesday. One ticket is one ticket. The intelligence isn’t in any single stream, it’s in the conjunction. Usage falling and sentiment souring and tickets spiking, in the same account, in the same two weeks, is not three coincidences. It’s a customer leaving in slow motion.

So the real job isn’t “compute a health score.” The job is: watch three streams continuously, notice when they bend together, and the moment they do, speak, to a person, with the reason and the play.

Three independent signals about one account, a drop in product usage, a souring of conversation tone, and a spike in support tickets, each living in its own tool. Read alone, each looks like noise. Read together by a continuous watch, the conjunction becomes one at-risk flag with a reason.

The operational role: a watch that speaks first

Here’s the shift, and it’s the same shift that separates a chatbot from a coworker: who moves first.

A dashboard waits to be asked. The role we’re describing asks nothing. It runs continuously, holds the three streams in one place, and when the conjunction trips, it opens the conversation, the way a good account manager would lean over and say “hey, I’m worried about this one.” It doesn’t replace the human’s judgment about what to do. It replaces the part the human is structurally bad at: noticing, across three tools, at the moment it matters, every time, for every account, without getting tired.

The naive automation version of this is a threshold alert. “Email me when usage drops 40%.” Reasonable, until you live with it. Single-threshold alerts are either too loud or too quiet. Set them sensitive and every holiday week buries you in false alarms until you mute the channel. Set them strict and they only fire after the account is already gone. A threshold on one stream can’t tell the difference between a customer on vacation and a customer on the way out, because the difference isn’t in the magnitude of one drop. It’s in whether the other two streams moved with it.

The conjunction is what makes the flag trustworthy. A usage dip with steady sentiment and zero tickets is probably a vacation, stay quiet. A usage dip with a cold last email and two escalated tickets is a fire, speak now. The same usage number means opposite things depending on the company it keeps. That’s why this has to be a watch that reasons over the conjunction, not a trigger wired to a single metric.

And when it does speak, it can’t just say “Account X is at risk.” A bare flag is a guess you’re handed and asked to trust. It has to carry two things a number never does: the reason and the play.

The reason is half the product

Imagine the flag arrives like this. Not “Account X: health 41, red.” Instead: “This account is at risk. Logins are down sharply over two weeks after running steady all quarter. The last two support threads escalated and stayed unresolved for days. The tone in the most recent reply turned curt, short sentences, no sign-off, none of the warmth from earlier in the relationship. The renewal is in roughly five weeks.”

Read that and notice what just happened. You don’t have to go verify the alarm. The alarm verified itself. It named the three streams, it told you which way each one bent, and it connected them to the date that makes it urgent. You can argue with it, maybe you know the champion just had a baby and the curtness is unrelated, but now you’re arguing with evidence, not a colored dot.

This is the part single-signal scores can never do. A number compresses the whole story into one digit and throws away the reason. The reason is the value, because the reason is what tells you which play to run.

Because the play depends entirely on why. An account that’s at risk from a ticket spike needs an engineer and an apology, the product is hurting them. An account that’s at risk from a usage drop with no tickets needs re-onboarding, they’re not getting value, maybe they forgot how. An account that’s souring in tone before a renewal needs the human relationship, a real call from a real person, not another in-app nudge. Same red flag, three completely different responses. A score that only says “red” sends you in blind. A flag that says why it’s red hands you the play before you ask.

On the left, a single-signal threshold fires on a usage dip and emails a bare red alert, which lands during a holiday week and gets muted. On the right, a continuous watch correlates three streams, fires only on the conjunction, and delivers a flag that names the reason and prescribes the play to a person.

Why this has to live in the company brain, not a CS tool

You could imagine bolting this onto a customer-success platform. It would be a real improvement, and it would still hit a wall, because the three streams don’t all live in the CS tool.

Usage lives in the product analytics. Sentiment lives in the support inbox and the meeting notes and the email threads. Tickets live in the helpdesk. The renewal date lives in a contract in a folder somewhere, or in the billing system, or in a sales note from nine months ago. To correlate them, you need a system that already reads across all of it, that holds the customer’s product behavior, their conversations, their support history, and their contract dates in one continuous memory, and watches that memory for the conjunction.

That’s not a feature you add to a dashboard. That’s a property of the substrate the whole thing runs on. The reason Apollo can watch customer health is the same reason it can do any of the cross-corner work: it isn’t a tool you query, it’s an operating system for the company that already has the inbox, the calendar, the relationship history, and the documents in one place. The watch is just one of the things you can stand up on a brain that doesn’t forget and doesn’t wait to be asked. Suppose the streams were already unified and already being read, then “flag the at-risk account, with the reason and the play, before renewal” stops being an integration project and becomes an instruction.

The hard part was never the alert. The hard part was having all three streams in one mind at once, continuously, so the conjunction is even visible.

The turn: stop finding out at renewal

Here’s the part that isn’t about software.

Right now, in most companies, somebody finds out an account is unhappy when the cancellation lands, or, if they’re lucky and diligent, when a heroic account manager happens to remember to check three tools on the right Tuesday. That diligence feels like the job. It’s actually a tax on the most relationship-skilled person you have, spending their attention on noticing instead of on the thing only they can do: making the call, having the conversation, saving the customer.

The point of a watch that speaks first isn’t to replace that person. It’s to give them their attention back. Let the system do the part it’s good at, reading three streams across every account, every day, without missing one, so the human does the part only a human can: walking into the at-risk conversation already knowing what’s wrong and what to try, while there’s still time to try it.

A customer you save in week one of the slide is a renewal. The same customer you discover at renewal is a postmortem. The difference between those two outcomes was never a smarter model or a prettier dashboard. It was whether anyone was watching the three signals when they bent together, and whether the watch spoke first.


That’s what we’re building at Apollo Space, not another health-score column you remember to check on the wrong day, but a watch that reads the usage, the tone, and the tickets together and tells a real person, this one, now, here’s why, here’s the play. The account that left you on Tuesday was already leaving in March. The only thing that changes the ending is who was watching in March.

Apollo runs your company's repetitive ops so your team doesn't.

Join the waitlist for early access, founding-user pricing, and a front-row seat as we ship.

Join the waitlist