Churn Risk Early Warning

Cancellations arrive as a surprise and almost never are one. The email that lands on the first of the month, asking to wind things down, is the final step in a sequence that began eight to twelve weeks earlier: a report that went unopened, a review call quietly declined, a staff member who stopped logging in, a reply that got shorter, a question about the invoice. Every one of those signals existed in the agency's own systems. None of them was watched, because watching them was nobody's job and because each one in isolation looks like nothing.

The practical failure is that agencies monitor delivery, not engagement. There are dashboards for leads, bookings and spend, and nothing at all for whether the client is still showing up to the relationship. Account managers do carry an instinct for which clients feel wobbly, but that instinct is uneven, unrecorded, and lost whenever someone leaves or takes on too many accounts. The clients most at risk are often the quiet ones - no complaints, no escalations, no contact - and quiet reads as fine right up to the cancellation.

The cost is the most expensive kind. A retainer lost at month five has consumed the full acquisition cost and the whole of provisioning and onboarding, and returned a fraction of the revenue that justified them. Worse, the intervention that would have saved it was usually small and cheap - a call, a format change, an explanation - and was available for weeks. Intervening after the cancellation email is a different and much harder conversation, because the client has already made the decision and is now defending it. The leak is not the churn itself; it is the weeks of free warning the agency throws away.

Retention pipeline and stages

A pipeline named Client Retention in the agency workspace. Unlike the other builds, an opportunity here is created only when risk is detected, not for every client. A thin pipeline is the point: if everything is in it, nothing is flagged.

• Watchlist - score has crossed the first threshold. Monitoring only, no client contact yet.
• Risk Confirmed - a human has looked at the signals and agrees this is real.
• Diagnosis Call Booked - a conversation is scheduled to find out what is actually wrong.
• Root Cause Identified - the reason is recorded in one of a fixed set of categories.
• Intervention In Flight - an agreed plan with a named owner and a review date.
• Recovering - score improving, intervention working, still watched.
• Recovered - score back under threshold for two consecutive cycles.
• Cancellation Requested - the client has asked to stop. Handled as a defined process, not improvised.
• Saved at Cancellation - client asked to stop and stayed.
• Churned - lost, with an exit interview and a recorded reason.

Calendars

• Diagnosis Call - 30 minutes with the account manager, offered as soon as risk is confirmed. Framed as a check-in, never as a retention call.
• Principal Escalation Call - 45 minutes with the agency principal, reserved for high-risk accounts and for anything that reaches Cancellation Requested. A different person in the room changes the conversation.
• Intervention Review - 30 minutes, scheduled at the point the plan is agreed so there is a date in the calendar rather than a vague intention.
• Exit Interview - 30 minutes, offered to every churned client. The most useful half hour the agency will have all quarter, and the one most often skipped.

Custom fields

The signal fields are written by workflows and by the reporting and onboarding builds. The judgment fields are written only by humans.

• churn_risk_score - numeric, 0 to 100, recomputed weekly.
• churn_risk_band - Green, Amber, Red or Critical.
• churn_risk_score_prior, churn_risk_trend - Improving, Flat or Worsening. Trend matters more than level.
• churn_risk_drivers - long text, the named signals contributing to the current score.
• Engagement signals: reporting_consecutive_unopened, days_since_client_reply, days_since_portal_login, portal_active_users_30d, review_calls_declined_consecutive, meetings_no_show_90d, inbound_message_sentiment_30d.
• Delivery signals: variance_flag, consecutive_down_months, kpi_primary_vs_target_pct, goal_met_last_cycle.
• Commercial signals: days_to_renewal, invoice_late_count_90d, payment_method_expiring, downgrade_requested, pricing_question_logged.
• Relationship signals: champion_departed, new_decision_maker, account_manager_changed_90d, support_tickets_open, escalations_90d.
• Judgment and action: risk_confirmed_by, risk_confirmed_date, root_cause_category, root_cause_detail, intervention_plan, intervention_owner, intervention_review_date, intervention_outcome.
• Outcome: churn_requested_date, churn_reason_stated, churn_reason_actual, exit_interview_held, saved_flag.

Tags

