Solo B2B SaaS founder fighting silent churn

Silent disengagement becomes a visible, early signal

Cadence reaches a state where the 5–6 week revert-to-meetings pattern shows up as an observable signal on a dashboard or alert — not as a cancellation email. The signal exists before the account goes quiet, and it is specific enough that someone other than you can act on it.

Why this matters: Today the first time you learn an account is gone is the cancellation. That is the single mechanism driving churn from 3.1% to 6.8%. Until this signal exists, every other improvement is downstream of a blind spot.

How they'll know it's real: Within 12 months, every account that churns was flagged as at-risk at least 2 weeks before cancellation, and the flag was visible without you opening a tool.

Because you said: Catalyst · Buyer Outcome · Stakeholders

Re-activation runs without you in the loop

When the disengagement signal fires, an on-brand re-activation motion — a champion nudge, a fix suggestion, a check-in — executes automatically or through the VA's checklist. You are not the person who notices, drafts, or sends. The motion survives you being heads-down on product for three weeks.

Why this matters: You are the bottleneck on support today, and your north star explicitly requires you off support and on product/strategy. If re-activation depends on you, the system cannot scale to the 4-person, $3M ARR shape you described, and it cannot survive your product sprints now.

How they'll know it's real: At least 80% of at-risk flags in a given month result in a re-activation touch that you neither wrote nor sent, and you can name the week you last personally handled one.

Because you said: Buyer Outcome · Buyer · Stakeholders · North Star

The retention stack is VA-operable, not founder-operable

The 2–3 AI capabilities that move retention are wired together such that a $25/hr ops VA with a daily checklist can run them. No bespoke ML, no on-call founder, no step that requires your judgment to complete the day. Customer Slack content stays inside DPA-covered tools.

Why this matters: Your hard constraints — 6 hrs/wk ceiling, $800/mo tooling, no bespoke ML, DPA-only data paths, no onboarding friction — mean any solution that requires founder operation is the wrong solution by definition. This is the constraint that kills most architectures before they start.

How they'll know it's real: The VA completes the daily checklist end-to-end on a day you are unreachable, with no escalations to you, and no customer content leaves DPA-covered systems.

Because you said: Buyer Outcome · Buyer · Constraints · Stakeholders

Retention is reported in cohort numbers, not vibes

Cadence reaches a state where net revenue retention is reportable by signup cohort on demand — you can answer 'how is the Q2 cohort retaining vs. Q1' in minutes, not by guessing. This is the substrate the angel conversation and every future retention decision sits on.

Why this matters: Your north star is explicitly retention-driven compounding, NRR >115%, and you have a possible angel round in 6 months. A defensible NRR story requires cohort numbers, not anecdotes. Without this, you cannot tell whether the rest of the system is actually working.

How they'll know it's real: At month 60 days post-rollout you can produce a cohort NRR view in one sitting, and it is the artifact you would show an angel.

Because you said: Buyer Outcome · North Star · Buyer

Your time stays under the ceiling, including during product sprints

The system reaches a state where its weekly operation costs you under 4 hours, and its weekly operation costs the VA roughly 6 hours, and a 3-week founder-absent window does not degrade the disengagement signal or the re-activation motion.

Why this matters: You named 6 hrs/wk as a hard ceiling and 3-week heads-down windows as a survival requirement. If the architecture passes every other test but quietly consumes 10 hours of your week, it has failed — because product work stops, and product work is the actual moat.

How they'll know it's real: Across any rolling 4-week window — including one where you were absent for 3 of them — the at-risk flagging and re-activation motions ran on schedule and your logged hours on the system stayed under 16.

Because you said: Buyer · Constraints · Buyer Outcome

Physical reality — the hard ceiling on what can get done

Your operation has exactly two pairs of hands: ~6 hrs/week of you, and ~6 hrs/week of a $25/hr ops VA you haven't hired yet. You must also survive three-week stretches where you are heads-down on product and effectively unavailable. That is the entire labor substrate — anything proposed in later layers has to fit inside it, including weeks when your hours are zero.

Why this matters: Most retention playbooks assume a CS person or at least a founder who can jump on calls. You have neither. If a solution can't run untouched for 3 weeks straight, it doesn't exist for you.

How they'll know it's real: A proposed motion can be paused mid-week by you going heads-down on product and still produce the right outcome at week's end.

Because you said: Buyer · Constraints

What you can read today without copy-paste — and what's dark

Readable today: billing/MRR, seat counts, the fact that a cancellation email arrived. Not readable today: per-team async adoption trend, the moment a team's standup participation starts decaying, whether a champion has gone quiet, NRR by signup cohort. You said it plainly — you cannot see the silent-churn signal until it is a cancellation. So the instrumented surface of your business currently ends at 'they paid' and 'they left.'

Why this matters: You asked for a 60-day NRR-by-cohort read and an early disengagement signal. Both of those are things your operation literally cannot see today. Naming that gap is the whole job of Layer 2 — Layer 3 will have to install the missing reads.

How they'll know it's real: You can answer 'which teams are 5 weeks in and trending toward revert?' without opening Slack or running a query by hand.

Because you said: Catalyst · Buyer Outcome · Stakeholders

