Customer Health: Risk Alerts and Upsell Signals

💡 One-sentence summary: Use a Grok Bot to build your AI customer success watch line — combine usage, support, renewals, and key-contact changes into one ranked watch list, with evidence attached to both risks and upsell signals, and contacting customers always stays behind approval.

This is the fifth and final lesson of Track A (workplace), using the same official six-step method as Daily Briefing, Expense Reconciliation, Sales Outreach, and Talent Sourcing. This lesson corresponds to the official use-cases page, one of 8 roles: Account health (Customer Health Specialist). The official positioning for it is: own the risk and upsell signals across the entire customer portfolio—not "help you write a few win-back emails," but a ranked watch list that, for every account, clearly states the evidence, why it matters, and what to do next. The four connection types officially named are CRM, product usage, support, and billing.

The whole lesson takes about 10 minutes. The official guidance has one special closing requirement for this role: define risk thresholds in the Bot's description so weekly results stay consistent—Step 1 of this lesson and the "Risk Threshold Calibration" magic Prompt cover exactly how to put this into practice.

What you'll be able to do after this lesson

• Build a "Customer Health Specialist" Bot: connect CRM, product usage, support tickets, and billing to watch your entire customer portfolio for you
• Have the Bot combine recent usage, support escalations, renewal dates, and key-contact changes into a ranked watch list—each account with evidence, why it matters, and a suggested next step
• Mine upsell signals from the same data: rising usage, new key contacts, renewal windows—using the same evidence standard as the risk list
• Save the scan process as a skill to rerun weekly; contacting customers and editing the CRM always stay behind approval

Why use a Grok Bot instead of web-based AI?

Capability	Web-based AI	Grok Bot
Can read your CRM and internal dashboards	❌ Export reports, copy and paste into the chat	✅ Connect directly where a connector exists; for systems without connectors, log in via a cloud computer browser
Remembers your risk thresholds	❌ Re-paste the criteria in every conversation	✅ Thresholds are defined in the Bot description; the official guidance explicitly requires this to keep weekly results consistent
Combines four signal types into one list	❌ You copy numbers from four systems and aggregate them yourself	✅ The Bot checks usage, support escalations, renewals, and key-contact changes one by one, then merges and ranks them
Evidence for every account	❌ Says "this customer is at risk" based on the model's gut feeling	✅ The official starter prompt explicitly requires evidence + why it matters + a suggested next step
Reruns automatically every week	❌ You redo it all yourself every Monday	✅ Save it as a skill, build a routine, and it runs in the cloud even with your laptop closed

Your current predicament

• Dozens of customers on your plate—whose usage is dropping, whose tickets are escalating, you find out only by digging through each system, and a week is gone by the time you finish
• Renewals always catch you off guard: the customer quietly switched their point of contact, usage dropped two months in a row, and you only find out a week before renewal
• Upsell calls are pure gut feel: usage has long exceeded the quota, yet no one thinks to negotiate an expansion

When to use this technique

When you need to:

• Go through your entire customer portfolio weekly, with risk accounts and upsell opportunities each ranked and backed by evidence
• Compress "digging through four systems to do homework" into "reading one AI customer risk alert list," then decide who to reach out to and what to discuss
• Approve actions like contacting customers or editing the CRM one by one yourself, so customers still feel it's you personally keeping watch

And you don't want to:

• Find out late only after a customer's problems have piled up
• Let AI message customers directly, or carelessly modify records in the CRM

🎒 Preparation Before Starting

• Read 3.2 Skills and Teaching—Step 4 of this lesson saves the scan process as a skill, and this is also the common prerequisite for all Track A scenarios
• Have a Bot you can delegate work to: if you don't have one yet, first go to 1.5 Create Your First Bot
• Think through how to connect the four data sources: CRM (connector or web version + login method), product usage (internal dashboards or analytics tools), support (ticketing system), billing (subscription system or finance spreadsheets)
• Prepare your current risk-judgment criteria: what counts as a usage decline, what counts as a ticket escalation, how far ahead of renewal counts as approaching—Step 1 will turn them into thresholds
• About 10 minutes, plus one round of human feedback after the first list comes out

Follow Along With Me

Step 1: Write the customer success manager's responsibilities and risk thresholds into the Bot's description

Why: The first step of the official six-step method is to write the responsibilities, data sources, output format, and standing boundaries into the Bot's description; this role has one extra official requirement—the risk thresholds are also defined here, so the weekly results stay consistent.

How to do it: Create or open a Bot (sidebar + → Create a Bot), and write the description as follows, replacing what's in 【】 with your own criteria:

You are my customer health specialist, responsible for risk alerts and upsell signals across my entire customer portfolio.
Data sources: CRM, product usage, support tickets, billing, and the customer portfolio list I give you.
Output format: a ranked watchlist—each account with evidence, why it matters, and a suggested next step; risks and upsell opportunities labeled separately.
Risk thresholds: a month-over-month usage drop of ≥【X%】 counts as a decline; support ticket escalations of ≥【N】 in a single week count as an escalation;
≤【M】 days until renewal counts as approaching renewal; key contact changes (departure/role change) are flagged immediately.
Standing boundaries: analyze and draft only—do not contact any customers, do not modify records in the CRM; if data cannot be found, say so explicitly and do not fabricate it.

You should see: the description is saved on this Bot's detail page. Writing the thresholds here means every weekly scan from now on uses the same yardstick.

Step 2: Connect the four data source categories—CRM, product usage, support, and billing

Why: the facts in the watchlist can only come from the data sources you connect—systems Grok Bot cannot read will never make it into the watchlist. The four connection categories the officials name for this role are: CRM, product usage, support, and billing.

How to do it: handle each data source one by one; for details of the 5-step connection method, see 2.5 Connecting apps:

1. First search for your CRM, ticketing system, and billing tool in Connect apps—if they show up, connect them directly (examples of apps named in the official documentation include Gmail, Notion, and Linear)
2. Systems without a connector (such as an internal usage dashboard, or a CRM that doesn't show up in Connect apps): have the Bot log into the web version using the browser on its cloud computer—login credentials are stored in Vault, and the Bot logs in on your behalf but never sees the values
3. Data living in spreadsheets (billing, usage exports): connect Google Sheets / OneDrive / SharePoint—note that Sheets connected with Viewer permission is read-only
4. If a system provides an MCP server, the Bot can also add it by URL
5. If authorization breaks, click Reconnect (on the app) or Reopen (on the connection card in the chat) to get back to the login page

You should see: the Bot can open all four data source categories. Note that Added ≠ logged in—when Needs auth or Disconnected is shown, you must click Authenticate to re-authorize for it to count.

💡 This is the unique value of Grok Bot

A web-based AI can only look at the exported reports you paste to it; a Grok Bot has its own cloud computer and browser, so it can log in and check CRMs and internal dashboards that have no connector. It verifies the numbers from the four systems one by one and then merges them—what you get is one list, not four reports.

Step 3: Run the first AI customer success scan with the official starter prompt

Why: the official starter prompt deliberately stops at a read-only, no-modification review point—validate the quality of the list first, then talk about automation.

How to do it: send the customer portfolio list (or a CRM view link) to the Bot along with your message, then send this Chinese-localized version of the official Account health starter prompt:

Review all accounts in this customer portfolio. Combine recent usage, support escalations, renewal dates, and
key contact changes into a ranked watchlist. Each account must include: evidence,
why it matters, and a suggested next step. Do not contact customers, and do not modify the CRM.

You should see: the Bot checks the four data source categories one by one and returns a ranked watchlist—three items per account: evidence (which number, which ticket), why it matters, and a suggested next step; both risks and upsell opportunities each come with evidence. Throughout, no customers were contacted and no records in the CRM were touched.

Step 4: Revise the output until it's reviewable, then save it as a "Weekly customer health" skill

Why: the official six-step method requires revising the results until they are "reviewable without you watching," then saving the workflow as a skill and testing it with a second input. The skill-saving example in the official documentation happens to be exactly this scenario—its name is Weekly account health.

How to do it: check the Bot's output item by item—can the evidence be traced back to its source? Were the thresholds applied correctly? Are the next-step suggestions reasonable? Send back anything that fails and have it redone; once it's reviewable, lock in the workflow:

Save the complete customer health scan workflow from just now as a skill named "Weekly customer health."
Requirements: include the source systems, risk definitions, output format, and the rule that customer contact always requires approval.

You should see: the Bot confirms the skill has been saved. Afterward, ask for it by name in any conversation—simply say "run the Weekly customer health skill" to invoke it (@ is for Bots, groups, routines, and apps, and does not produce skills).

The official method requires testing with a second input: run it again with a different customer portfolio and check that the thresholds and evidence still hold up. The private skill library is shared across all Bots; for saving details, see 3.2 Skills and teaching.

Step 5: Define failure handling, then create the weekly risk alert routine

Why: step five of the official six-step method: create the routine only after retries and failure scenarios are defined. The routine-creation example in the official documentation also happens to be exactly this scenario—running the customer risk skill on a schedule and posting a linked watchlist in the conversation.

How to do it: send the following (the weekly version of the official routine example):

Every Monday morning at 8:00, run the "Weekly customer health" skill on the current customer list,
and post a linked watchlist in this conversation. Do not contact customers.
If source data is unavailable, report the failure—do not use stale data.

After sending it, go through the six items of the official confirmation checklist with the Bot: which Bot it belongs to, time and time zone, input sources, expected results, approval boundaries, and what to do about missing data—correct it if anything doesn't match. The frequency in the official example is every workday at 8:00—if you want daily monitoring, change "every Monday" to "every workday" and use the skill name you saved.

You should see: the routine appears in this Bot's routines. A new routine does not run immediately—it waits for the next scheduled time; to verify right away, use Test. Routines run in the cloud, so they run even with your laptop closed; every run consumes usage, and once a week is very light—don't configure it to run hourly.

Step 6: Hold the approval line—no contacting customers, no modifying the CRM

Why: the two boundaries from the official starter prompt (no contacting customers, no modifying the CRM), plus the universal rule for all roles that "consequential external actions stay behind approval"—for customer success, these two are the red lines.

How to do it: keep the defaults for the mechanism—Auto Review is on by default; if you do have the Bot draft a win-back email, outgoing email comes out as a draft card by default (Needs approval), and emails sent by routines are always saved as drafts awaiting your Send. For the boundaries, confirm that the description from step 1 already states "do not contact customers, do not modify the CRM." Don't add actions to the routine that require approval beyond posting the list—approval cards triggered by a routine expire if not handled within 30 minutes.

You should see: what you receive each week is lists and drafts; which customer to approach, what to send, and whether to change CRM records are all released by you. For details on approval rules, see 3.1 Approvals and Auto Review.

📋 Magic Prompts

📝 Weekly Customer Health Watchlist (official starter prompt structure version)

Expected result: the Bot returns a ranked watchlist — at-risk accounts first, expansion opportunities after, with each account carrying evidence, why it matters, and a suggested next step.

## Role
You are my customer health specialist, responsible for risk alerts and upsell signals across my entire customer portfolio.
## Task
Synthesize recent usage, support escalations, renewal timing, and key-contact changes into one ranked watchlist.
## Input Information
### Required Items
- Customer portfolio: [account list or CRM view link]
- Risk thresholds: [criteria for usage decline / ticket escalation / approaching renewal]
### Optional Items
- Special attention: [accounts to watch extra closely this week?]
- Exclusion rules: [which accounts should not make the list?]
## Output Specification
Ranked watchlist: three items per account — evidence (numbers and tickets traceable back to sources), why it matters, and a suggested next step; risks and expansion opportunities labeled separately.
## Constraints
- ✅ Evidence is traceable back to sources; anything unverifiable is stated as such
- ✅ Risks and expansion opportunities use the same evidence standard
- ❌ Do not contact any customers
- ❌ Do not modify any records in the CRM

📝 Expansion Signal List (an expansion view of the same data)

Expected result: pull a separate ranked list of expansion opportunities from the same data sources — each opportunity clearly states where the signal comes from and why now is a good time.

## Role
You are my customer health specialist; this time, look only at expansion opportunities, not risks.
## Task
Find expansion signals in the CRM, usage, support, and billing data, and rank them by opportunity size.
## Input Information
### Required Items
- Customer portfolio: [account list or CRM view link]
- Expansion criteria: [what counts as an opportunity: usage over quota, new key contacts joining, approaching renewal window?]
### Optional Items
- Product lines: [only look at a specific product line?]
- Minimum threshold: [opportunities below what amount don't need to be reported?]
## Output Specification
Expansion opportunity list: each account with evidence, why now is a good time, and a suggested talking approach; if the amount can't be found, mark it "to be verified" — don't make up numbers.
## Constraints
- ✅ Each opportunity notes the signal source (usage numbers / key-contact changes / renewal dates)
- ✅ Use the same evidence standard as the risk list
- ❌ Do not contact any customers
- ❌ Don't fabricate amounts or budget figures

🔧 Risk Threshold Calibration (writing criteria feedback into the skill)

Expected result: you point out the accounts misjudged or missed this week, the Bot updates the threshold criteria and writes them into the skill, and next week's list is noticeably more stable — what should trigger an alert does, and what shouldn't no longer appears.

## Role
You are my customer health specialist, having just sent me this week's watchlist.
## Task
Against my feedback, update the risk thresholds and expansion criteria, and write them into the "Weekly Customer Health" skill.
## Input Information
### Required Items
- Misjudged accounts: [ones alerted that shouldn't have been, or not alerted that should have been, with the correct judgment explained]
- Corresponding thresholds: [which criteria to tighten or loosen]
### Optional Items
- New signals: [signals to factor into the judgment going forward?]
## Output Specification
First restate the new criteria you've summarized; update the skill only after I confirm.
## Constraints
- ✅ Criteria written into the skill, taking effect from next week's scan
- ✅ Only adjust thresholds; don't change the output format or approval boundaries
- ❌ Don't loosen thresholds to the point of distortion just to reduce alerts
- ❌ Do not contact any customers

Checkpoints ✅

• The Bot can open all four data source types: connectors show Installed (not Needs auth / Disconnected), and web-based systems stay logged in
• The first watchlist includes evidence, why it matters, and a suggested next step for every account, with evidence traceable back to sources
• Risk thresholds are written in the Bot description, and the criteria stay consistent over two consecutive weeks of runs
• The scan workflow is saved as a skill; with a different customer list, it can be rerun by name
• No customers were contacted and nothing in the CRM was changed throughout; the routine only posts the list, with no approval-requiring actions configured

Pitfall Reminders

❌ The same account is "high risk" this week and "fine" next week

The risk thresholds weren't written into the Bot's description — the official guidance explicitly requires defining thresholds in the description so weekly results stay consistent. Use the "Risk Threshold Calibration" magic prompt to lock the criteria into the skill.

❌ A source system is unreachable, and the Bot cobbles together a list from last week's stale data

The official routine example hard-codes this policy: if source data is unavailable, report failure; don't use stale data. When building a routine, spell out "what to do when data is missing" (this is also on the official checklist) — in customer health scenarios, stale data is more dangerous than no data.

❌ Wanting the Bot to send win-back emails directly to customers — not possible, and don't try

Official boundary: no contacting customers. Mechanically, outbound email defaults to a draft card first (Needs approval); emails sent by routines always go to drafts awaiting your Send — there is no unattended sending option. Your process of approving each one is the process of safeguarding the customer experience.

❌ Expansion opportunities based purely on "a feeling the customer will buy"

The expansion list follows the same evidence standard as the risk list: each opportunity notes the signal source (usage numbers, key-contact changes, renewal dates). Figures that can't be verified, like amounts and budgets, are marked "to be verified," not fabricated — negotiating an expansion with made-up numbers damages trust more than not negotiating at all.

Advanced Tips (Optional)

• Daily or weekly monitoring: the official skill example is "Weekly Customer Health," while the routine example runs a Daily customer-risk skill every workday at 8:00. Start with once a week; once stable, if you want to increase frequency, save a lightweight daily version following the official example. Every run consumes usage — double the frequency and the usage doubles too. See 3.3 Routines.
• Archive watchlists as Pages: have the Grok Bot organize the weekly customer health list into a Pages page (official positioning: readable pages like reports and dashboards) and store it in the Bot's Library — reviewing how a customer changed over several weeks or showing portfolio trends to your boss is faster than digging through chat history. See 2.2 Files and Reviewable Results.
• Connect expansion signals to sales outreach: hand the selected opportunities from the expansion list to the A3 Sales Outreach workflow to draft outreach — the same CRM data, one line from signal to draft.
• A different data source is a new scenario: with the same six steps, swap CRM, usage, support, and billing for an issue tracking system and a staging environment, and you get the reproducible package of B1 Bug Reproduction.

Lesson Summary

• ✅ One "customer health specialist" Bot + four data source types (CRM, product usage, support tickets, billing), producing an evidence-backed AI customer success watchlist
• ✅ Start with the official starter prompt: usage, support escalations, renewals, and key-contact changes — four signal types synthesized into a ranked list, with no customer contact and no CRM changes
• ✅ Write risk thresholds into the Bot description, adjust until auditable, then save as a skill and test with a different customer list
• ✅ The routine only posts the list: if source data is unavailable, report failure; contacting customers and modifying the CRM always stay behind approvals

Key Item	Value of This Lesson
Bot Role	Account health (customer health specialist) — risk and expansion signals across the entire customer portfolio
Connected Apps	CRM (connector or browser login), product usage dashboard, support ticket system, billing / finance spreadsheets
Judgment Criteria	Risk thresholds defined in the Bot description, keeping weekly results consistent
skill	"Weekly Customer Health" (official example name, invoked by name, shared across all Bots)
routine	Weekly risk alert (optional), post the list only; report failure if data is missing
Approval line	Do not contact customers or modify the CRM; emails stay in the draft stage; the routine has no approval action configured

Preview of the next lesson

Route A (workplace) ends here. Next we move on to Route B (programmer); the next lesson is B1 Bug Reproduction: still the same six steps, but with the information sources switched to an issue tracking system and a staging environment. You will learn:

• Turn a bug report into a reliable reproduction package: exact steps, expected vs. actual behavior, screenshots, and browser and system information
• Reproduce in staging with a brand-new test account, without touching production customer data
• Hand off test credentials securely (secure handoff), never through chat