CSM Feed¶
The CSM Feed is where risk shows up. Every day, Clynto evaluates every account in your workspace against a set of conditions — payment failures, usage drops, upcoming renewals, health score declines, CRM silence — and puts the ones that need attention into a single feed. Each signal comes with an AI explanation from Larry and a set of recommended next steps you can push straight into your task list.
No more checking accounts one by one to figure out who's slipping.
What you'll see¶
The feed lives in the left nav under CSM Feed. Cards are sorted by severity first (critical at the top), then by ARR (biggest accounts surface first within the same severity), then by recency.
Each collapsed card shows:
- Account name and ARR
- Signal label — e.g. "Usage declining with upcoming renewal" or "Payment failed — $4,200 overdue"
- Severity badge — Critical, High, Medium, or Low
- When it fired — relative time like "3h ago" or "2d ago"
- Ack button — marks the signal as seen (green check replaces it once clicked)
Click a card to expand it. Two panels open:
- Analysis (left) — Larry's explanation of what's going on, the specific conditions that triggered with their scores, and a link to the account.
- Recommended Actions (right) — concrete next steps. Check the ones you want and hit Add as Tasks, or just Add All as Tasks to convert the full list.
Filters¶
Two dropdowns at the top: severity and signal type (Churn Risk, Renewal Risk, Disengagement). Billing signals show up in the feed too but don't have their own filter category — they're visible alongside everything else. Total count shows next to the Run Now button.
Signal types¶
Two categories: composite signals that score multiple conditions together, and billing signals that fire on individual Stripe events.
Composite signals¶
Churn Risk¶
The big one. Five conditions, each weighted independently:
| Condition | What it looks at | Source | Default weight |
|---|---|---|---|
| Payment failure | Payment status is failed or overdue |
Stripe | 30 |
| Health decline | Health score fell ≥10 points between the last two computations | Health engine | 25 |
| Contract proximity | Renewal coming up within 90 days | Stripe / CSV billing | 25 |
| Usage decline | ≥30% week-over-week drop in event volume, active users, or stickiness | Mixpanel (group mode) | 25 |
| CRM inactivity | No contact interaction in 30+ days | HubSpot | 15 |
The score is a weighted average of triggered conditions only. If an account only trips two of the five, the other three don't drag the score down — they're just ignored.
You can adjust these weights during Larry's onboarding (Topic 5 — Churn Signals). If payment failures matter more than CRM silence for your business, crank that weight up.
The signal label adapts to what triggered. Some examples:
- Payment failure — immediate attention required
- Usage declining with upcoming renewal
- Health declining with upcoming renewal
- Contract renewal approaching
- Usage declining week-over-week
- Health score declining
- CRM contact inactivity
- Elevated churn risk (multiple conditions, no single dominant one)
Renewal Risk¶
Fires when a contract renewal is within 90 days. The score blends churn risk with how soon the renewal hits:
renewal_risk_score = churn_score × 0.6 + proximity_weight × 0.4 × 100
Proximity weight by distance:
| Days to renewal | Weight |
|---|---|
| ≤ 30 | 1.0 |
| 31–60 | 0.6 |
| 61–90 | 0.3 |
So even a perfectly healthy account with a renewal in two weeks still gets flagged — you probably want to know about it.
Labels read like: Renewal imminent — 12 days, Renewal approaching — 28 days, Upcoming renewal — 45 days.
Disengagement¶
The early-warning version of usage decline. Compares usage over a 14-day window (not 7-day like the churn condition) and fires when the drop lands in the 15–30% band — meaningful enough to worry about, but not severe enough to trigger a full churn risk signal.
Drops under 15% are noise. Drops at 30% or above get caught by the churn risk usage decline condition instead. One account won't fire both.
Requires Mixpanel in group identity mode.
Billing signals¶
These don't use the weighted scoring model. Each one fires on a specific Stripe condition with a fixed severity.
| Signal | Trigger | Severity |
|---|---|---|
| Payment failed | Open invoice past due with outstanding balance | Critical |
| Subscription canceled | Canceled within the last 7 days | Critical |
| Past due | Subscription status is past_due |
High |
| Subscription downgraded | Active subscription set to cancel at period end | High |
| Trial expiring | Trial ends within 30 days | Low–High (closer = higher) |
With Stripe webhooks configured, these fire within seconds of the event. Without webhooks, they update on the next scheduled check or manual re-sync.
Billing signals auto-resolve. If a past_due subscription goes back to active, the signal clears on the next evaluation.
Severity levels¶
Composite signal scores map to severity like this:
| Severity | Score range | Meaning |
|---|---|---|
| Critical | 75–100 | Act now — real churn or revenue loss risk |
| High | 50–74 | Needs attention in the next few days |
| Medium | 25–49 | Worth monitoring, maybe reach out |
| Low | 1–24 | On the radar, not urgent |
Billing signals skip this mapping and use fixed severities (see table above).
How signals run¶
Schedule¶
You set a time and timezone during Larry's onboarding (Topic 7). Clynto runs the check once a day at that time — say, 8:00 AM Eastern — evaluating every account in the workspace.
What the check does¶
- Loads every account with its billing data.
- Evaluates churn risk conditions per account. Creates or updates signals for accounts that trip any conditions. Resolves signals for accounts that no longer do.
- Evaluates renewal risk for accounts with renewals within 90 days.
- Evaluates disengagement using the 14-day usage window.
- Evaluates billing signals for accounts with Stripe data.
- Sends in-app notifications to every user in the workspace for each new signal.
- Queues up Larry explanations for any new signals. These generate asynchronously — you might see "Explanation pending..." for a few seconds after a signal first appears.
What Larry sees¶
When generating an explanation and recommended actions, Larry gets the full picture for that account: name, industry, region, account status, journey stage, current health score and band, billing details (ARR, MRR, payment status, contract dates), up to five contacts with their roles and last interaction dates, and the specific conditions that triggered with their scores. For signals involving usage decline, Larry also gets a 30-day usage breakdown — total events, active user counts, week-over-week comparisons, and top features by volume.
That's why explanations reference specific numbers and dates rather than generic advice.
Deduplication¶
One active signal per type per account. If a churn risk signal already exists for an account, the check updates its score and conditions instead of creating a second one. Notifications only go out for brand-new signals.
Run Now¶
Hit Run Now in the top-right to trigger an immediate check outside the schedule. Good for after you connect a new integration or want to see the effect of something that just changed.
Taking action¶
Acknowledge¶
Ack on a card records a timestamp and swaps the button for a green check. Your team can see that someone's looked at it. The signal stays in the feed until the underlying conditions resolve — acknowledging doesn't hide it.
Create tasks¶
Expand a card and you'll see Larry's recommended actions — things like "Schedule a call to review usage trends" or "Loop in billing to resolve the overdue invoice." Check the ones you want and click Add as Tasks, or skip the checkboxes and Add All to convert the whole list. Tasks land on the Tasks page, tagged with signal as the source.
View account¶
View Account in the expanded card takes you to the full account detail — health score, billing, usage, support, and all active signals for that account in one place.
Prerequisites¶
Three things need to be in place before the feed does anything:
- Health config (Larry onboarding, Topic 6) — defines how health scores are computed.
- Signals schedule (Topic 7) — without this, checks don't run.
- At least one integration with data the engine can evaluate:
| Integration | What it unlocks |
|---|---|
| Stripe | Payment failure, contract proximity, all billing signals |
| Mixpanel (group mode) | Usage decline, disengagement |
| HubSpot | CRM inactivity |
You don't need all three. A workspace with only Stripe connected still gets churn risk and billing signals. Conditions that don't have data just get skipped — they won't show up in the conditions list or affect the score.
Signals on account pages¶
The same signals show up on individual account detail pages under Signals. Same data, same actions — just scoped to one account instead of the whole portfolio.
FAQ¶
How often do signals update? Once a day at your scheduled time. Run Now forces an immediate check. Billing signals with webhooks can also fire in near real-time.
Can one account have multiple signals? Yes — churn risk, renewal risk, disengagement, and any number of billing signals can all be active on the same account at once.
When do signals go away? When the conditions that triggered them stop being true. The next scheduled check (or Run Now) clears them automatically. There's no manual dismiss button — signals always reflect current state.
What generates the explanations and recommended actions? Larry, based on the signal type, the conditions that fired, and the account's context (ARR, health score, usage patterns, your special instructions). Both generate asynchronously — if you see "Explanation pending..." just give it a few seconds.
Can I change the condition weights? Yes — during Larry's onboarding (Topic 5). Bump up what matters more for your business, dial down what doesn't.
Why am I not seeing disengagement signals? Disengagement needs Mixpanel in group identity mode. User-level mode can't compute per-account usage comparisons.
What's the difference between "usage decline" and "disengagement"? Usage decline is a condition inside the churn risk signal — 7-day window, fires at ≥30% drops. Disengagement is its own signal type — 14-day window, fires in the 15–30% range. They don't overlap. An account won't trigger both for the same drop.
Do billing signals need the scheduled check to fire? They're evaluated as part of it, yes. But with Stripe webhooks configured, payment events also trigger evaluation in near real-time. The scheduled check is a safety net that catches anything webhooks missed.
Need help?¶
If something's off and this page doesn't cover it, reach out to support with:
- Your workspace name
- Which signal and account you're looking at
- Whether your schedule is configured (Larry onboarding, Topic 7)
- Which integrations are connected
We can look at your signal evaluation history from our side.