• Band: risk-green, risk-amber, risk-red, risk-critical. Exactly one applies at any time.
• Driver: signal-reports-unopened, signal-gone-quiet, signal-no-portal-use, signal-calls-declined, signal-performance-down, signal-invoice-late, signal-champion-gone, signal-pricing-question.
• Process: risk-confirmed, diagnosis-booked, intervention-active, recovering, recovered, cancellation-requested, saved, churned.
• Suppression: risk-monitoring-paused - for a client in a known seasonal lull or an agreed hiatus, with an expiry date so a pause cannot become permanent blindness.

Scoring model

Weights are a starting point to be calibrated against the agency's own churn history, not a universal truth. Build it, then look at the clients you actually lost and adjust.

• Reports unopened - 10 points per consecutive unopened report, capped at 30. The highest-weighted single signal because it is the cleanest evidence of disengagement.
• Client gone quiet - 5 points at 14 days since last client-initiated reply, 10 at 30 days, 20 at 60 days.
• Portal unused - 10 points at 30 days with no login, 15 at 60. Plus 10 where portal_active_users_30d has fallen to one from two or more, which usually means a champion has disengaged before they depart.
• Review calls declined - 10 points per consecutive decline or no-show, capped at 20.
• Performance down - 10 points per consecutive down month, capped at 20. Plus 10 where kpi_primary_vs_target_pct is below 70.
• Invoice late - 15 points for any late payment in 90 days. Payment behavior changes before stated intentions do.
• Champion departed or decision maker changed - 25 points, the single largest jump, applied on the day it is recorded.
• Pricing or scope question logged - 15 points. A client asking what they are paying for has already started the internal conversation.
• Renewal inside 60 days - a 1.3 multiplier on the total, because the same score is more dangerous when there is a decision point in view.
• Bands: Green under 25, Amber 25 to 44, Red 45 to 69, Critical 70 and above.

Forms and surveys

• Risk Confirmation - internal, completed by the account manager when a client enters the watchlist. Three questions: do you agree this is real, what do you think is actually going on, what would you do about it. Forces a judgment to be recorded rather than a feeling to be held.
• Root Cause Capture - internal, with a fixed category list: performance, communication, price or value, champion change, internal client change, adoption, service failure, external factors. Fixed categories are what make the churn data aggregable.
• Quarterly Relationship Pulse - client-facing, three questions, sent to every client regardless of band so the score has a live sentiment input rather than only behavioral inference.
• Exit Interview - used live on the call, capturing churn_reason_stated and, separately, churn_reason_actual as the interviewer judged it. These two differ often, and the gap is where the agency learns.

BO's role and guardrails

• BO assembles the weekly risk digest, listing accounts by band with their named drivers.
• BO drafts the diagnosis-call invitation and the intervention follow-up for the account manager to review.
• BO classifies inbound client messages for sentiment and for pricing, scope or cancellation language, and writes those flags to fields.
• BO never contacts an at-risk client unprompted. Every outbound message to an Amber or worse account is sent by a named human, or by BO only after a human has approved that specific message. An automated we-noticed-you-seem-unhappy message makes a wobbly client a lost one.
• BO never discusses pricing, discounts, contract terms or cancellation. Any message containing cancellation language is routed immediately to the account manager and the principal, with no reply sent, and the thread is flagged within minutes.
• BO cannot set risk_confirmed_by, root_cause_category or intervention_outcome. Judgment fields are human-only.
• BO never characterizes a client's state of mind to the client. Internally it reports signals; externally it says nothing about risk.

Numbers and channels

• Internal only by default: the weekly digest and all band-change alerts go to Slack and to the owner's task list.
• Client-facing contact on an at-risk account is by phone first, then email from the account manager's own address. No bulk email, no automated sequence, no SMS blast to a wobbling client.
• The quarterly pulse goes by email to all clients, with SMS reminder only to consented contacts.
• A dedicated Slack channel for Critical band accounts, with the principal in it.

Reporting surface

• A retention dashboard listing every client with band, score, trend, top drivers, days to renewal and intervention owner, sorted by score descending. One screen, read weekly.
• A churn post-mortem view aggregating root_cause_category and churn_reason_actual across all losses, which is the only honest input to what the agency should change.

One client, from first signal to recovery. A med-spa, eleven months into a retainer, previously healthy.

