Customer Health Agent: Usage, Tickets, Revenue, and Risk Signals

See how to build an agent that monitors customer health by combining usage data, support tickets, revenue metrics, and risk signals into a single, actionable view.

Start With the Promise

Most teams track "customer health" as a score buried in a dashboard. In this guide, we'll build a customer health agent that actually tells you what's going on with an account—usage, tickets, revenue, and risk signals—in one place, on demand.

What This Agent Is Expected To Do

This agent answers concrete questions about customer health. Here's what it should handle:

• "What's the current health of Acme Corp?"
• "Why did Contoso's health drop this week?"
• "Which customers are at risk this quarter and why?"
• "What's the story with customer X? Give me the full context."
• "Which customers should we prioritize this week?"
• "Show me all enterprise customers with declining usage."

The agent doesn't just return a score—it provides context, explains why, and surfaces actionable insights.

Who This Agent Is For

This agent is built for teams that need to understand customer health across multiple systems:

• CS / Customer Success – Prep before calls, monitor at-risk accounts, understand why health changed
• Founders / Leadership – Quick pulse on top customers, identify accounts that need attention
• RevOps / Data – Central place to encode health logic, surface insights without building dashboards
• Product – See how usage and tickets tie into retention, identify feature adoption patterns

If you live in CRM, tickets, product data, and billing systems, this agent is for you.

Core Use Cases

Here are the scenarios where this agent shines:

Spotting churn risk before renewal: The agent identifies customers with declining usage, increasing support tickets, or billing issues before they hit renewal. You can intervene early.

Understanding why a "healthy" account suddenly went quiet: A customer shows as healthy in your dashboard, but the agent reveals they haven't logged in for 30 days and have 3 open critical tickets. The dashboard missed it; the agent caught it.

Prioritizing which customers to talk to this week: Instead of manually reviewing dozens of accounts, the agent surfaces the 5–10 customers that need attention, with context on why.

Turning messy signals into one coherent story per account: Usage data says one thing, support tickets say another, revenue says a third. The agent synthesizes all signals into a clear narrative.

The Ingredients: Data You'll Need

To build this agent, you'll need data from a few key systems:

Usage data – Product events, feature adoption, last seen, active users, login frequency. Sources: Postgres (application database), Snowflake (data warehouse), product analytics tools.

Tickets – Volume, severity, open/closed status, time-to-resolution, satisfaction scores. Sources: Zendesk, Intercom, support systems.

Revenue – MRR/ARR, plan tier, renewal dates, upgrades/downgrades, payment status. Sources: Stripe, billing systems, CRM.

Risk signals – Low logins, negative NPS, repeated bugs, billing issues, contract expiration dates. Sources: Multiple systems, often derived from the above.

You don't need all of these to start. You can begin with 2–3 sources and expand later.

Step-by-Step Build

Here's how to build this agent, step by step.

Step 1: Define What "Healthy" Means for You

Before building anything, decide what "healthy" means for your business. Write out 4–6 dimensions:

Adoption: Are customers using the product? Metrics: active users, feature adoption, login frequency.

Engagement: Are customers actively engaged? Metrics: last seen, session frequency, feature usage trends.

Support load: Are customers struggling? Metrics: open tickets, ticket volume, time-to-resolution, satisfaction scores.

Commercial status: Are customers paying and growing? Metrics: MRR, plan tier, renewal dates, upgrades/downgrades.

Risk signals: Are there warning signs? Metrics: declining usage, increasing tickets, billing issues, contract expiration.

Then decide thresholds for each dimension:

Green (Healthy):

• Active users > 10
• Login frequency > 3x per week
• Open tickets < 2
• Payment status: current
• Usage trend: stable or increasing

Yellow (At Risk):

• Active users: 5–10
• Login frequency: 1–3x per week
• Open tickets: 2–5
• Payment status: delayed
• Usage trend: declining

Red (Critical):

• Active users < 5
• Login frequency < 1x per week
• Open tickets > 5
• Payment status: overdue
• Usage trend: sharply declining

Emphasize: Don't overfit the score. Start simple. You can refine thresholds later based on what you learn.

Step 2: Connect Your Data Sources in Pylar

