Rank Intercom and Zendesk feature requests by the revenue of the people asking

SKILL.md---
name: intercom-requests-weighted-by-revenue
description: "Monthly: 90 days of feature requests from support and Discord, ranked by the MRR of the customers asking and the open deals they hold up. Use when the user asks for this, or when it runs on a schedule."
---

# Feature requests weighted by revenue: support, Stripe and CRM

Monthly: 90 days of feature requests from support and Discord, ranked by the MRR of the customers asking and the open deals they hold up.

A feature request list sorted by count favors whoever writes in most: free users, small accounts, the regulars in Discord. The request that three of your biggest customers raised once each, and that two open deals mention, sits near the bottom of it.

Once a month the agent groups 90 days of requests from Intercom and Zendesk (and Discord, counted but not priced), matches each requester to their Stripe MRR and their open HubSpot deals, and ranks the requests both ways. Product managers see where count and revenue disagree; support and founders get a list they can answer customers from.

## Two ways to get the data

Use the API or MCP route when you have an MCP server, a CLI or an API token for the app. Otherwise, if you can drive a browser the user is signed in to (Claude in Chrome, a Playwright or Chrome DevTools MCP server), use the browser route. Say which one you used.

## Route A: API or MCP server

### What you need

- Read access to Intercom conversations or Zendesk tickets, and the feature-request tag if you use one; untagged requests are classified by the agent.
- The same customer email in Intercom or Zendesk, Stripe and HubSpot: each request is priced through its requester's email, or the company domain when that is all that matches.
- Read access to Stripe Customers and Subscriptions and to HubSpot contacts and deals; optionally a Discord bot with View Channels and Read Message History on the requests channel.

If something is missing, say what and stop; do not invent numbers.

### Steps

1. **Collect 90 days of requests** (Intercom): Intercom: `POST /conversations/search` with `created_at >` the Unix time 90 days ago, plus `tag_ids IN [<feature request tag>]` if you tag them, and `GET /conversations/{id}` for the messages and `source.author.email`. Zendesk: `GET /api/v2/search.json?query=type:ticket created>90days tags:feature_request` (your tag), then `GET /api/v2/users/show_many?ids=<requester_ids>` for emails.
2. **Add community requests** (Discord): For a feature-requests forum channel, list threads with `GET /channels/{channel.id}/threads/archived/public` and `GET /guilds/{guild.id}/threads/active`, keep those started in the 90 days (the thread ID is a snowflake that encodes the time) and read each starter message. Discord does not give bots members' emails, so these are counted but carry no revenue unless you keep a username-to-email list.
3. **Classify into features**: Map each request to one name on the feature list the person keeps, using its synonyms; read untagged conversations too, since many requests arrive inside a support question. Propose a new name only for a cluster of 3 or more unmatched requests. Count unique requesters per feature, not conversations, so a customer who wrote five times counts once.
4. **Look up each requester's revenue and deals** (Stripe): Stripe: `GET /v1/customers/search?query=email:"<email>"`, then the customer's active subscriptions for MRR (monthly, after discounts). HubSpot: `POST /crm/v3/objects/contacts/search` with `email IN [...]`, then `POST /crm/v4/associations/contacts/deals/batch/read` and the deals' `amount` and `hs_is_closed`, keeping open ones.
5. **Join and rank both ways**: Join on the lowercased requester email; when it misses, match the email domain to a Stripe customer or HubSpot company domain, never free-mail. A company with several requesters adds its MRR and each deal once per feature. Requesters with no Stripe customer count in the request total and add $0. Rank by MRR, show the count rank beside it, and call out any feature whose MRR rank is 3 or more places above its count rank.

## Route B: the browser

### What you need

- Signed in to Intercom or Zendesk as a teammate or agent, to the Stripe Dashboard (Analyst role or higher), to HubSpot with view access to contacts and deals, and to Discord as a member of the requests channel.

If something is missing, say what and stop; do not invent numbers.

### Steps

Start at https://app.intercom.com/. The user is signed in already; never type passwords or codes, and ask if a sign-in page appears.

1. **Collect requests in Intercom**: Open the inbox, search or filter by your feature-request tag and set the date to the last 90 days. For each conversation, note the requester's email and what they asked for. Read a sample of untagged conversations too, since requests often arrive inside support questions.
2. **Add Zendesk and Discord**: Zendesk: search `type:ticket created>90days tags:feature_request` and note requester and request. Discord: open the feature-requests forum channel, scroll through posts from the last 90 days and note each request and username.
3. **Group and count**: Map each request to a feature from the list, by name or synonym, and count unique requesters per feature. Propose a new feature only for 3 or more similar unmatched requests.
4. **Price the requesters**: In `https://dashboard.stripe.com/customers` search each email and read the active subscription amount per month. In HubSpot, open the contact (or company) and read the open deals in its **Deals** card. Count a company once per feature; Discord requesters add no revenue.
5. **Rank and report**: Rank features by MRR with the count rank beside it and the open deals, flag features 3 or more places higher by MRR than by count, give totals by source, and end with the feature to prioritize and the customers to tell when it ships.