1. Week one. The Monday scoring run computes a churn_risk_score of 18, Green. The only contributor is 14 days since the client last initiated a reply. Nothing happens, correctly - a single soft signal is noise.
2. Week three. The month's report goes unsent-unopened for a second cycle. reporting_consecutive_unopened reaches 2, which adds 20 points. Portal logins have stopped, adding 10. Score is 48, band Red, trend Worsening. An opportunity is created in Client Retention at Watchlist and the driver tags signal-reports-unopened and signal-no-portal-use are applied.
3. The band change posts to Slack naming the drivers, and a Risk Confirmation form lands on the account manager with a 48-hour deadline. The client is contacted by nobody at this point. The watchlist is for the agency, not the client.
4. The account manager completes the confirmation the next morning. Their answer to what is actually going on: the marketing coordinator who was the day-to-day contact has not replied in a month and the owner has never been on a call. That is a champion-risk pattern the score cannot see directly. risk_confirmed_by and risk_confirmed_date are written and the opportunity moves to Risk Confirmed.
5. The account manager phones. No answer. They then email from their own address, framed as an ordinary check-in with a specific hook: the previous month's numbers and a question about a service line. No mention of reports going unread. The Diagnosis Call link is in the signature position, not the subject.
6. Day four. The owner replies, not the coordinator, and books the diagnosis call. The opportunity moves to Diagnosis Call Booked. champion_departed is set to yes on the record because the coordinator left the business three weeks ago, adding 25 points. The score is now 73, Critical, and the principal is pulled into the Critical channel.
7. The diagnosis call happens. The owner says nobody has been reading the reports because the coordinator who received them has gone, and they themselves had never seen one. They are not unhappy with the work; they have no visibility into it. That is the whole problem.
8. root_cause_category is set to Champion change, with root_cause_detail recording the specifics. The opportunity moves to Root Cause Identified. Had the category been Price or value, the escalation path would have gone to the principal instead of being handled by the account manager.
9. An intervention plan is agreed on the call, not written afterwards. intervention_plan records three actions: the owner becomes the primary report recipient, a 15-minute walkthrough of the last two reports happens this week, and a replacement day-to-day contact is named and given portal access and training. intervention_owner is the account manager. intervention_review_date is set 21 days out and booked in the calendar before the call ends.
10. The opportunity moves to Intervention In Flight, intervention-active is applied, and scoring alerts for this account are suppressed for 14 days so the plan gets room to work without the build shouting weekly about a problem that is being handled.
11. Week five. Report recipient fields are updated, the walkthrough is held, the new contact completes two training modules. reporting_consecutive_unopened resets to 0 on the next report open and days_since_portal_login resets. The next scoring run returns 31, Amber, trend Improving. The opportunity moves to Recovering.
12. Week seven. The intervention review call happens on its scheduled date. intervention_outcome is recorded as effective. Score is 22, Green.
13. Week nine. A second consecutive Green cycle moves the opportunity to Recovered, applies recovered, and clears the driver tags. The account manager is prompted to add the specifics to the account notes so the next person inherits the context.
14. The same month, a different client replies to a report email with the sentence can we talk about scaling this back. BO detects the cancellation language, sends no reply, and within two minutes alerts the account manager and the principal, moves that opportunity to Cancellation Requested, and offers the Principal Escalation Call. Detection speed is the whole value here; a cancellation email that sits unread for a day has already hardened.
15. Quarter end. The post-mortem view shows root_cause_category across the quarter's losses and near-losses. Champion change appears three times. That becomes a change to the onboarding build - a named secondary contact and a second report recipient from day one - which is the build improving itself from its own data rather than from opinion.

1. Weekly Risk Scoring Run

Trigger: scheduled, Mondays at 06:00 agency time, ahead of the working day so the digest is waiting rather than arriving mid-morning.

Conditions: runs for every client tagged as live and not tagged risk-monitoring-paused. Clients inside their first 45 days are scored but never banded above Amber, because onboarding-period signals are not comparable to steady-state ones.

Actions, in order:

