# Rank support load by account

> Combine errors, complaints, affected users, and plan data to show which accounts are consuming the most support attention.

## Agent adaptation contract

- Canonical human page: https://agentry.sh/workflows/support-load-by-account
- Execution mode: on_demand
- Immutable automation template: none
- Applies to: b2b-saas, devtools-api, enterprise-sales
- Required example events: support_ticket_opened
- 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 when the product has no stable account or workspace identity.
- Ask before using:
  - Which observed events map to support_ticket_opened? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?
  - Which live properties provide support_ticket_opened.account_id, support_ticket_opened.topic, 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

Support load is not evenly distributed. One account can dominate support because of one unresolved bug, bad onboarding, or a product mismatch.

## What you get

- Accounts ranked by tickets, errors, and affected users
- Top topics or fingerprints per account
- Revenue-aware prioritization
- Follow-up action for CS or engineering

## Walk through it

**You:**
> Which accounts are generating the most support load?

**Agent:**
> I'll join support events and error impact by account.

```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, countIf(event = 'support_ticket_opened') AS tickets, countIf(event = '$exception') AS errors, count(DISTINCT distinct_id) AS affected_users FROM events WHERE timestamp > now() - INTERVAL 30 DAY GROUP BY account ORDER BY tickets DESC, errors DESC LIMIT 30"
```

## The output

The agent returns accounts by support load and explains whether the likely fix is product, engineering, documentation, or CS.

## Setting it up

Send support-ticket events from your help desk webhook or backend. Use the same `account_id` as analytics and errors.

## Variations

- *"Only show enterprise accounts."*
- *"Which support topics correlate with churn?"*
- *"Create a weekly support-load dashboard."*