What the operation can actually execute today (not what's claimed)

Today's real operating motion: you do 100% of support, reactively, when something reaches your inbox. There is no onboarding follow-up after the champion configures. There is no week-5 nudge. There is no VA, no checklist, no re-activation sequence — those are aspirations in F3/F6, not running processes. The honest current-state execution capacity is: 'founder answers tickets when they arrive.' Everything else in the binder has to be built from zero, not optimized from existing.

Why this matters: It would be easy to describe the target motion as if it were partially in place. It isn't. Treating this as a greenfield build (with a 6 hr/wk ceiling) is the only way the 90-day plan stays honest.

How they'll know it's real: Anyone could write down today's retention motion in one sentence — because there isn't one beyond 'reactive support.'

Because you said: Catalyst · Buyer · Stakeholders

What the money allows

$800/mo recurring tooling ceiling, ~$3k one-time, and that $800 has to start showing NRR impact or it gets cut. VA labor is ~$600/mo (6 hrs/wk × $25). So the entire retention apparatus — detection, nudges, re-activation, cohort reporting — has to fit inside roughly $1,400/mo all-in, with a clock on proving it. No bespoke ML build (you've ruled it out), no enterprise CS platform.

Why this matters: This rules out a large portion of what a typical 'fix churn with AI' answer would propose. The financial envelope forces the Layer 3 design toward assembled, off-the-shelf tools wired in an afternoon — which is also what you said you'll accept.

How they'll know it's real: Every tool in the eventual stack has a line item under $800/mo total and a named NRR metric it is supposed to move.

Because you said: Constraints · Buyer

What's load-bearing for the 5-year outcome

Your north star is explicit: NRR-driven compounding, not top-of-funnel. $3M ARR with >115% NRR, run by a 4-person team with you on product, not support. That means two things are load-bearing right now and must not be compromised by any short-term fix: (a) the async-by-default opinion that makes Cadence itself — a re-activation motion that nudges teams back into meetings would destroy the product; (b) the founder-out-of-support trajectory — any solution that routes through you defeats the 5-year shape. The angel round in 6 months also depends on a defensible cohort NRR story, not vibes.

Why this matters: It's tempting to solve churn with whatever works in 90 days. But a fix that puts you back in the support seat, or softens the async opinion, wins the quarter and loses the company.

How they'll know it's real: The proposed motion is something a VA runs, reinforces async behavior (not meetings), and produces cohort NRR numbers an angel would accept.

Because you said: Identity · North Star · Stakeholders

How your apparatus produces recommendations specific to you (not a template)

The recommendation set is built backward from your stated outcome — an early silent-disengagement signal plus an automated re-activation motion the VA runs — not from a generic 'SaaS retention stack' archetype. That means anything proposed has to (a) detect the week-5 revert pattern you actually described and (b) be operable by a $25/hr VA on a checklist. A generic retention playbook would surface CSM tooling, NPS surveys, and lifecycle email suites; for you, most of that fails the operability test and gets dropped before it's even considered.

Why this matters: You are the only full-timer with 6 hrs/week. A template stack would consume your runway before it produced an NRR read.

How they'll know it's real: Every recommended capability can be traced back to either the silent-disengagement signal or the VA-run re-activation motion. If a recommendation can't, it shouldn't be in your set.

Because you said: Catalyst · Buyer Outcome · Buyer · Constraints

The order things get turned on for you

Touchpoints are sequenced so the disengagement signal exists before the re-activation motion is wired, and the VA checklist exists before either is handed off. Concretely for Cadence: first, an account-health view that flags 'standup completion rate dropped >30% week-over-week around week 4–6' (signal layer); second, an on-brand async nudge to the eng-manager champion when that flag fires (intervention layer); third, the VA's daily checklist that confirms flags fired correctly and nudges went out (operations layer); fourth, the cohort NRR read at day 60 (measurement layer).

Why this matters: Wiring the nudge before the signal is calibrated would burn champion trust — the exact relationship that's already fraying at week 5. Wiring measurement before intervention would give you a clean read of a system that isn't doing anything yet.

How they'll know it's real: At each stage, the prior stage is observably running before the next is turned on — not assumed to be running.

Because you said: Catalyst · Buyer Outcome · Stakeholders

What has to be true before a tool is even eligible

A tool only enters consideration if it clears your information-sufficiency bar: it can ingest Cadence's existing standup-completion and posting-frequency data (which you already have, no DPA expansion needed) and emit a flag the VA can act on. Tools that would need raw customer Slack message content do not clear the bar at all, because of your DPA rule. This eliminates most off-the-shelf 'conversation intelligence' and 'customer health AI' products before pricing is even discussed.

Why this matters: Your DPA limit isn't a preference, it's a hard wall. Most retention-AI vendors silently assume content access and fail this test.

How they'll know it's real: Every tool in the final set operates on metadata you already lawfully hold (completion rates, posting cadence, configuration state) — never message content.

Because you said: Constraints · Identity

What gets removed from the pool, and when

A tool is removed the moment it (a) breaches the $800/mo ceiling without a traceable NRR contribution, (b) requires you on-call to keep running, or (c) drifts into needing maintenance the VA can't perform on a checklist. Concretely: if a chosen workflow tool starts requiring you to debug API errors during a heads-down product sprint, it is removed, not nursed.

Why this matters: You've stated you go heads-down on product for 3-week stretches. A tool that can't survive that is, in your context, a liability disguised as an asset.

How they'll know it's real: Removal happens on the rule, not on a feeling. The VA can flag a removal candidate without your judgment.

Because you said: Buyer · Constraints

What you do when a tool changes under you

Because the apparatus is assembled (not built) from third-party tools you 'wire in an afternoon,' tool drift — pricing changes, API deprecations, capability shifts — is treated as expected, not exceptional. The response: each capability slot has a named function (e.g., 'fires the week-5 flag'), and the tool currently in that slot is swappable. The VA checklist references the function, not the tool name, so a swap doesn't break operations.

Why this matters: You explicitly refused to build/maintain bespoke ML. The flip side of that choice is that your vendors will change on you, and the design has to absorb that without consuming your 6 hrs/week.

How they'll know it's real: A tool swap takes you one afternoon and zero VA retraining beyond a one-line checklist edit.

Because you said: Buyer · Constraints

How the method handles improving itself in your operation

Given your 2-quarter runway pressure, improvement is triaged toward NRR-moving changes only. A change is worked on if it plausibly affects the week-5 revert rate or the cohort NRR number; everything else (UI polish on the VA dashboard, nicer flag visualizations, etc.) waits. This is the opposite of a comprehensive rebuild — you cannot afford one.

Why this matters: You have ~2 quarters before the churn compounds past recoverable. Comprehensive improvement would spend runway you don't have.

How they'll know it's real: Every improvement in flight can be traced to a hypothesis about NRR or week-5 revert. If it can't, it's parked.

Because you said: Catalyst · Buyer Outcome · North Star

When 'doing more than promised' is actually an alarm

If the apparatus starts producing more than the agreed daily VA checklist + weekly NRR cohort read — for example, the VA starts hand-investigating accounts the system didn't flag, or you start personally jumping into champion DMs — that overdelivery is treated as a signal the underlying system is failing, not as virtue. The response is to fix the signal layer so the extra work isn't needed, not to normalize the extra work.

Why this matters: Your entire stake is being able to go heads-down on product for 3 weeks. Heroic VA work or founder rescues quietly recreate the exact reactive-support trap you're trying to exit.

How they'll know it's real: Hours logged by you or the VA stay within the 6 + 6 ceiling week after week. A breach is investigated as a system defect.

Because you said: Catalyst · Buyer · Constraints

How accounts move between lifecycle stages

Accounts have observable stage transitions tied to your week-5 pattern: Configured → Active (standup completion stable) → Drifting (completion dropping, the silent-disengagement state you described) → Recovered or Lost. Transitions are triggered by the signal layer, not by calendar time or CSM intuition. The re-activation motion is what a Drifting account receives; it is not sent to Active accounts (which would feel like noise) or Lost accounts (which need a different motion you haven't scoped here).

Why this matters: Today every account is one undifferentiated bucket until the cancellation email arrives. Naming the Drifting state is the entire point of the silent-disengagement signal you asked for.

How they'll know it's real: At any moment you can pull a list of which of your ~140 teams are in each stage, without asking the VA or yourself a judgment question.

Because you said: Catalyst · Buyer Outcome · Stakeholders

What shape of service you're accepting from this apparatus

You are explicitly accepting a service shape of: automated detection + automated on-brand outreach + VA verification, with you out of the loop on individual accounts. You are not accepting: a high-touch CSM model, a model where you personally write re-activation messages, or a model where the VA exercises judgment on which accounts to nudge. This shape is chosen because it's the only one that fits 6 hrs/week and survives your 3-week product sprints.

Why this matters: Many retention improvements implicitly assume a human-in-the-loop CSM. Accepting that shape would silently violate your time ceiling and your 'nothing that needs me on call' rule.

How they'll know it's real: When a Drifting account is detected during a week you're heads-down on product, the nudge still goes out, on-brand, without your involvement.

Because you said: Buyer · Constraints · Stakeholders

How cohorts are admitted to the measurement read

Your 60-day cohort NRR read defines what counts as a cohort: teams that entered Active stage in the same calendar week, tracked forward together. New signups during the rollout are admitted to fresh cohorts, not retrofitted into earlier ones, so the read stays honest. This is the basis of the 'NRR by cohort, not vibes' deliverable and the defensible story for the angel round.

Why this matters: Mixing cohorts is how SaaS founders accidentally tell themselves stories. A clean cohort admission rule is what makes the 60-day read defensible to an angel investor reading critically.

How they'll know it's real: You can name, for any week in the last quarter, which teams are in that week's cohort and what their net revenue retention looks like at day 30, 60, 90.

Because you said: Buyer Outcome · North Star

Integration 1 — Your command center: one page showing which teams are drifting, which are healthy, and which need a human touch this week

A single dashboard (think Retool, a Notion board fed by a script, or a Metabase view) that lists every paying team with a health state — Configured / Adopting / Drifting / At-Risk / Reverted — plus the last signal date. You glance at it once a week; the VA works from it daily. This is the artifact that replaces 'I find out at the cancellation email.'

Why this matters: Your catalyst is that silent churn is invisible until it's terminal. Without a cockpit, every other integration below is just pipes feeding nowhere. This is the surface where the early disengagement signal F3 asks for actually becomes visible to a human.

How they'll know it's real: You can open one URL and, in under 60 seconds, name the five accounts most likely to churn this month and why.

Because you said: Catalyst · Buyer Outcome · Buyer · Stakeholders

Integration 2 — The buyer-support agent: an automated, on-brand responder that handles the routine support load so you're not the bottleneck

An assistant (e.g. Pylon, Plain, or Intercom Fin wired to your docs) that answers configuration and 'how do I…' questions in-product or in shared Slack, in Cadence's opinionated async voice. The VA reviews its drafts; you only see escalations.

Why this matters: Today you do 100% of support reactively (F2), which is exactly what prevents you from seeing the drift signal in time. Offloading routine support is the precondition for your 6 hrs/wk ceiling (F5) surviving 3-week heads-down product sprints (F4).

How they'll know it's real: The VA closes >70% of inbound questions without pinging you, and response time stays under 4 hours even during your product sprints.

Because you said: Catalyst · Buyer · Constraints

Integration 3 — A strategic-partner agent for you, the operator: an AI that helps you read the weekly numbers and decide what to change

A lightweight weekly review — a ChatGPT/Claude project pre-loaded with your cohort retention data, the cockpit export, and your North Star — that you spend 30 minutes with each Friday to surface 'what changed, what to test next, what to ignore.'

Why this matters: F7 says the bedrock is NRR-driven compounding, and F3 wants a 60-day cohort read, not vibes. You have no co-founder to argue with. A structured weekly thinking partner is the cheapest substitute and fits inside your 6-hr ceiling.

How they'll know it's real: Every Friday you end with one written decision (test, kill, double-down) tied to a cohort number, not a feeling.

Because you said: Buyer Outcome · Buyer · North Star

Integration 4 — Engagement orchestration: the automated re-activation motion when a team starts drifting at week 4-5

A workflow (Customer.io, Userlist, or n8n + Postmark) triggered by drop-offs in async-update volume or active-user count. It sends a sequenced, on-brand nudge to the champion ('your team's check-in rate dropped 40% — here's the one config change that fixes it') plus an in-product nudge to engineers. The VA monitors which sequences got opened/ignored from the cockpit.

Why this matters: This is literally the #1 ask in F3: 'an automated, on-brand re-activation motion I do not personally run.' The 5-6 week revert pattern in F2 is the exact moment this fires. Champions (F6) get the drift nudge they don't get today.

How they'll know it's real: At least 60% of accounts flagged 'Drifting' in the cockpit either re-engage or get a clean human decision within 10 days — automatically, without you authoring any of the touches.

Because you said: Catalyst · Buyer Outcome · Stakeholders

Integration 5 — Currency pipeline: the data plumbing that converts raw product events into the health states your cockpit and re-activation flow depend on

A scheduled job (a few SQL views + a Segment or RudderStack pipe, or even a daily Python script on cron) that turns 'standup posted', 'reactions', 'meeting-scheduled-in-Cadence' events into the Configured / Adopting / Drifting / At-Risk labels used everywhere else. No ML — just thresholds you, the engineer, can write in an afternoon.

Why this matters: F4 is explicit: no bespoke ML, must be wireable in an afternoon. F5 forbids piping customer Slack content without DPA — so this pipeline must run on your own product telemetry only, which is actually cleaner. Everything else is downstream of this; without it the cockpit and the re-activation flow have nothing to fire on.

How they'll know it's real: The state of every account updates daily on its own, and you can point to the exact SQL/threshold that produced each label.

Because you said: Buyer Outcome · Buyer · Constraints

Integration 6 — A library + change log: the single place your VA reads the playbooks and you log what changed

A Notion (or similar) workspace holding: the support agent's voice/tone doc, the re-activation sequence copy, the VA's daily checklist, and a dated changelog of every threshold or sequence you edit. Nothing fancy — just one source of truth instead of tribal knowledge in your head.

Why this matters: F6 says the VA needs an 'unambiguous daily checklist.' F4 says the system must survive you being heads-down for 3 weeks. Both fail if the playbook lives only in your head. The changelog is also what makes the 60-day NRR read in F3 honest — you can correlate retention changes to specific edits.

How they'll know it's real: The VA can run a full week without messaging you, and you can answer 'what did we change in the last 30 days?' from one page.

Because you said: Buyer Outcome · Buyer · Stakeholders

Integration 7 — Propagating what you learn: when one threshold or sequence proves out, it updates everywhere it's referenced

In your scale this is mostly a discipline, not software: when you change the 'Drifting' threshold in the SQL view, the cockpit label, the re-activation trigger, and the VA checklist all need to reflect it. Practically — one canonical config file (or one Notion page) that the script reads and the VA reads, so a single edit propagates.

Why this matters: F4 demands the system survive 3-week founder absences. The failure mode is the VA running last month's playbook against this month's thresholds. One canonical config is the cheapest insurance.

How they'll know it's real: You change a threshold in one place and within an hour the dashboard, the trigger, and the VA's checklist all show the new value — with no manual edits.

Because you said: Buyer · Stakeholders

Integration 8 — A simple map of outcome → tool → context: knowing which tool owns which signal

A one-page diagram: 'Reduce silent churn' → fed by the events pipeline → surfaced in the cockpit → acted on by the orchestration tool → answered by the support agent. Lists each tool, what data it sees, and which DPA covers it.

Why this matters: F5's hard limit is 'no customer Slack content into a tool without a signed DPA.' Without this map you will, under pressure, paste the wrong thing into the wrong tool. It also makes the angel-round conversation in F7 easier — you can show the architecture on one page.

How they'll know it's real: For any tool in the stack, you can name in 10 seconds what data flows in, what flows out, and which DPA governs it.

Because you said: Constraints · North Star

Integration 9 — Recommendation pipeline: the system suggesting which at-risk account the VA (or you) should touch next

A simple ranked list inside the cockpit — 'these 5 accounts are most worth a human touch this week, in order of MRR × drift severity.' No ML; it's a SQL ORDER BY. The VA works top-down through it.

Why this matters: F5 caps VA time at ~6 hrs/wk. Without prioritization, the VA will work alphabetically or by recency and waste hours on tiny accounts. Ranking by MRR × risk is how 6 hours protects the most revenue, which is the F7 NRR story.

How they'll know it's real: The VA finishes the week having touched the top of the list, not the bottom, and 80%+ of human-touch hours land on accounts that actually had revenue at stake.

Because you said: Constraints · Stakeholders · North Star

Integration 10 — The 'something is really wrong' alarm: a hard alert that bypasses the dashboard

An email/SMS to you when something exceeds a 'this is not normal' threshold — e.g. weekly logo churn rate ticks above 7%, or the events pipeline stops writing for 24 hours, or three top-decile-MRR accounts go At-Risk in the same week. Not noisy — only the things that genuinely need you, not the VA.

Why this matters: F4 says you'll go heads-down for 3 weeks at a time. The cockpit only helps if you look at it. F2's whole story is 'I didn't see it until it was too late' — the alarm is the safety net that lets you stop looking without going blind.

How they'll know it's real: In any 3-week product sprint, you receive 0–2 alerts, and every alert turns out to have been worth interrupting you for.

Because you said: Catalyst · Buyer

Integration 11 — Profit + stage view: cohort NRR, not vibes

A cohort retention table — teams grouped by signup month — showing logo retention, seat expansion, and net revenue retention over time. Updated weekly from the same events pipeline. This is the artifact you'd show an angel.

Why this matters: F3 asks explicitly for 'a 60-day read on net revenue retention by cohort, not vibes.' F7 makes NRR>115% the bedrock 5-year metric and references a 6-month angel round. This is the literal deliverable, not a nice-to-have.

How they'll know it's real: At day 60 you can show a cohort table where the post-rollout cohorts visibly retain better than the pre-rollout ones — or honestly admit they don't and know which lever to pull.

Because you said: Buyer Outcome · North Star

Integration 12 — Weekly cadence + Lock-and-Adjust: the rhythm that keeps the system honest

A fixed weekly loop: Monday VA runs the prioritized list; Friday you spend 30 min with the strategic-partner agent reviewing the cockpit and cohort table, and you either lock the current thresholds/sequences for another week or adjust exactly one of them and log it in the changelog.

Why this matters: F4's 6 hrs/wk and the 3-week-absence constraint only work if the rhythm is fixed and small. Lock-and-Adjust (changing one thing at a time and logging it) is what makes the 60-day cohort read in F3 interpretable instead of a soup of simultaneous changes.

How they'll know it's real: Every Friday ends with either a 'lock' or a single logged 'adjust', and you can read the changelog in 60 days and say which adjustment moved which cohort.

Because you said: Buyer Outcome · Buyer · Constraints

Integration 13 — A customer tribe surface (community/peer space)

N/A for you right now.

Why this matters: F4 says you are the only full-time person and F5 caps the team at you + a VA. F3 and F7 prioritize a private retention motion (cockpit + re-activation + cohort NRR), not a public community. Running a customer tribe well is a 1–2 person job in itself; doing it badly is worse than not doing it. Revisit at the 4-person-team stage in F7, not now.

How they'll know it's real: N/A — deliberately deferred.

Because you said: Buyer · Constraints · North Star

Turning your situation into the live data the system runs on

Your answers about Cadence (Slack-native async tool, 140 teams at ~$41k MRR, churn pattern of week-5 reversion, 6 hrs/wk founder ceiling, $800/mo tooling cap, no customer Slack content without DPA) are the live operating parameters every other loop reads from. When churn pattern, runway, or constraints change, this baseline gets refreshed — otherwise downstream loops drift from reality.

Why this matters: You're the only person who knows when reality moved (e.g. churn drops, VA quits, DPA gets signed). If this isn't refreshed deliberately, the rest of the system optimises against a stale picture of Cadence.

How they'll know it's real: A single short doc you re-read at the start of each month; if you can't answer 'has churn %, MRR, runway, or tooling ceiling moved?' in under 2 minutes, it's stale.

Because you said: Identity · Catalyst · Buyer · Constraints

How a disengagement signal becomes a specific re-activation action

When the silent-disengagement signal fires for an account (e.g. standup-post volume drops below baseline at week 4-5), the system generates a concrete recommended action — which champion to nudge, which message variant, whether to escalate. The VA executes from a queue; you don't author per-account responses. Recommendations come from a small fixed playbook, not bespoke ML.

Why this matters: Your catalyst is that you only see churn as a cancellation email. This loop is the entire point of the build — it converts the early signal into something the VA can act on without you on call.

How they'll know it's real: VA's daily queue has named accounts with a named action next to each; you can be heads-down on product for 3 weeks and the queue still clears.

Because you said: Catalyst · Buyer Outcome · Buyer · Stakeholders

Locking what works and adjusting what doesn't, on a fixed cadence

Every ~30 days you review which re-activation variants actually pulled accounts back into active use vs. which didn't, lock the winners into the VA's default script, and retire or adjust the losers. This is a 30-minute review, not an experiment program. The cohort NRR read is the scoreboard.

Why this matters: Without this, the playbook ossifies and the VA keeps running messages that stopped working. With it, you get the defensible NRR-by-cohort story you need for the angel round.

How they'll know it's real: A dated changelog of which re-activation variants are live; cohort NRR trend visible at 60 days.

Because you said: Buyer Outcome · North Star

Keeping the small tool stack healthy inside your $800/mo ceiling

The few tools you wire in (signal detection on Cadence's own usage data, a queue/CRM for the VA, a messaging tool for re-activation outreach) need a light monthly check: are they still under $800/mo combined, still DPA-compliant for any customer Slack content, still doing the job. Anything that creeps past the ceiling without showing NRR impact gets cut.

Why this matters: Your hard ceiling is $800/mo before NRR impact must be visible. Without an explicit check, SaaS sprawl quietly eats the budget and the constraint becomes invisible until renewal.

How they'll know it's real: A one-page tool ledger with cost, purpose, DPA status, and 'is it earning its keep?' checked monthly.

Because you said: Constraints · Buyer

N/A — buyer-surfaced research

This loop doesn't apply to you right now. You're a solo founder with a clear, narrow diagnosis (week-5 reversion to meetings) and a 6 hr/wk ceiling. Adding a research-intake loop would consume hours that need to go to product and the retention build itself. Revisit when you're past the 4-person team milestone.

Why this matters: Honest omission protects your 6 hr/wk ceiling.

Because you said: Buyer · Constraints · North Star

Keeping the re-activation playbook library current

The small library of re-activation message variants, signal thresholds, and VA checklist steps is maintained as a single living doc. New variants get added when the Lock+Adjust review surfaces them; dead ones get archived. You own writes; VA reads.

Why this matters: The VA needs an unambiguous source of truth (per F6). If the playbook lives in your head, the system collapses the moment you go heads-down for 3 weeks.

How they'll know it's real: VA can answer 'what's the current week-5 nudge?' by opening one doc, not by Slacking you.

Because you said: Stakeholders · Buyer

Making sure changes you make actually reach the VA's daily work

When you change a threshold, a message variant, or a checklist step, that change has to land in the VA's actual daily queue — not just in the playbook doc. A short propagation step (update the doc, update the queue template, ping the VA once) is part of every change.

Why this matters: You're the only person who can change anything (F4), and the VA is the only one who runs it. A change that doesn't propagate is worse than no change — it creates silent divergence between intent and execution.

How they'll know it's real: VA's queue reflects the new variant within one working day of you changing it.

Because you said: Buyer · Stakeholders

Keeping the re-activation messages sounding like Cadence, not like a CRM

Cadence's whole identity is opinionated async — actively discouraging meetings. Re-activation messages have to carry that voice, not generic 'we miss you' SaaS tone. A short voice check (you, 10 min, once a month) on the live variants keeps the VA's outbound from drifting into bland reactivation-spam.

Why this matters: The product's defensibility is its opinion. If the re-activation motion sounds like every other tool, you've automated the wrong thing and accelerated churn.

How they'll know it's real: You'd send any of the current live variants from your own account without wincing.

Because you said: Identity · Buyer Outcome

What happens when the signal fires loud — accounts about to cancel

A separate, higher-priority lane: when an account crosses from 'disengaging' to 'imminent cancel' (e.g. week 6+, near-zero activity, billing event approaching), the VA escalates with a different script and flags it for your eyes if it's a top-revenue account. Everything below that threshold stays in the standard queue.

Why this matters: Your catalyst is that today you only see churn at cancellation. This loop is what guarantees you see at-risk revenue *before* the email, with a clear rule for when you personally need to look.

How they'll know it's real: Zero cancellations in the next quarter that the VA didn't flag as at-risk at least 2 weeks prior.

Because you said: Catalyst · Buyer · Stakeholders

Reading NRR by cohort on a fixed rhythm, not by vibes

Every 30 days: cohort NRR snapshot (signup month → current MRR retained). Every 90 days: the readout that informs whether to keep, adjust, or rebuild the retention motion. This is the scoreboard for the whole system and the artifact for the angel conversation.

Why this matters: F3 explicitly asks for a 60-day cohort NRR read, and F7's bedrock is NRR-driven compounding. Without a fixed cadence, this slips and you're back to vibes.

How they'll know it's real: A dated NRR-by-cohort chart exists at day 60 and updates monthly thereafter.

Because you said: Buyer Outcome · North Star

N/A — tribe digest

This loop doesn't apply at your scale. Your 'tribe' is you and one VA. A formal digest would be overhead, not signal. The Lock+Adjust review and the NRR readout already cover everything a digest would surface. Revisit when the team is 3+.

Why this matters: Honest omission — protects the 6 hr/wk ceiling.

Because you said: Buyer · Constraints

Moving changes from 'I'm trying this' to 'this is how Cadence runs'

When a new signal threshold, message variant, or VA checklist step has passed one Lock+Adjust review with positive NRR signal, it graduates from 'experimental' to 'default'. Defaults are what the VA runs when you're heads-down. Experiments require your active attention; defaults don't.

Why this matters: You will be heads-down on product for 3 weeks at a stretch (F4). The system has to know what's safe to run unattended vs. what isn't, or every founder absence becomes a risk window.

How they'll know it's real: Playbook doc clearly marks each item as 'default' or 'experimental'; VA only runs defaults when you're unavailable.

Because you said: Buyer · Stakeholders · Buyer Outcome

Where you stand

You have ~140 paying teams at $34/seat producing ~$41k MRR, run entirely by you. Logo churn has more than doubled — from 3.1% to 6.8% per month over two quarters — and the failure pattern is consistent: teams sign up, the champion configures Cadence, and around week 5–6 the team quietly reverts to meetings and the account goes silent before cancelling. You only see it when the cancellation email arrives. You have roughly two quarters of runway before this compounds past recoverable.

Why this matters: Naming the actual numbers — 6.8%, week 5–6, two quarters — is what separates a fixable problem from a vague anxiety. Every decision below is sized against these.

How they'll know it's real: Cancellation emails arriving with no prior support ticket from that account.

Because you said: Identity · Catalyst

What your system is, in one paragraph

Cadence is becoming a retention engine: a small set of wired-together tools that watch each team's async usage, flag silent disengagement around week 4–5, and trigger an on-brand re-activation motion the VA executes from a daily checklist — so churn is caught before it becomes a cancellation, and you stay on product.

Why this matters: This is the sentence you repeat verbatim to an advisor, an angel, or yourself at 11pm. If you can't say it in one breath, the design is still too complicated for a one-person company.

How they'll know it's real: You can say it without looking it up, and the VA can recognize their part in it.

Because you said: Identity · Buyer Outcome · North Star

What's working / what's drifting / what needs you

Working: you have a real, opinionated product with 140 paying teams and a clear wedge (async-by-default, anti-meeting) that competitors don't occupy. You can change anything unilaterally. Drifting: post-configuration adoption decays silently from roughly week 5; champions get no signal; end-user engineers stop feeling value; support is 100% reactive. Needs you: defining the disengagement signal, choosing the 2–3 AI capabilities, and standing up the VA's daily checklist — after that, the system runs without you for three-week heads-down stretches.

Why this matters: Three honest lists keep you from over-investing in what already works and from under-investing in the silent-churn gap that's actually eating you.

How they'll know it's real: After setup, you can disappear into product for 3 weeks and NRR-by-cohort still gets reported.

Because you said: Identity · Catalyst · Buyer · Stakeholders

The load-bearing capability

Early silent-disengagement detection at the team level. If the signal — whatever combination of standup completion rate, response latency, and active-user decay you settle on — fails to fire before week 5, every other piece (re-activation motion, VA checklist, NRR cohort read, angel story) collapses, because you're back to learning about churn from cancellation emails. This is the single capability that, if it erodes, the whole design fails.

Why this matters: Your north star is retention-driven compounding to >115% NRR. That compounding is impossible if churn is only visible after it's already happened. Detection is the upstream of everything.

How they'll know it's real: At least 70% of eventual churners are flagged by the signal at least 2 weeks before they cancel.

Because you said: Catalyst · Buyer Outcome · North Star

The 60–90 day proof

By day 60 you have a net revenue retention read by signup cohort — not a gut feel, an actual number per cohort. By day 90 you can show: logo churn trending back toward 3–4% (from 6.8%), the disengagement signal firing on at-risk accounts before week 5, the VA executing the re-activation motion from a daily checklist without you, your weekly time on this under 4 hours, and tooling cost under the $800/mo ceiling. If those five lines are true, it's working. If any one is false, it isn't.

Why this matters: These are your own success terms from F3 and F5. Anything else is vibes, and vibes won't survive a 3-week product sprint or an angel conversation.

How they'll know it's real: A one-page cohort NRR table you can pull up on demand.

Because you said: Buyer Outcome · Constraints · Catalyst

The one risk that kills this

The risk: the disengagement signal turns out to require piping customer Slack content into a third-party tool you don't have a DPA with, or it adds onboarding friction, or it ends up needing you on call to interpret edge cases. Any one of those violates your hard limits and the whole architecture has to be re-grounded. Mitigation: before wiring anything, confirm the signal can be computed from Cadence's own usage metadata (completion rates, latency, active-user counts) — not message content — and that the VA's playbook for each signal type is unambiguous enough to run while you're heads-down for three weeks.

Why this matters: Your hard limits in F5 are not preferences; violating them either breaks customer trust or pulls you off product, and either one ends the company before the angel round.

How they'll know it's real: The signal spec fits on one page and references zero customer message bodies.

Because you said: Constraints · Buyer · Stakeholders

What you show the board

Sentence one: "Cadence has 140 paying teams and ~$41k MRR, but logo churn doubled to 6.8% because we were learning about disengagement only at cancellation." Sentence two: "We've installed a detection-and-reactivation layer that flags at-risk teams by week 4–5 and runs an on-brand recovery motion via a VA on a daily checklist, with me under 4 hours a week on it." Sentence three: "The 60-day cohort NRR read is how we'll know it worked, and it's the foundation of the >115% NRR story we're raising against."

Why this matters: Your F6 stake is a defensible NRR story for an angel round in ~6 months. These three sentences are that story, grounded in what you actually built.

How they'll know it's real: An angel asks a follow-up about the cohort table, not about whether the problem is real.

Because you said: Stakeholders · North Star · Catalyst · Buyer Outcome

Week 1 — Pipe per-team usage events into a warehouse you control

WHY: Outcome #1 (early silent-disengagement signal) and outcome #4 (NRR read by cohort) both require per-team event data outside Cadence's app DB so the VA and downstream tools can query it without you. WHERE: Cadence backend → a managed warehouse (BigQuery or Postgres on Neon/Supabase — pick the one you already have credentials for). WHAT: 1) List the 6–8 events that signal real async use (standup posted, update read, reaction, thread reply, config change, channel added, invite accepted, login). 2) Add a single emit() call on each, writing team_id, user_id, event_type, ts. 3) Backfill 90 days from your app DB. 4) Build one view: team_id, week, events_total, active_users, posts_per_active_user. GOTCHAS: Do NOT pipe Slack message content — only metadata/counts. Without that line you'll trip your own DPA limit (F5). Recovery: if you catch content fields, drop the column and re-run the backfill. VERIFICATION: You can run one SQL query that returns weekly events for all ~140 teams, and the row count for last week matches a spot-check of 3 known-active teams.

Why this matters: Every later step (health score, VA checklist, NRR cohort view) reads from this table. If it isn't right in week 1, weeks 2–4 collapse.

How they'll know it's real: One query returns a weekly per-team usage table covering all paying teams, with zero message-content columns.

Because you said: Identity · Buyer Outcome · Buyer · Constraints

Week 1 — Define the "week-5 revert" signal in plain rules, not ML

WHY: Your churn pattern is specifically the 5–6 week revert (F2), and you've refused bespoke ML (F4). A rules-based signal you can read in SQL is the only thing that fits both. WHERE: Same warehouse view from the previous step. WHAT: 1) Write the disengagement rule as SQL: a team is "drifting" if posts_per_active_user drops >40% vs its own weeks 2–3 baseline, OR active_users drops >30%, sustained 7 days. 2) Add a "champion silent" rule: the configuring admin hasn't posted in 10 days. 3) Materialize a team_health table: team_id, state ∈ {healthy, drifting, silent, reverted}, reason, since_date. GOTCHAS: New signups will false-positive because they have no baseline. Recovery: exclude teams <21 days old from the drifting state; mark them "onboarding" instead. VERIFICATION: Run the rule against the last 2 quarters of data and confirm it would have flagged ≥70% of the teams that actually churned at least 14 days before they cancelled.

Why this matters: This is the "capability" in your capability architecture — the signal itself, owned by you, not rented from a vendor.

How they'll know it's real: Backtest shows the rule catches most past churns with ≥2 weeks of lead time.

Because you said: Catalyst · Buyer Outcome · Buyer

Week 2 — Stand up the re-activation message system with a DPA-clean vendor

WHY: Outcome #1 requires an automated, on-brand re-activation motion you don't personally run. You need a sending tool that can be triggered by warehouse state and signs a DPA. WHERE: Customer.io, Loops, or Resend+a thin worker — whichever you can sign a DPA with inside the week and stays under ~$200/mo at your volume. WHAT: 1) Sign DPA before importing any contact data. 2) Sync team_health table → vendor via reverse-ETL (Hightouch free tier) or a 30-line cron job. 3) Draft 3 messages in your async-by-default voice: drift nudge to champion, end-user "here's what your team is missing" digest, silent-champion re-engagement. 4) Wire one trigger: state becomes "drifting" → send champion nudge, 72h later send end-user digest if no state change. GOTCHAS: Generic SaaS "we miss you" copy will undermine the brand (F1 — you're the anti-meeting tool). Recovery: every message must name the specific behavior that dropped and propose an async fix, not ask them to "log back in". VERIFICATION: Trigger the flow against a test team you control; both messages arrive, copy reads like Cadence not like Mailchimp, and the team's state in the warehouse updates after the test event.

Why this matters: This is the motion that has to run while you're heads-down on product for 3 weeks (F4). It must work untouched.

How they'll know it's real: A state change in the warehouse produces the correct message sequence end-to-end without you touching anything.

Because you said: Identity · Buyer Outcome · Buyer · Constraints · Stakeholders

Week 2 — Run the first re-activation cycle on currently-drifting teams (workflow #1)

WHY: You have ~140 teams and elevated churn right now (F2) — week 2 is the first moment the foundation can pay rent. WHERE: Live, against real drifting teams flagged by the rule from week 1. WHAT: 1) Pull the current drifting list (expect 10–25 teams given 6.8% churn). 2) Spot-check 5 of them manually against the app to confirm the rule isn't lying. 3) Enable the trigger. 4) Log every send and every reply in a single sheet the VA can see. GOTCHAS: A flood of replies will land on you, not the VA yet. Recovery: cap the first batch at 10 teams; expand only after week 3 once the VA owns it. VERIFICATION: Within 7 days, at least one drifting team's state returns to "healthy" without you personally intervening — proof the motion works, not just sends.

Why this matters: This is the first real test that the foundation works in your actual business, not in theory.

How they'll know it's real: ≥1 drifting team self-recovers from the automated sequence inside 7 days.

Because you said: Catalyst · Buyer Outcome · Buyer

Week 3 — Hire and onboard the VA against a written daily checklist

WHY: Outcome #2 explicitly requires the 2–3 capabilities be operable by a non-engineer VA, and F6 says the VA needs an unambiguous daily checklist. WHERE: Async hire (OnlineJobs.ph or a referral) at $25/hr, ~6 hrs/wk. WHAT: 1) Write a 1-page daily checklist: open the team_health dashboard, review teams that changed state in last 24h, hand-personalize the nudge for any account >$200 MRR, mark replies in the sheet, escalate to you only if state = "reverted" AND MRR >$500. 2) Write a 1-page weekly checklist: cohort NRR refresh, top-10 risk list, message-performance review. 3) Run 2 paired sessions over Loom + shared screen. 4) Give read-only warehouse access and send-only access to the email tool — no admin. GOTCHAS: VA will try to ask you questions in real time. Recovery: route all VA questions to one async channel with a 24h SLA from you, never DM. VERIFICATION: VA completes 3 consecutive days of the checklist solo, and you can read the log without correcting anything.

Why this matters: Without this, the whole system collapses to you the moment you go heads-down on product.

How they'll know it's real: Three consecutive solo VA days with a clean log.

Because you said: Buyer Outcome · Buyer · Constraints · Stakeholders

Week 3 — Build the cohort NRR view and run workflow #2 (weekly retention read)

WHY: Outcome #4 demands a 60-day NRR read by cohort, not vibes, and F7's bedrock is NRR-driven compounding. WHERE: Same warehouse, one new view + one Metabase/Hex/Preset dashboard (free or <$50/mo tier). WHAT: 1) Build cohort table: signup_month, teams_started, teams_active_now, MRR_started, MRR_now, expansion_MRR, contraction_MRR. 2) Compute NRR per cohort. 3) Build one dashboard with 3 charts: NRR by cohort, logo churn by week-since-signup, drift→recovery rate. 4) Run the first weekly review with the VA; you skim, they prep. GOTCHAS: Early cohorts will look distorted because of the prior 6.8% churn spike. Recovery: annotate the dashboard so the angel-round narrative (F6) is honest — pre-system vs post-system cohorts. VERIFICATION: You can answer "what's NRR for teams that signed up in month X" in <60 seconds from the dashboard.

Why this matters: This is the defensible NRR story for the angel round (F6) and the truth source for whether the whole effort is working.

How they'll know it's real: Dashboard loads, numbers reconcile to Stripe ±2%, and the week-5 revert is visibly shrinking in newer cohorts (or you know it isn't).

Because you said: Buyer Outcome · Stakeholders · North Star

Week 3 — Re-open any rule or message that didn't match what you saw in week 2

WHY: Week 2's live run will have exposed at least one place where the drift rule or the message copy didn't match how Cadence teams actually behave — fixing it now, before handoff to the VA hardens, is much cheaper than fixing it in month 2. WHERE: The team_health rule (week 1) and the three message drafts (week 2). WHAT: 1) Pull the week-2 send log. 2) For every false positive (team flagged drifting but actually fine) and every non-response from a real drifter, write one line: what the rule missed or what the message missed. 3) Pick the top 2 issues only and change them — tighten the threshold, rewrite the message, or add an exclusion. 4) Re-backtest the rule against the 2-quarter history. GOTCHAS: The temptation is to rewrite everything. Recovery: cap changes at 2 this week; everything else goes on a list for the Week 4 quarterly checkpoint. VERIFICATION: Backtest still catches ≥70% of past churns AND the live false-positive rate from week 2 drops by at least half on the next batch.