Connect your data sources to Pylar. You'll need:

CRM (HubSpot, Salesforce): Customer accounts, company info, deal stages, renewal dates.

Product Database/Warehouse (Postgres, Snowflake, BigQuery): Usage events, feature adoption, user activity.

Support System (Zendesk, Intercom): Tickets, satisfaction scores, resolution times.

Billing (Stripe, billing system): Subscriptions, MRR, payment status, plan tiers.

In Pylar, use connectors to link each system. The connectors handle authentication and schema mapping. You'll configure:

• Database credentials
• API keys for SaaS tools
• Table/endpoint selection
• Sync frequency

Focus on business entities: accounts, users, tickets, invoices. You don't need every table—just the ones that matter for health.

Step 3: Build a Joined Customer Health View

In Pylar, create a Customer Health View that joins all your data sources. This is the core of your agent.

Here's what the view should include:

Base data (from CRM):

• Account ID, account name, company name
• Plan tier, MRR, renewal date
• Account owner, industry, company size

Usage data (from product database):

• Active users (last 30 days)
• Login frequency (last 30 days)
• Feature adoption score
• Last seen date
• Usage trend (increasing/stable/declining)

Support data (from support system):

• Open tickets count
• Critical tickets count
• Average time to resolution
• Satisfaction score (last 30 days)
• Ticket volume trend

Revenue data (from billing):

• Current MRR
• Plan tier
• Payment status
• Days until renewal
• Upgrade/downgrade history

Derived fields (calculated in the view):

• last_30d_logins: COUNT of logins in last 30 days
• active_users_count: COUNT of distinct active users
• open_critical_tickets: COUNT of tickets with severity = 'critical'
• months_to_renewal: DATEDIFF between today and renewal_date
• health_band: CASE statement that maps metrics to green/yellow/red

Here's an example SQL view:

-- Customer Health View
SELECT 
  -- Base data from CRM
  a.account_id,
  a.account_name,
  a.company_name,
  a.plan_tier,
  a.mrr,
  a.renewal_date,
  a.account_owner,
  
  -- Usage data from product database
  COUNT(DISTINCT u.user_id) as active_users_count,
  COUNT(DISTINCT DATE(u.login_date)) as last_30d_logins,
  AVG(u.feature_adoption_score) as feature_adoption_score,
  MAX(u.last_seen_date) as last_seen_date,
  CASE 
    WHEN COUNT(DISTINCT u.user_id) > COUNT(DISTINCT u.user_id) OVER (PARTITION BY a.account_id ORDER BY u.login_date ROWS BETWEEN 30 PRECEDING AND 1 PRECEDING) THEN 'increasing'
    WHEN COUNT(DISTINCT u.user_id) < COUNT(DISTINCT u.user_id) OVER (PARTITION BY a.account_id ORDER BY u.login_date ROWS BETWEEN 30 PRECEDING AND 1 PRECEDING) THEN 'declining'
    ELSE 'stable'
  END as usage_trend,
  
  -- Support data from support system
  COUNT(DISTINCT CASE WHEN t.status = 'open' THEN t.ticket_id END) as open_tickets_count,
  COUNT(DISTINCT CASE WHEN t.status = 'open' AND t.severity = 'critical' THEN t.ticket_id END) as open_critical_tickets,
  AVG(CASE WHEN t.status = 'closed' THEN t.resolution_time_hours END) as avg_resolution_time,
  AVG(CASE WHEN t.created_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY) THEN t.satisfaction_score END) as satisfaction_score,
  
  -- Revenue data from billing
  s.current_mrr,
  s.plan_tier as subscription_plan,
  s.payment_status,
  DATEDIFF(s.renewal_date, CURRENT_DATE()) as days_until_renewal,
  
  -- Derived health band
  CASE 
    WHEN COUNT(DISTINCT u.user_id) > 10 
      AND COUNT(DISTINCT DATE(u.login_date)) > 12
      AND COUNT(DISTINCT CASE WHEN t.status = 'open' THEN t.ticket_id END) < 2
      AND s.payment_status = 'current'
      AND (usage_trend = 'increasing' OR usage_trend = 'stable')
    THEN 'green'
    WHEN COUNT(DISTINCT u.user_id) BETWEEN 5 AND 10
      AND COUNT(DISTINCT DATE(u.login_date)) BETWEEN 4 AND 12
      AND COUNT(DISTINCT CASE WHEN t.status = 'open' THEN t.ticket_id END) BETWEEN 2 AND 5
      AND s.payment_status IN ('current', 'delayed')
    THEN 'yellow'
    ELSE 'red'
  END as health_band
  
