Instruction
Every weekday at 8:30 AM review usage, support tickets and renewal dates for every customer account and post a Slack digest of accounts that became at risk or show expansion signals.
Steps in each run
- 1 Read usage per account from product API
- 2 Read renewal dates and owners from Sheets Google Sheets
- 3 Load the previous run's health scores
- 4 Score account health with a reason
- 5 Keep accounts that changed or need action
- 6 Post digest to the customer success channel Slack
Memory. Saves each account's daily health status so the digest lists only accounts whose status changed or that need action this week.
Customer health digest for today
Sample output| Account | Status | Reason | Suggested next step |
|---|---|---|---|
| Silverbirch Dental Labs | At risk | Active users down from 42 to 19 in two weeks, renewal in 21 days | Owner call this week |
| Oakhollow Realty | At risk | Three open tickets about exports, negative tone | Escalate tickets and follow up |
| Marlowe Freight | Expansion | 58 active users on a 40 seat plan | Share Teams plan comparison |
| Bellhaven Clinics | Recovered | Usage back to normal after onboarding session | No action needed |
| Stonebridge Legal | Renewal due | Renewal in 14 days, usage stable | Send renewal summary |
-
Silverbirch Dental Labs
- Status
- At risk
- Reason
- Active users down from 42 to 19 in two weeks, renewal in 21 days
- Suggested next step
- Owner call this week
-
Oakhollow Realty
- Status
- At risk
- Reason
- Three open tickets about exports, negative tone
- Suggested next step
- Escalate tickets and follow up
-
Marlowe Freight
- Status
- Expansion
- Reason
- 58 active users on a 40 seat plan
- Suggested next step
- Share Teams plan comparison
-
Bellhaven Clinics
- Status
- Recovered
- Reason
- Usage back to normal after onboarding session
- Suggested next step
- No action needed
-
Stonebridge Legal
- Status
- Renewal due
- Reason
- Renewal in 14 days, usage stable
- Suggested next step
- Send renewal summary
Starts as a paused draft in your workspace. You review every step before the first run.
What the health digest does
Customer success managers usually check several tools before they know which accounts need a call. This agent does that check for them. Every weekday morning it pulls usage numbers from your product API, open tickets from your support tool, and renewal dates and owners from HubSpot or a sheet. An AI step reads the signals together and assigns each account a health status with a short reason.
The digest posted to Slack is short on purpose. It lists accounts whose status changed since the last run, renewals in the next 30 days that look at risk, and accounts showing expansion signals such as more active users than their plan includes. Each line has a suggested next step. See more examples on the customer success use cases page.
Weekday schedule
The default schedule is every weekday at 08:30 in America/New_York, written as 30 8 * * 1-5. The digest arrives before the team stand up, so priorities are clear for the day. Teams that work across regions often add a second cron in another timezone, or change the sentence to every day including weekends.
Each step of the digest
- 1Pull usage data. An HTTP step calls your product API with stored credentials and reads active users and key events per account.
- 2Pull support and renewal data. An integration step reads open tickets, renewal dates and account owners.
- 3Load the last scores. A memory step reads the health status saved after the last run.
- 4Score every account. An AI step weighs usage trend, ticket volume and sentiment, and time to renewal.
- 5Keep only changes. A condition step selects accounts whose status changed or that need action this week.
- 6Post the digest. The Slack step posts the digest and mentions each account owner.
If you add a step that emails customers directly, it includes an approval gate. The digest itself goes only to your internal Slack channel.
How memory keeps the digest short
After every run the agent saves each account's health status and the reason. The next weekday it compares new scores with the saved ones and reports only accounts that moved, plus a small list of renewals that need action. A healthy account that stays healthy never appears, and an at risk account is not repeated on every run unless something new happens, such as another ticket or a further drop in usage. This keeps the digest readable in under two minutes.
Customising the scoring
- Choose which product events count as healthy usage for your product.
- Change the weight of support tickets compared with usage.
- Set the renewal window, for example 60 days for annual contracts.
- Send a weekly summary to Gmail for leadership in addition to the daily Slack post.
- Write all scores to Google Sheets to build a health history.
Calling your own API uses an HTTP step with stored credentials. On Pro and Teams you can add a code step to calculate custom metrics. Read more in API, webhooks and MCP.
Who it is for
The template suits customer success teams at subscription businesses, account managers who own many accounts each, and founders who still handle renewals personally. If each manager spends twenty minutes every morning checking dashboards, the digest gives that time back and makes sure no renewal slips past unnoticed.
Frequently asked questions
Where does the agent get usage data?
From your own product API or an export you already have, through an HTTP request step with stored credentials. You can also read usage from a Google Sheet.
Does it contact customers?
No. The digest goes to your internal Slack channel. Any customer email step you add waits for approval first.
How is the health score calculated?
An AI step weighs the signals you choose, such as usage trend, open tickets and time to renewal, and writes a reason for each status. You can change the rules in plain English.
Can each manager get only their own accounts?
Yes. The Slack step can mention owners, or you can create one cron per manager that filters by owner and posts to a direct message.
What if the usage API is down?
The HTTP step retries three times with backoff. If it still fails, the digest is not posted with partial data and you get a failure alert by email or Slack.