What is a churn predictor?

A small serverless system that spots customers who are quietly drifting away before they leave. It watches simple signals you already have — last order date, support mood, login gaps — scores who looks at-risk using plain, explainable rules, and gives the owner a short weekly 'reach out to these five' list with the reason for each. A human does the reaching out; the system only flags and explains. It never messages customers on its own.

How much does it cost to run?

About $2/month at typical small-business volume (around 500 customers). The fixed cost is essentially zero. The variable cost is dominated by the weekly Lambda run that scores every customer; Bedrock fires only on the support-email mood lane and the weekly reason write-up, so they're small slivers. At 5,000 customers the bill lands around $9.

Which AWS services does it use?

Lambda (Python 3.14, arm64) with a Function URL for the outcome buttons, EventBridge Scheduler for the weekly run and the hourly imports, DynamoDB on-demand, S3 (with versioning), SES inbound + outbound, Secrets Manager, CloudWatch Logs (7-day retention), AWS Budgets, and Bedrock (Claude Haiku 4.5 via Global cross-Region inference) for reading support-email mood and writing the weekly plain-English reason. No API Gateway, no NAT Gateway, no always-on compute, no Knowledge Base.

Where does the customer list live?

In a Google Sheet in a Drive folder you control. One row per customer with name, owner email, last order date, order count, support mood, last login date, plan, and monthly value. A small drive-sync Lambda mirrors the sheet to S3 every 15 minutes; the predictor reads from S3 to keep Drive API calls predictable and to get S3 versioning for free.

No, and that's the point. The score is a plain weighted sum of a few signals, all spelled out in the rules doc — days since last order, drop in order pace, sour support mood, login gap. Every at-risk flag ships with the exact reason that tripped it, in plain words, so the owner can judge it. No hidden model decides who's churning; a human reads the reason and decides whether to act.

Does it message customers automatically?

Never. The predictor only flags and explains. It produces a short weekly list for the owner — 'reach out to these five, here's why each one' — and a human decides who to contact and what to say. There is no auto-send to customers anywhere in the system. That keeps the risky part (talking to a wavering customer) in human hands.

What happens after the owner reaches out?

The weekly list has three buttons per customer: Reached out (logs the contact and pauses re-flagging for two weeks), Won back (marks the save and resets the customer to steady), and Lost (records the churn with a reason for the monthly review). Every action is written to the cp-audit DynamoDB table with timestamp, customer, action, by-user, and a snapshot, so the win-back trail is auditable and the monthly summary can report saves and losses.

Series · 7 parts Published May 28, 2026

Churn predictor

A serverless predictor that spots customers who are quietly drifting away before they leave. It watches simple signals you already have — last order, support mood, login gaps — scores who looks at-risk with plain, explainable rules, and hands the owner a short weekly “reach out to these five” list with the reason for each. A human wins them back; the system only flags and explains, and never messages customers on its own. Seven posts on the same system — one diagram at a time — with an engineering reference at the end.

01

A churn predictor on AWS for a few dollars a month

The whole system on one page — a signals intake, a scorer, and a hand-off piece, plus the four outcomes they share for every customer.
02

How an at-risk customer gets watched

Three lanes feed the customer list — the Drive sheet itself, an order-feed import that updates last order and pace, and a support-inbox lane that reads each ticket’s mood into a simple score.
03

How a churn score gets calculated

A weekly run reads the list, turns each signal into points using weights in the rules doc, adds them up, and picks one of four bands: steady, watch, at-risk, churning. No black box — plain arithmetic.
04

How an at-risk list reaches the owner

Owner lookup per customer, a cap of five names a week, a plain reason per name, Slack or email delivery, and the four guardrails between the score and the actual list landing.
05

How a win-back gets tracked

Three actions on each name: reached out (log and pause re-flagging), won back (save and reset to steady), and lost (record the churn with a reason). Every action is logged.
06

What the churn predictor costs

A couple of dollars a month at SMB volume. The scorer runs once a week, calls no model on the hot path, and only fires Bedrock on the support-mood lane and the weekly reason write-up.
07

Engineering reference: the churn predictor architecture

Same system, drawn purely for engineers. Service names, resource identifiers, region, Bedrock model IDs, Lambda inventory, IAM scopes, the SES inbound rule set, EventBridge Scheduler config, and the DynamoDB schemas.

What is a churn predictor?: A small serverless system that spots customers who are quietly drifting away before they leave. It watches simple signals you already have — last order date, support mood, login gaps — scores who looks at-risk using plain, explainable rules, and gives the owner a short weekly “reach out to these five” list with the reason for each. A human does the reaching out; the system only flags and explains, and never messages customers on its own.
How much does it cost to run?: About $2/month at typical small-business volume (around 500 customers). The fixed cost is essentially zero. The variable cost is dominated by the weekly Lambda run that scores every customer; Bedrock fires only on the support-email mood lane and the weekly reason write-up, so they’re small slivers. At 5,000 customers the bill lands around $9.
Which AWS services does it use?: Lambda (Python 3.14, arm64) with a Function URL for the outcome buttons, EventBridge Scheduler for the weekly run and hourly imports, DynamoDB on-demand, S3 (with versioning), SES inbound + outbound, Secrets Manager, CloudWatch Logs (7-day retention), AWS Budgets, and Bedrock (Claude Haiku 4.5 via Global cross-Region inference) for reading support-email mood and writing the weekly reason. No API Gateway, no NAT Gateway, no always-on compute, no Knowledge Base.
Where does the customer list live?: In a Google Sheet in a Drive folder. One row per customer with name, owner email, last order date, order count, support mood, last login date, plan, and monthly value. A small drive-sync Lambda mirrors the sheet to S3 every 15 minutes; the predictor reads from S3 to keep Drive API calls predictable and to get S3 versioning for free.
Is it a black box?: No, and that’s the point. The score is a plain weighted sum of a few signals, all spelled out in the rules doc — days since last order, drop in order pace, sour support mood, login gap. Every at-risk flag ships with the exact reason that tripped it, in plain words, so the owner can judge it. No hidden model decides who’s churning; a human reads the reason and decides whether to act.
Does it message customers automatically?: Never. The predictor only flags and explains. It produces a short weekly list for the owner — “reach out to these five, here’s why each one” — and a human decides who to contact and what to say. There is no auto-send to customers anywhere in the system. That keeps the risky part — talking to a wavering customer — in human hands.
What happens after the owner reaches out?: The weekly list has three buttons per customer: Reached out logs the contact and pauses re-flagging for two weeks. Won back marks the save and resets the customer to steady. Lost records the churn with a reason for the monthly review. Every action is recorded in the cp-audit DynamoDB table with timestamp, customer, action, by-user, and a snapshot, so the win-back trail is auditable.

All posts

Frequently asked questions

Other series