Why this matters: The methodology only works if you rebuild what reality contradicted; skipping this bakes in errors the VA will then execute faithfully for months.

How they'll know it's real: Updated rule + updated copy, backtest holds, and the change log is one short paragraph — not a rewrite.

Because you said: Catalyst · Buyer Outcome · Buyer

Week 4 — Lock the weekly cadence: VA daily, you 90 minutes Friday

WHY: Outcome #3 caps your time at <4 hrs/wk, F4 caps it at 6, and the system must survive 3-week heads-down stretches. A fixed cadence is what makes that real. WHERE: Calendar + the shared ops doc. WHAT: 1) VA: daily checklist 45–60 min, weekday mornings. 2) You: Friday 90 min — skim the week's dashboard, read the VA's exception log, approve any message copy changes, decide nothing else. 3) Block the Friday slot recurring; mark it non-negotiable. 4) Define the "heads-down mode" variant: VA continues daily; your Friday slot drops to 30 min reading the exception log only. GOTCHAS: You will try to do support work in the Friday slot. Recovery: support email auto-replies route to the VA; you only see escalations matching the rubric. VERIFICATION: Two consecutive Fridays where you spend ≤90 min and the dashboard shows the system kept running.

Why this matters: This is the only mechanism that gets you from founder-does-everything (F4) toward the 4-person team where you're on product (F7).