1. Copy churn_risk_score to churn_risk_score_prior before anything else.
2. Refresh each signal field from its source: unopened count and variance from the reporting build, portal login and active-user counts from the portal, declines and no-shows from the calendars, late payments from the payment integration, renewal date from the contract record.
3. Compute the component scores per the weighting model, sum them, apply the 1.3 multiplier where days_to_renewal is 60 or fewer, and cap the result at 100.
4. Write churn_risk_score, set churn_risk_band, and write the named contributing signals to churn_risk_drivers as a readable list. The drivers field is what makes the score actionable; a bare number gets ignored.
5. Compare to churn_risk_score_prior and set churn_risk_trend to Improving, Flat or Worsening. A change of 5 or fewer points counts as Flat.
6. Apply exactly one band tag, removing the previous one. Apply or remove each driver tag to match the current drivers.
7. Hand off to workflow 2 for any band change, and to workflow 3 for the digest.

Stop or exit: if a source signal cannot be read, write the previous value, flag the record as having stale data, and post a named data-integrity alert. Never score a missing signal as zero - that silently turns a broken connector into a healthy client.

2. Band Change Detection and Watchlist Entry

Trigger: churn_risk_band changes value.

Conditions: only upward changes into Red or Critical create a pipeline opportunity. An Amber appearance is logged and digested but does not open a case, which keeps the pipeline thin enough to mean something.

Actions:

1. Branch on the new band. Green from anything higher: post an improvement note to Slack and, where an opportunity exists, hand off to workflow 7.
2. Amber: log the change, apply risk-amber, include in the digest, create no task.
3. Red: create an opportunity in Client Retention at Watchlist. Post to the pod Slack channel within 15 minutes. Copy: [client] has moved to Red, score [churn_risk_score], trend [churn_risk_trend]. Drivers: [churn_risk_drivers]. Renewal in [days_to_renewal] days. Owner: [account_manager]. Confirmation needed within 48 hours.
4. Critical: as above, plus post to the Critical channel with the principal, and create a same-day task for the account manager rather than a 48-hour one.
5. Assign the Risk Confirmation form to the account manager in all Red and Critical cases.
6. Wait 48 hours. If the form is unsubmitted, remind the account manager. Wait a further 24 hours and escalate to the principal. An unconfirmed risk flag is the main failure mode of this build.
7. Branch on confirmation. Confirmed writes risk_confirmed_by and risk_confirmed_date, applies risk-confirmed, moves to Risk Confirmed, and hands off to workflow 4.
8. Not confirmed requires a written reason, which is recorded against the account and reviewed monthly. A pattern of dismissals from one person, or on one signal, is useful information about either the model or the person.

Stop or exit: no client-facing message is sent anywhere in this workflow. Watchlist entry is invisible to the client by design.

3. Weekly Retention Digest

Trigger: completion of workflow 1, Mondays at approximately 07:00.

Actions:

1. BO assembles the digest: Critical accounts first with full drivers, then Red, then Amber accounts whose trend is Worsening. Accounts that are Amber and Flat or Improving appear as a count only.
2. Include the accounts that moved band in either direction this week, and the accounts with renewal inside 60 days regardless of band.
3. Include any account flagged as having stale data, named, so a broken signal is visible in the same place as the risks.
4. Post to the retention Slack channel and email the principal and each account manager their own accounts only.
5. Create a single weekly task for the digest owner: review and confirm actions on every Critical and Red account.
6. Branch: where no account is above Amber, send a short all-clear rather than nothing. A digest that only appears when there is bad news trains people to dread it and eventually to skip it.

Stop or exit: one send per week, no retries. A failed digest alerts the principal directly.

4. Diagnosis Outreach and Call

Trigger: tag risk-confirmed applied.

Conditions: all client contact here is by a named human. BO drafts; a person sends. No message references risk, scores or engagement.

Actions:

1. Create a call task for the account manager due the same day, with the drivers and the confirmation-form answers attached so the call has substance.
2. BO drafts an email for the account manager to review and send, framed as a normal check-in with a concrete hook from the account. Draft copy: Hi [first name] - I wanted to catch up properly rather than just send the monthly summary. A couple of things I would like your read on, and I would rather do it on a call than by email. Here is my calendar if that is easiest: [link], or reply with a time and I will work around you.
3. Wait 48 hours. If no response and no booking, the account manager phones again, and the principal is notified on Critical accounts.
4. Wait 72 hours. For Critical accounts, the principal makes contact directly with the decision maker. Changing who is asking is the most effective single escalation available.
5. On booking, move to Diagnosis Call Booked, apply diagnosis-booked, and send a prep task to the account manager carrying the full signal history.
6. Reminders at 24 hours and 2 hours. A no-show here is itself a strong signal: apply meetings_no_show_90d increment and escalate to the principal immediately rather than offering a third rebooking.
7. After the call, require the Root Cause Capture form within 24 hours. Submission writes root_cause_category and root_cause_detail, moves to Root Cause Identified, and hands off to workflow 5.

