How to See Every Customer Blocked by a Single Linear Issue
Open the issue and check the Customer Requests panel: Linear attaches every request tied to that issue there, each one carrying the customer name, tier, revenue, and a link back to the original conversation. That's the built-in answer, and it's a real one if your team consistently links conversations to issues. The catch is in the word "attached." A request only shows up if it came through Intercom, Zendesk, Front, Slack, email intake, Linear Asks, a Salesforce sync, or someone typed it in by hand (Linear's docs list the sources). Anything else, a customer who mentioned it on a call, in a DM, in a support tool Linear doesn't touch, is invisible to that panel even though the customer is just as blocked.
So the honest version of the question isn't "does Linear show me who's blocked," it's "does Linear see every place a customer said they're blocked." For teams whose feedback funnels almost entirely through one or two connected tools, the panel is close enough to complete. For everyone else, it's a partial list that looks complete, which is worse than an obviously partial one.
The four fields on a linked request
Every request on an issue carries four things: which customer, what they said, where it came from, and how important it is to them. That last part is a binary importance flag a rep can set per request, meant to mark "this blocks their renewal" rather than "someone mentioned it once." Two viewing habits make the panel worth checking regularly:
- Subscribe to the issue. You get notified when a new request lands on it, so "who's blocked by this" stays current without a manual recheck.
- Subscribe to a customer directly. From a customer's page, the bell icon lets you follow that one account across every issue it touches, useful for CS owners tracking a specific renewal.
Custom views add the other half: you can build a view ordered by customer count, so issues with the most requests attached float to the top without you tallying them by hand. That's a real prioritization tool, not just a display.
“we need SSO before rollout”
“any update on single sign-on?”
“SSO came up twice on this call”
Linear issue, quotes attached
insight report in NotionSetting it up so the panel is worth trusting
Customer Requests is on by default for connected sources, so there's no toggle to flip. The work is making sure requests actually land there:
- Connect your support tools first. Intercom, Zendesk, and Front conversations create a request automatically when an agent links or creates an issue from them, that's the highest-volume path and the one worth getting right before anything else.
- Fill in customer tier and revenue. A request from an empty customer record weighs the same as one from your biggest account. Sync from Salesforce on Enterprise plans, or backfill manually for your top accounts.
- Make linking a triage step, not an afterthought. When a rep works a support conversation that clearly matches an open issue, linking it takes one click and is the only thing that makes the customer show up on that issue at all.
- Build one custom view ordered by customer count. That's the view a planning meeting should open with, not a raw issue list sorted by creation date.
None of this is hard to configure. What it depends on is a human noticing the match and clicking link, every single time, across every channel a customer might use.
When the panel gave a support lead the wrong headcount
Owen Castellanos runs support at Portside Retail, a 40-person team selling inventory software to mid-size retailers. An issue titled "barcode scanner times out on bulk receiving" had three linked requests, all from Zendesk tickets, all logged over six weeks.
Before a planning meeting, his VP asked the obvious question:
VP of Product: Three tickets over six weeks doesn't feel urgent enough to bump the roadmap. Are we sure that's the whole picture?
Owen checked Slack before answering, because he remembered a thread in the shared customer channel for one of Portside's larger accounts:
Owen (in the planning doc): It's not the whole picture. One of Portside's top-20 accounts flagged this twice in their Slack channel, and their ops lead mentioned it again on last week's QBR call. None of that is linked to the issue because it never went through Zendesk. The real count is five customers, not three, and one of them is a renewal risk in three weeks.
Nothing in Linear was wrong. The three tickets it showed were real and correctly linked. But the issue's request count answered "how many people filed a ticket," not "how many customers are actually blocked," and those turned out to be different questions with a renewal riding on the gap.
Three limits under real volume
Three limits show up consistently once volume passes what one person can track from memory:
- Coverage follows the integration list. A call, a community Slack message, a Discord ping, an email nobody forwarded, none of it becomes a request unless someone manually adds it, and manually adding requires first knowing it exists.
- Linking is a per-conversation decision. Even inside supported sources, a rep has to notice the match and click link. On Business and Enterprise plans, Triage Intelligence will flag a likely duplicate once something becomes a Linear issue, but that comparison only runs against issues already in the tracker. It has no way to catch the version still sitting in an unlinked support ticket or a Slack thread, which is the gap that matters here.
- The count on the issue is a count of what got attached, not a count of who's blocked. Those match exactly when linking discipline is perfect. It usually isn't, especially under support-ticket volume.
Modem is the tool we build for this specific gap: it watches Slack, Discord, email, support tools, calls, and Linear together, and links every mention of a topic back to the person and company behind it whether or not a human remembered to click link. When five customers across four channels are all describing the same blocker, Modem treats it as one topic with five people attached, including the ones a Zendesk-only view would miss. That said, a team whose feedback genuinely arrives through one or two connected tools already gets that coverage from the native panel, for free. The case for something more only shows up once feedback starts fragmenting across channels the way Owen's did. For the customer/request model itself, see our complete guide to Linear Customer Requests; for how Triage Intelligence's duplicate suggestions actually work and where they stop, see does Linear automatically catch duplicate feature requests.
A one-question habit for the next planning meeting
Build one custom view ordered by customer count, and before your next planning meeting, pick the top three issues in it and ask out loud whether anyone remembers a customer mentioning the same problem somewhere that isn't linked. Owen's five-versus-three gap surfaced because someone asked that question once. Turning it into a habit costs nothing and catches most of what the panel misses.
