Generate a renewal-risk brief for each account

Combine usage decline, errors, seat utilization, and support friction into a renewal-risk brief CS can act on before the renewal date.

Updated · published

markdown for agents →

difficulty advanced · time to value 10 minutes · execution on demand
#analytics #revenue #customer-success #renewals #account-health #b2b

Start from this 

Generate renewal-risk briefs for accounts renewing in the next 60 days. Include usage trend, errors, seat utilization, support friction, and recommended CS action.

Why this matters

CS teams do not need another dashboard. They need a brief: what changed, why the account is at risk, and what to do before renewal.

What you get

  • Accounts renewing soon
  • Usage trend and seat utilization
  • Error/support friction
  • Recommended CS motion for each account

Walk through it

You

Which renewals are at risk this quarter?

Agent

I’ll find renewal cohorts and join them with usage and friction signals.

Endpoint: POST /v1/projects/:project_id/analytics/query
Exact shape: /v1/openapi.json?path=%2Fv1%2Fprojects%2F%7Bproject_id%7D%2Fanalytics%2Fquery&method=post
Custom HogQL goes in the OpenAPI-defined `query` field.
Concept fields:
  query: "SELECT properties.account_id AS account, argMax(properties.renewal_date, timestamp) AS renewal_date, count() AS recent_events FROM events WHERE timestamp > now() - INTERVAL 60 DAY GROUP BY account HAVING renewal_date != '' ORDER BY renewal_date ASC LIMIT 50"

The output

The agent returns one brief per account: risk level, evidence, and action. It should be written for a CSM, not for an engineer.

Setting it up

Emit renewal_upcoming or attach renewal date to account snapshot events. Keep account IDs consistent across usage, errors, and billing.

Variations

  • “Only include enterprise renewals.”
  • “Draft the CSM email for the top three at-risk accounts.”
  • “Create a weekly renewal-risk digest.”

Related workflows

ops 10 minutes

Review account-health evidence before outreach

Combine verified account usage, revenue context, and support-friction signals into a review queue without pretending a universal score proves churn or intent.

growth 2 minutes

Find quiet paying accounts before they churn

List paying accounts with zero events in 14 days. Sort by ARR. Get personalized outreach drafted in one prompt.

ops 10 minutes

Weekly CSM book-of-business digest

Create a weekly account digest for each CSM with risks, expansion signals, product adoption, and customers needing outreach.

Adapt this workflow in your own agent.

Ask your agent to map the starter prompt to your saved signal map, live events, and the current HTTP API before answering.

Agentry gives coding agents production context from errors, product analytics, and deploys through one HTTP API. Fetch and read https://agentry.sh/install.md completely, then install Agentry's full first-time telemetry baseline in this repository. I authorize device-code login, saving the owner key only to ~/.agentry/credentials.json, creating one Agentry project for this repository, and read-only inspection of shipped source plus hidden CI/provider configuration. Deeply analyze the product's business logic and complete value flow before choosing telemetry. Save the complete source-backed plan and show me its exact contents and hash. Until I explicitly approve that plan or request a replacement, do not edit app/CI source, place runtime/CI credentials, commit, exercise product traffic, start proof, push, or deploy. After approval, I authorize only the reviewed targets: place the required scoped browser/server/CI credentials through the established environment or secret mechanism, preserve existing telemetry, implement and test the baseline, commit it, push that reviewed commit when the shipped CI/provider path requires it, exercise safe proof paths with test/non-customer data, and perform one deployment through the reviewed shipped CI/provider path. Ask first if proof would charge money, contact a third party, change real customer data, or require new external access. After the plan is saved, immediately before every onboarding state-changing POST, GET current onboarding state, perform only its single returned next_action, then read state again; do not batch or infer later stages. Continue until status is verified, installation_complete is true, and next_action is null. Keep all secrets, source snapshots, proof markers, and scratch files outside the repository.

+ Full access
5.5 Extra High
  1. 1. Open your repo in Codex, Claude Code, Cursor etc.
  2. 2. Paste the install prompt.
  3. 3. Your agent reads the install doc and shows you an implementation plan for approval.
← all workflows