Stop or exit: cannot progress without a recorded root cause. A diagnosis call that produced no category is treated as not held.

5. Intervention Planning and Review

Trigger: root_cause_category populated.

Conditions: branches on category, because the same intervention does not fit every cause.

Actions:

1. Branch on category. Performance routes to a delivery review with the build owner. Communication routes to a reporting or cadence change. Price or value escalates to the principal and never to the account manager alone. Champion change routes to a new-contact onboarding mini-path. Adoption routes to retraining. Service failure routes to the principal with a written account of what went wrong.
2. Require intervention_plan, intervention_owner and intervention_review_date to be populated before the opportunity can move. The review date must be within 30 days.
3. Move to Intervention In Flight, apply intervention-active.
4. Suppress band-change alerts for this account for 14 days, so an active intervention is not drowned in weekly noise. The account still scores and still appears in the digest, marked as under intervention.
5. Create tasks for each action in the plan, each with its own owner and due date.
6. Wait until 7 days before intervention_review_date. Remind the owner and check that the plan tasks are progressing. An intervention plan with no closed tasks at this point escalates to the principal.
7. On the review date, require intervention_outcome to be recorded as effective, partial or ineffective, with a sentence of detail.
8. Branch on outcome. Effective or partial with an improving score hands off to workflow 7. Ineffective escalates to the principal and triggers a second-line plan, which must be materially different from the first rather than the same actions repeated.

Stop or exit: suppression expires automatically at 14 days whether or not the plan is complete, so a stalled intervention becomes loud again rather than staying quiet.

6. Cancellation Language Detection and Immediate Escalation

Trigger: any inbound client message - email, SMS or chat - across any channel.

Conditions: BO classifies for cancellation, pause, downgrade, pricing and competitor language. This workflow takes priority over every other response path, including BO's normal replies.

Actions:

1. On detection, suppress any automated reply to that thread immediately. Nothing automated goes back to a client who has just raised cancellation.
2. Within 2 minutes, alert the account manager and the principal by Slack and push notification, with the client name and the verbatim sentence that triggered detection.
3. Branch on language type. Explicit cancellation or pause: move to Cancellation Requested, apply cancellation-requested, stamp churn_requested_date, set churn_risk_band to Critical regardless of computed score, and offer the Principal Escalation Call.
4. Pricing or scope question without cancellation: set pricing_question_logged to yes, which adds 15 points at the next run, and create a same-day task for the account manager. Do not escalate to Critical on a pricing question alone.
5. Downgrade request: set downgrade_requested to yes and route to the principal, because a downgrade conversation is a pricing conversation.
6. Create a task to respond by phone within 4 working hours. The first response to a cancellation request should be a voice, not a thread.
7. Wait 4 hours. If the task is not actioned, escalate to the principal again. This is the one escalation in the build with no tolerance for delay.
8. Record the response and the outcome. A client who stays applies saved, sets saved_flag, and moves to Saved at Cancellation, with a mandatory 30-day follow-up review because a save is fragile.

Stop or exit: BO never replies in this path. Detection, suppression and alerting only.

7. Recovery Confirmation and Case Closure

Trigger: churn_risk_band returns to Green for an account with an open retention opportunity.

Conditions: requires two consecutive weekly runs at Green. One good week is noise, particularly where a score fell because a single signal reset.

Actions:

1. First Green run moves the opportunity to Recovering and applies recovering. No closure yet.
2. Second consecutive Green run moves it to Recovered, applies recovered, and removes intervention-active and the driver tags.
3. Create a task for the account manager to write what actually worked into the account notes, in one or two sentences, so the next person inherits the reasoning rather than just the outcome.
4. Post a short Slack note naming the account, the original drivers, the root cause and the intervention that worked. Recoveries are the only reliable source of knowledge about what interventions do.
5. Schedule a 60-day re-check task. A recovered account that regresses within 60 days is a different and more serious case than a first-time flag, and is escalated straight to Risk Confirmed, skipping the watchlist.
6. Branch: where the score fell because a signal went stale rather than because engagement improved, do not close. Hold at Recovering and flag for data review. A recovery that is actually a broken connector is the worst outcome this build can produce.

