Hank watches your customers.
Hank is customer success. Every morning he compares each customer's recent product activity against their own baseline, and flags the ones whose usage has fallen off a cliff. Each flag carries the numbers behind it, and Hank says plainly whether he thinks it's real or noise. For the paying ones he drafts the check-in email; you decide whether it sends. Honest framing, never alarmist.
What Hank does.
The half of customer success that gets skipped at micro-SaaS scale is noticing. A customer who is going to cancel in March usually stops using the product in January, and the founder finds out from the Stripe email. Nobody skips it on purpose. It's just that noticing requires looking at every customer every day, which is exactly the kind of work a person cannot do and a schedule can.
So that's what Hank does. Once a day he scans your customers, comparing each one's activity over the last week against their own two-week baseline. A customer whose usage has dropped by half or more gets flagged — and it's their own baseline, not an average across your book, so a customer who was always quiet doesn't get flagged for staying that way.
Then he does the part that makes the flag worth reading. For each flagged customer he weighs what he knows — how long they've been with you, what they pay, whether he already drafted you a note about them recently — and tells you whether this looks like a real problem or a quiet fortnight. He won't re-flag the same customer inside a week, and he caps how many he raises in a single run, because a list of five customers is one you act on and a list of fifty is one you close.
Hank doesn't predict churn. He names what's changed and lets you decide whether to reach out. The save play is yours. Hank's job is to make sure no customer goes quiet without you noticing.
What sets it off, what it reads, what it writes.
- Triggers
- The daily 9am scan, in your workspace's timezone
- Manual /run from the founder
- Inputs
- Product activity per customer, recent window against their own baseline
- Customer-graph history (tenure, MRR, lifecycle stage)
- When Hank last flagged this customer, and last drafted about them
- Founder voice samples
- Outputs
- Quiet-customer flag with the activity numbers behind it
- Hank's read on whether the flag is real or noise
- Drafted check-in email, held for approval
- Audit trail entry
The playbook in plain English.
The scan. At 9am in your timezone, Hank walks your customers and compares each one's product activity over the last week against their own two-week baseline. A drop of half or more puts them on the list. Customers too new to have a baseline are left alone, because there's nothing to compare them against yet.
The read. A flag on its own is just a number going down, so Hank takes a second pass over each one. He weighs tenure, what they pay, and whether he's already raised this customer with you recently, then says whether he thinks it's genuine or noise. That judgement is the product. The scan is cheap; knowing which four of the eleven matter is the part that saves you an afternoon.
The draft. Here the funnel narrows, and it is worth being exact about where. Every genuine flag reaches your digest, whoever it is about. Only paying and expanding customers get a drafted check-in: "noticed things have been quiet — anything blocking you we can help with?" A trial user who goes quiet is still surfaced to you; Hank just doesn't write to them. The draft lands in your approval queue, and Hank has no ability to send it — the send permission is absent from the playbook, not defaulted to off.
The restraint. Hank won't raise the same customer twice inside a week, and he caps the flags per run. Both exist for the same reason: a customer-success list you learn to ignore is worse than no list, because it costs you the same attention and returns nothing.
Over time the audit log tells you which of Hank's flags were saves and which were customers who were just busy. Your edits to his drafts feed back into what he writes next, through the same suggestion-then-rule loop described on Inky's page.
The guardrails are yours.
- Turn Hank off — the per-agent switch is real and enforced. A disabled agent refuses at dispatch.
- What Hank may touch — the permissions on the installation are read on every run. Absent by design: no send permission, so no setting can make a check-in leave without you.
- Quiet threshold (designed, not yet wired) — how far activity has to fall before Hank raises it.
- Cooldown (designed, not yet wired) — how long before the same customer can be raised again.
- Minimum customer age (designed, not yet wired) — how much history a customer needs before Hank judges them.
- Excluded segments (designed, not yet wired) — which segments are held back from the check-in drafts.
- Flag cap (designed, not yet wired) — the most customers Hank raises in one run.
- Tone (designed, not yet wired) — observant, concerned, or informational.
Nothing here yet.
We're pre-launch, so there is nothing to put here. Customer quotes go up as design partners come online and consent to being named.
Hank on customers.
Hank is the customer success agent. He watches for the activity drop that comes before a cancellation, says whether he thinks it's real, and drafts the check-in for the paying customers among them. Trial activation is not his beat: he'll surface a trial user who goes quiet, but he won't write to them. Lou handles the billing layer; Frankie handles the inbox. Hank handles the relationship between.
Read the customers pillar →Common questions about Hank.
Does Hank predict churn?
No. Hank surfaces one signal — product activity falling away from a customer's own baseline — and says whether he thinks it's real. You decide whether that's a churn risk. Predicting churn is a different problem; surfacing the signal is achievable, useful, and honest.
Does Hank onboard trial users?
No. There's no day-1 / day-7 / day-14 nudge sequence — not switched off, not built. His scan does cover trial users and will surface one who goes quiet, but the check-in drafts are limited to paying and expanding customers, so he won't write to them. Trial activation is a real gap and we'd rather name it than describe a cadence you'd go looking for and not find.
How does Hank decide someone has gone quiet?
He compares a customer's recent activity against their own baseline over a longer window, and raises them when it's fallen by half or more. Comparing a customer to themselves is the point: a low-volume customer who is behaving normally never gets raised, and a heavy user who halves their usage does, even though they're still using the product more than the first one.
What can't Hank see?
Anything that isn't product activity. He doesn't read login frequency separately, doesn't watch your support-ticket volume for a spike, and doesn't factor in sentiment from what a customer wrote to you. If a customer is unhappy but still using the product, Hank won't catch it — that one reaches you through Frankie's inbox instead.
How do you avoid alarming false positives?
Conservative thresholds, a cap on how many he raises per run (default 5), a cooldown that stops him raising the same customer twice in a week, and the segments you've excluded. There's no per-customer suppression list yet, so silencing one account means silencing its segment. We have no false-positive rate to quote — the flags have to run against real customers first.
What's the followup tone?
Genuinely curious, never sales-y. The default draft is "noticed you've been quiet — anything blocking you we can help with?" — short, no pressure, no "upgrade" pitch. The founder edits if needed; the tone should feel like a friend checking in.
Closing
Hank names what's slipping. The save play is yours. — A cofounder
PorchOps puts a crew of AI coworkers on your back office: recovering failed payments, sorting support, keeping the books. Everything they write waits for your approval.