Rank support load by account

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

Updated · published

markdown for agents →

difficulty intermediate · time to value 5 minutes · execution on demand
#analytics #errors #customer-support #account-health #b2b #revenue

Start from this 

Rank accounts by support load for the last 30 days using errors, affected users, complaint events, and plan or revenue tier.

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.

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

Related workflows

ops 10 minutes

Review account-health evidence before outreach

Combine verified account usage, revenue context, and support-friction signals into a review queue without pretending a universal score proves churn or intent.

debugging 5 minutes

Investigate one customer-reported problem

Review the minimum identity-linked product evidence for an authorized support case, corroborate any real error case, and prepare a reply that preserves uncertainty.

debugging 2 minutes

Rank errors by revenue impact, not raw count

Multiply users-affected by their plan ARR to surface the bugs costing real money. Stop triaging by event volume.

Adapt this workflow in your own agent.

Ask your agent to map the starter prompt to your saved signal map, live events, and the current HTTP API before answering.

Agentry gives coding agents production context from errors, product analytics, and deploys through one HTTP API. Fetch and read https://agentry.sh/install.md completely, then install Agentry's full first-time telemetry baseline in this repository. I authorize device-code login, saving the owner key only to ~/.agentry/credentials.json, creating one Agentry project for this repository, and read-only inspection of shipped source plus hidden CI/provider configuration. Deeply analyze the product's business logic and complete value flow before choosing telemetry. Save the complete source-backed plan and show me its exact contents and hash. Until I explicitly approve that plan or request a replacement, do not edit app/CI source, place runtime/CI credentials, commit, exercise product traffic, start proof, push, or deploy. After approval, I authorize only the reviewed targets: place the required scoped browser/server/CI credentials through the established environment or secret mechanism, preserve existing telemetry, implement and test the baseline, commit it, push that reviewed commit when the shipped CI/provider path requires it, exercise safe proof paths with test/non-customer data, and perform one deployment through the reviewed shipped CI/provider path. Ask first if proof would charge money, contact a third party, change real customer data, or require new external access. After the plan is saved, immediately before every onboarding state-changing POST, GET current onboarding state, perform only its single returned next_action, then read state again; do not batch or infer later stages. Continue until status is verified, installation_complete is true, and next_action is null. Keep all secrets, source snapshots, proof markers, and scratch files outside the repository.

+ Full access
5.5 Extra High
  1. 1. Open your repo in Codex, Claude Code, Cursor etc.
  2. 2. Paste the install prompt.
  3. 3. Your agent reads the install doc and shows you an implementation plan for approval.
← all workflows