Stop or exit: closes the opportunity. The account returns to ordinary weekly scoring.

8. Churn Processing and Exit Interview

Trigger: a client's cancellation is accepted.

Actions:

1. Move to Churned, apply churned, remove every risk and process tag.
2. Capture churn_reason_stated immediately from the cancellation correspondence, in the client's own words.
3. Offer the Exit Interview, requested by the principal rather than the account manager, which materially increases both acceptance and candour. Copy: Completely understood, and no hard feelings. If you have half an hour, I would value hearing honestly where we fell short - it is the most useful thing anyone can give us and it will not turn into a sales conversation.
4. Wait 3 days. One reminder. Then stop. Do not chase a departing client.
5. On the interview, record churn_reason_actual as the interviewer assessed it, separately from the stated reason, and set exit_interview_held.
6. Create an internal post-mortem task: what the score was at churn, what the earliest signal was and when, what the agency did, and what should have happened differently. Fifteen minutes, written down, within a week.
7. Run the offboarding path: data retention or deletion per the agreement, access revocation, number release, final invoice.
8. Wait 90 days. Create a single win-back task for the principal, offered once. No automated win-back sequence.
9. Quarterly, aggregate root_cause_category and churn_reason_actual across all losses and near-losses, and create a task to change something specific in whichever upstream build the commonest cause points at.

Stop or exit: terminal. The post-mortem task must be closed before the case is archived, because the learning step is the only part of churn processing with any future value.

9. Signal Integrity and Model Calibration

Trigger: daily at 05:00 for integrity, plus a quarterly calibration run.

Conditions: this workflow watches the watcher. A churn model fed by a dead connector is worse than no model, because it reports confidence it does not have.

Actions:

1. Daily: check each signal source for freshness. Any source whose most recent write is older than its expected interval is flagged, named in Slack, and every client depending on it is marked as stale-data.
2. Daily: check for implausible uniformity - every client showing identical values on a signal almost always means the source is returning a default rather than real data.
3. Quarterly: compare churn_risk_score at the point of churn for every client lost that quarter against the scores of clients retained. Post the comparison.
4. Branch: any client who churned from Green or Amber triggers a model review task. The question is which signal was missing, not whether the person should have noticed.
5. Quarterly: compute the false positive rate from confirmed-risk accounts that recovered with no intervention, and recommend weight reductions where a single signal is driving most of them.
6. Create a quarterly calibration task for the principal with the proposed weight changes, requiring an explicit decision. Weights change deliberately and are versioned, never quietly adjusted.
7. Record the weight version in use, so a historical score can be interpreted against the model that produced it.

Stop or exit: runs indefinitely. A failure of this workflow escalates to the principal, because silent failure here makes every other number in the build untrustworthy.

What is different afterwards

• Churn stops being a surprise. The agency has weeks of warning on most losses, in a form anyone can read, rather than one account manager's unrecorded hunch.
• Attention goes where it is needed. A roster of thirty clients produces three or four accounts worth worrying about in a given month, which is a manageable amount of worry and the opposite of the vague permanent anxiety most agencies run on.
• The quiet clients become visible. Silence is now a scored signal rather than an absence of signal, which is the single biggest change for agencies whose losses skew toward accounts nobody had a problem with.
• Interventions have owners, plans and dates in the calendar, and an outcome recorded afterwards, so the agency learns which interventions actually work for which root cause.
• Root causes become aggregable. Fixed categories across every loss turn churn from a story told at each post-mortem into a ranked list of things to change.
• Cancellation requests get a defined path with the principal involved within minutes, rather than an improvised reply written by whoever opened the email.
• Other builds get better. The commonest root cause usually points at a fixable gap in onboarding or reporting, and the retention data is what identifies it.

Metrics to watch