How they'll know it's real: Two clean Friday cycles inside the time cap.

Because you said: Buyer Outcome · Buyer · Constraints · North Star

Week 4 — Activate the escalation rubric so the VA decides, not you

WHY: F4 says nothing can require you on call; F6 says the VA needs unambiguous rules. Without a written rubric every edge case becomes a Slack DM to you. WHERE: One page at the top of the VA's ops doc. WHAT: 1) Write 4 decision rules: (a) team reverts AND MRR >$500 → escalate to founder same day; (b) team reverts AND MRR ≤$500 → VA sends save-offer template, log result; (c) message copy gets 2+ negative replies in a week → pause that message, flag for Friday review; (d) any DPA/security question from a customer → escalate to founder, do not respond. 2) Walk through 5 historical cases with the VA and have them apply the rubric. 3) Anything not covered defaults to "wait until Friday". GOTCHAS: VA will over-escalate at first out of caution. Recovery: in week 1 of running it, every escalation you receive that wasn't rubric-warranted, you reply with the rule number, not the answer. VERIFICATION: One full week passes where every VA decision maps to a numbered rule, and your escalation count is ≤2.

Why this matters: The rubric is what makes the VA an operator, not a question-asker — the condition for you going heads-down for 3 weeks.

How they'll know it's real: ≤2 escalations/week, all rubric-mapped.

