# 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.

## Agent adaptation contract

- Canonical human page: https://agentry.sh/workflows/renewal-risk-brief
- Execution mode: on_demand
- Immutable automation template: none
- Applies to: b2b-saas, devtools-api, enterprise-sales
- Required example events: renewal_upcoming
- Required Agentry resources: none declared
- Do not use when:
  - Do not use until the example events are mapped to observed project signals, the current onboarding state is verified, and live event/property reads prove the required data is present.
  - Do not recommend this for products without a real revenue lifecycle or an equivalent paid-account signal.
  - Do not recommend this when the product has no stable account or workspace identity.
- Ask before using:
  - Which observed events map to renewal_upcoming? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?
  - Which live properties provide renewal_upcoming.account_id, renewal_upcoming.renewal_date, and which stable user or account identifier joins the signals?

This is an adaptable workflow example, not an API recipe. Map event and property names to the project's saved signal map, require status: "verified" from GET /v1/projects/:project_id/onboarding, and confirm the required signals through live event/property metadata and rows. Fetch current OpenAPI or query-blueprint details before making calls. Do not infer unattended authority from this page.

## 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.

```text
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."*