FROM hubspot.accounts a
LEFT JOIN product_analytics.users u 
  ON a.account_id = u.account_id 
  AND u.login_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
LEFT JOIN zendesk.tickets t 
  ON a.account_id = t.account_id
LEFT JOIN stripe.subscriptions s 
  ON a.account_id = s.account_id
WHERE a.is_active = true
GROUP BY 
  a.account_id, a.account_name, a.company_name, a.plan_tier, 
  a.mrr, a.renewal_date, a.account_owner,
  s.current_mrr, s.plan_tier, s.payment_status, s.renewal_date;

This view joins data from HubSpot (accounts), your product database (usage), Zendesk (tickets), and Stripe (subscriptions). It calculates health metrics and assigns a health band.

Key points:

• The view joins across multiple systems in a single query
• It calculates derived fields (active users, login frequency, health band)
• It filters to only active accounts
• It uses time windows (last 30 days) for recency

Step 4: Add an MCP Tool on Top of This View

Create MCP tools that expose this view to agents. Tools translate natural language questions into SQL queries.

Tool 1: get_customer_health(account_name: string)

This tool returns complete health context for a specific customer.

Description: "Returns customer health metrics including usage, tickets, revenue, and risk signals for a specific account."

SQL Query:

SELECT * FROM customer_health_view
WHERE account_name = {account_name}
  OR company_name = {account_name};

Tool 2: list_at_risk_customers(limit: number, segment: string)

This tool lists customers at risk, with optional filtering by segment.

Description: "Returns list of customers at risk (yellow or red health band), optionally filtered by segment (enterprise, mid-market, SMB)."

SQL Query:

SELECT * FROM customer_health_view
WHERE health_band IN ('yellow', 'red')
  AND (segment = {segment} OR {segment} IS NULL)
ORDER BY 
  CASE health_band 
    WHEN 'red' THEN 1 
    WHEN 'yellow' THEN 2 
  END,
  days_until_renewal ASC
LIMIT {limit};

Tool 3: get_health_trend(account_name: string, days: number)

This tool shows how a customer's health has changed over time.

Description: "Returns customer health metrics over time to show trends."

SQL Query:

SELECT 
  account_name,
  health_band,
  active_users_count,
  open_tickets_count,
  usage_trend,
  DATE(calculated_at) as date
FROM customer_health_history_view
WHERE account_name = {account_name}
  AND calculated_at >= DATE_SUB(CURRENT_DATE(), INTERVAL {days} DAY)
ORDER BY calculated_at DESC;

Key points:

• Tools expose only the view, not raw database tables
• Tools handle parameterization (account names, limits, filters)
• Tools can be called by agents with natural language

Step 5: Wire the Tool to an Agent Builder

Connect your Pylar tools to an agent builder. You can use:

• OpenAI Platform – Build custom agents with GPT-4
• LangGraph – Build complex agent workflows
• Claude Desktop – Quick setup for internal use
• Cursor – Developer-focused agent builder
• Zapier / Make / n8n – Automation platforms

Agent Instructions:

Give your agent clear instructions:

You are a customer health assistant. Your job is to answer questions about customer health using the tools provided.

Rules:
1. Only use the tools provided. Do not invent metrics or make assumptions.
2. When asked about a customer, use get_customer_health to get complete context.
3. When asked about at-risk customers, use list_at_risk_customers.
4. Always provide context: explain why a customer is healthy or at risk.
5. If you don't have data, say so. Don't guess.

Available tools:
- get_customer_health(account_name): Get health metrics for a specific customer
- list_at_risk_customers(limit, segment): List customers at risk
- get_health_trend(account_name, days): Get health trends over time

Example Prompts Users Can Try:

1. "What's the current health of Acme Corp?"
2. "Why did Contoso's health drop this week?"
3. "Which enterprise customers are at risk this quarter?"
4. "Show me all customers with declining usage and open tickets."
5. "What's the story with customer X? Give me the full context."
6. "Which customers should we prioritize this week?"

The agent uses the tools to answer these questions, providing context and actionable insights.

Step 6: Add Evals & Guardrails

Add observability and guardrails to ensure the agent works correctly and safely.

Logging:

Track:

• Which customers are queried most frequently
• Error rates and types
• Query latency
• Unusual outputs or patterns

Use Pylar's Evals system to monitor:

• Success rates: How often queries succeed vs. fail
• Error patterns: What errors occur and why
• Query shapes: What types of queries agents make
• Raw logs: Every query with full context

Guardrails:

Add simple checks:

No PII leaking: Views exclude sensitive data (credit cards, SSNs, internal notes). Agents can only query through views, so they never see PII.

Limits on rows scanned: Views include LIMIT clauses to prevent unbounded queries. For example:

SELECT * FROM customer_health_view
WHERE health_band = 'red'
LIMIT 100;  -- Prevent scanning millions of rows

Time windows: Views filter to recent data (last 90 days, last 30 days) to prevent querying all historical data.

Access control: Views define exactly what data agents can access. Different agents can have different views (e.g., CS agents see all customers, sales agents see only their accounts).

Example guardrails in the view:

-- Customer Health View with Guardrails
SELECT * FROM customer_health_view
WHERE signup_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 2 YEAR)  -- GDPR: only last 2 years
  AND consent_status = 'granted'  -- Only consented customers
  -- Excludes: credit_card_number, ssn, internal_notes
LIMIT 1000;  -- Prevent unbounded queries

Step 7: Rollout Playbook

Introduce the agent to your team gradually. Here's a rollout plan:

Week 1: Pilot with CS Team

Start with 2–3 CS managers. Give them access and ask them to use it before customer calls.

Slack message example:

Hey team! We've built a customer health agent. Before your next customer call, try asking:

"What's the story with <customer>?"

The agent will give you complete context: usage, tickets, revenue, and risk signals—all in one place.

Try it out and let me know what you think!

Week 2: Expand to Leadership

Once CS validates it, share with founders/leadership for quick customer pulse checks.

Week 3: Rollout to Full Team

Open access to the full CS, RevOps, and Product teams. Monitor usage and gather feedback.

Week 4: Iterate

Based on usage, refine:

• Health thresholds (if too many false positives/negatives)
• View fields (if missing important context)
• Tool descriptions (if agents misuse tools)

Use Pylar's Evals to see what questions people ask most, what answers are most useful, and where the agent fails.

How This Replaces Dashboards (Without Killing Them)

This agent changes how teams interact with customer health data.

Old flow:

1. Open CRM dashboard → See health score
2. Open product analytics → Check usage
3. Open support system → Check tickets
4. Open billing → Check payment status
5. Manually correlate: "Usage is down, tickets are up, payment is delayed → at risk"
6. Form hypothesis: "Customer is struggling, likely to churn"

New flow:

1. Ask agent: "What's the story with Acme Corp?"
2. Agent returns: "Acme Corp: Health is yellow (at risk). Context: Usage dropped 40% in last 30 days (from 50 to 30 active users). 3 open critical tickets (avg resolution: 5 days). Payment delayed 15 days. Renewal in 45 days. Risk: High. Recommendation: Schedule health check call, address critical tickets, resolve payment issue."

The agent synthesizes data from multiple systems into a coherent narrative. You get answers in seconds instead of minutes.

Dashboards are still useful for:

• Monitoring known metrics
• Executive summaries
• Scheduled reports
• Visual exploration

Agents are better for:

• Ad-hoc questions
• Cross-system analysis
• Deep dives
• Proactive insi

Most teams track "customer health" as a score buried in a dashboard. This agent tells you what's actually going on with an account—usage, tickets, revenue, and risk signals—in one place, on demand.

If you want to try this with your own data, you can spin up a Customer Health View in Pylar and plug it into your existing agent builder. Start with 2–3 data sources, define simple health thresholds, and iterate based on what you learn.