Note: Looking up each requester by hand is slow past about 100 requests; the browser route then works best on the top features by count plus anything tagged by a paying account, and the API route covers the full set. Without a feature-request tag the browser route can only sample untagged conversations, so its counts run low.

## The report

- **Requests in 90 days**: how many, from how many people, by source.
- **Ranked by MRR**: each feature with unique requesters, count rank, MRR of paying requesters and open deals that mention it.
- **Where count and revenue disagree**: features that rank much higher by MRR than by count.
- **Proposed new features** from unmatched requests.
- What to do first: the feature with the most MRR and open pipeline behind it, and the customers to tell when it ships.

## Post it to Briefkin

When `BRIEFKIN_TOKEN` is set, or `~/.config/briefkin/env` exists (the installer from https://briefkin.dev/docs writes it), also send the result to the user's Briefkin board as one card. Keep the `item_key` the same on every run so the card updates in place, use a new `event_id` per run, and put today's real numbers in place of the example ones. If the request fails, say so once and carry on.

```bash
[ -n "${BRIEFKIN_TOKEN:-}" ] || . ~/.config/briefkin/env
curl -sS -X POST "${BRIEFKIN_URL:-https://briefkin.dev}/v1/events" \
  -H "authorization: Bearer $BRIEFKIN_TOKEN" \
  -H "content-type: application/json" \
  -d @- <<'JSON'
{
  "v": 1,
  "event_id": "intercom-requests-weighted-by-revenue/<date of this run, e.g. 2026-10-16>",
  "item_key": "intercom-requests-weighted-by-revenue",
  "project": "Acme",
  "source": "Feature requests weighted by revenue: support, Stripe and CRM skill",
  "kind": "update",
  "title": "SSO is 4th by requests but 1st by revenue",
  "summary": "**SSO** came from 9 customers in 90 days, 4th by count, but they pay **$3,100 MRR**, more than any other request, and it holds up **2 open deals worth $40,000**. Dark mode leads by count with $620 MRR behind it.",
  "widget": [
    {
      "type": "Table",
      "props": {
        "columns": [
          "Request",
          "Requesters",
          "Count rank",
          "MRR",
          "Open deals"
        ],
        "align": [
          "left",
          "right",
          "right",
          "right",
          "left"
        ],
        "rows": [
          [
            "SSO (SAML)",
            9,
            "4th",
            "$3,100",
            "2, $40,000"
          ],
          [
            "Bulk CSV import",
            21,
            "2nd",
            "$1,850",
            "None"
          ],
          [
            "Zapier integration",
            17,
            "3rd",
            "$1,400",
            "1, $8,000"
          ],
          [
            "Calendar sync",
            8,
            "5th",
            "$900",
            "None"
          ],
          [
            "Dark mode",
            34,
            "1st",
            "$620",
            "None"
          ]
        ]
      }
    },
    {
      "type": "Text",
      "props": {
        "text": "214 requests from 146 people: Intercom 128, Zendesk 61, Discord 25 (counted, not priced).",
        "variant": "muted"
      }
    },
    {
      "type": "Callout",
      "props": {
        "text": "Woodgrove Bank ($28,000) and Relecloud ($12,000) list SSO as a blocker. When ENG-412 has a date, tell them and the 9 paying requesters.",
        "tone": "info"
      }
    }
  ]
}
JSON
```

Widgets come from the Briefkin catalog (https://briefkin.dev/v1/catalog). Without a token, just give the user the report.

## Run it on a schedule

Suggested: 1st of the month at 9:00 (`0 9 1 * *`). From cron, with the agent signed in on that machine:

```bash
0 9 1 * * claude -p "Run the intercom-requests-weighted-by-revenue skill"
# Codex: codex exec, Gemini CLI: gemini -p, Copilot CLI: copilot -p, OpenCode: opencode run
```

Or use the agent's own scheduler (Claude Code routines, Codex automations, Claude or ChatGPT scheduled tasks): https://briefkin.dev/skills/intercom-requests-weighted-by-revenue#schedule

Source: https://briefkin.dev/skills/intercom-requests-weighted-by-revenue