• Band distribution over time - counts in Green, Amber, Red and Critical by week. A rising Amber count is an early read on the whole book, not just one account.
• Warning lead time - days between a client first entering the watchlist and either recovery or churn. If this is under two weeks on your losses, the scoring thresholds are too high or a signal is missing.
• Score at churn - what the score actually was for clients you lost. The honest test of whether the model works. Clients churning from Green mean a signal is missing entirely.
• False positive rate - share of confirmed-risk accounts that recovered without any intervention. A high rate means the weights are too aggressive and the team will start ignoring the digest.
• Confirmation rate and confirmation time - share of watchlist entries a human agrees with, and how long they take to say so. Slow confirmation is the usual place this build dies.
• Intervention success rate by root cause - from root_cause_category against intervention_outcome. This tells you which problems you can actually fix and which you cannot.
• Save rate at cancellation - from saved_flag. Expect this to be low; the point of the build is to have fewer accounts reach that stage at all.
• Root cause frequency - the ranked list, reviewed quarterly, and what changed in another build as a result.
• Stated versus actual churn reason - how often they differ. A large gap means exit interviews are being conducted too politely to be useful.
• Retention by cohort - survival at months 3, 6 and 12, segmented by onboarding completion time and day-30 pulse score, which is how you find out whether the earlier builds predict the later outcome.

Prerequisites

• Reporting automation and onboarding already running, or at minimum the fields they write. This build consumes their outputs - unopened counts, portal logins, goal attainment, pulse scores. Without them the score has almost nothing real to work from and will be mostly guesswork dressed as a number.
• Your own churn history, assembled honestly before the weights are set. List every client lost in the past twelve to eighteen months and write down what was observable about each in the two months before. The weights in this guide are a starting point; your data is the authority.
• Agreement that this build produces work. A risk flag nobody is accountable for acting on is worse than no flag, because it manufactures the feeling of having a system. Name the owner of the weekly digest before the first run.
• A fixed root-cause category list, agreed and closed. Free-text reasons cannot be aggregated and the whole learning loop depends on aggregation.
• Renewal dates recorded for every client, since the renewal multiplier is one of the most useful parts of the model and needs a real date.
• Honest conversations about accounts the agency already knows are shaky, before launch. Otherwise the first digest surfaces three things everyone knew and the build loses credibility in week one.

Integrations

• Stripe, QuickBooks or Xero for payment behavior. Late payment is one of the strongest commercial signals and it lives outside the platform.
• Google Calendar or Outlook for meeting attendance, declines and no-shows, which feed review_calls_declined_consecutive and meetings_no_show_90d.
• Slack for the weekly digest, band-change alerts and the Critical channel.
• The client portal or membership area for login and active-user counts.
• Zapier or Make where a support desk or other system holds ticket and escalation counts, documented per source so a dead connector does not silently zero a signal.

Messaging and contact discipline

• This build is internal first. Nothing in the scoring model should generate an automated client-facing message. The only automated client-facing element is the quarterly pulse, which goes to everyone and is not risk-conditional.
• Where the pulse uses SMS reminders, complete A2P 10DLC registration under the client's legal entity, honor STOP, UNSTOP and HELP, and keep to quiet hours in the recipient's local time, defaulting to 08:00 to 20:00.
• Never send an automated message that reveals the client is on a watchlist, and never let risk language appear in a template that could reach a client. Audit every template against this before launch.
• Contact on an at-risk account goes by phone first, then a personal email from a named human. Resist the urge to build a win-back sequence; a wobbling client who receives obvious automation reads it as confirmation that they are a number.

Compliance and data protection

• Risk scores are judgements about a client's business relationship. Treat the score, the drivers and the root-cause notes as confidential internal data, visible to the account team and the principal only, never on a shared dashboard a client might see and never in a report page.
• Be deliberate about message-content analysis. Scanning client communications for sentiment and cancellation language should be disclosed in the service agreement, limited to the agency's own correspondence with that client, and never applied to the client's end-customer conversations without a separate basis.
• champion_departed and new_decision_maker are facts about named individuals. Record the role change, not commentary about the person, and keep the retention period short.
• Exit interview notes should record what the client said and the interviewer's assessment, clearly distinguished, and should be retained for a defined period rather than indefinitely.
• Where the agency processes personal data on the client's behalf, the usual written processing agreement, retention period and deletion process apply, and a churned client's data needs an actual deletion path.
• None of this is legal advice. Confirm with the client's own counsel what disclosure the service agreement needs for communication analysis, and with the agency's counsel what retention is appropriate for risk and exit records in the relevant jurisdiction.

Calibration against an agency's own churn history is the bulk of the work here and varies considerably. To scope it, book a call at bookings.appbo.io.