Because you said: Buyer · Constraints · Stakeholders

Week 4 — Schedule the day-90 checkpoint with the NRR-by-cohort question pre-loaded

WHY: Outcome #4 is a 60-day NRR read by cohort, and F7 ties the whole 5-year plan to NRR >115%. The checkpoint is what converts "we built it" into "we know if it worked". WHERE: Calendar invite to yourself, day 90 from today, 2 hours blocked. WHAT: 1) Pre-write the 4 questions the checkpoint must answer: Is logo churn back below 4%? Is NRR on post-system cohorts trending toward 115%? What % of drifting teams self-recover from the automation? Is your time actually ≤4 hrs/wk? 2) Build a one-page template the VA fills in the week before. 3) Decide in advance the two branches: if NRR is improving → start drafting the angel-round narrative; if not → the checkpoint becomes a rebuild session on the drift rule and message system, not a new initiative. GOTCHAS: You'll be tempted to skip it because product work feels more urgent. Recovery: the calendar block is the same Friday slot, just doubled — you're not adding time, you're using existing time. VERIFICATION: Invite exists, template exists, and the VA has it on their weekly checklist to refresh the inputs starting day 75.

Why this matters: Without a scheduled honest re-read, you'll discover in month 5 that the numbers drifted — by which point F2's runway warning is back.

How they'll know it's real: Day-90 calendar block + filled template waiting for you.

Because you said: Catalyst · Buyer Outcome · Stakeholders · North Star