The complete guide to Linear Customer Requests
Linear Customer Requests answers a question issue trackers historically ignored: not "what should we build" but "who is this for, and how do we know." Instead of feedback living in a separate tool that drifts out of sync with the backlog, requests attach directly to Linear issues — with the customer, their words, and a link to the original conversation.
If your team already lives in Linear, this is the shortest path to feedback-driven prioritization. Here's how it works, how to set it up well, and where it honestly stops.
The model: customers and requests
Two objects do the work (Linear's docs). A customer is a company — with attributes like revenue, tier, size, and owner, which can sync from Salesforce or another system of record. A request is one piece of feedback from one customer, attached to an issue or project, carrying the original message and a link back to the source conversation.
The design decision that matters: one issue can hold many requests. When the tenth company asks for SAML, you don't get ten duplicate tickets — you get one "SAML SSO" issue with ten requests stacked on it, and the customer records behind them add up to something a team can rank with: "10 requests, 4 enterprise, combined revenue you can actually see."
Step 1: turn it on and connect the sources
Requests get created three ways:
- From integrations — Intercom, Zendesk, and Front conversations, Slack messages, email intake, and Linear Asks. Creating or linking an issue from a support conversation adds a request pointing back to it, and the customer record is created automatically from the source.
- From Slack — link a message from a shared customer channel to an issue, and it becomes a request on that issue.
- Manually — from any issue, add a request and pick the customer.
Connect support first. That's where request volume lives, and the Intercom/Zendesk path means agents create or link issues without leaving the conversation.
Step 2: enrich the customer records before you trust the counts
Requests inherit their weight from customer attributes, so empty customer records make every request weigh the same. Sync or fill in tier and revenue early — via the Salesforce sync, the API, or manually for your top 50 accounts. "Sixty requests" is noise; "sixty requests, of which eight are from the enterprise tier" is a roadmap input. You can filter and segment projects by request volume, customer tier, or revenue once the data is there.
Step 3: use the importance flag for what it's for
A request can be marked important for a specific customer — meaning it's a critical need for them, not a nice-to-have. This is a per-customer signal, deliberately binary. Use it sparingly and it separates "the champion mentioned this" from "the deal or renewal turns on this." Use it on everything and it means nothing. A reasonable norm: the account owner flags importance, and a flagged request gets a comment saying why ("blocking their finance-team rollout, renewal in Q2").
Step 4: work requests into triage and planning
The payoff shows up in two ceremonies:
- Triage: when a new issue arrives, the question "have we seen this before?" becomes "which existing issue should this request attach to?" Attaching beats creating — it's how the counts accumulate. This is the same discipline as any feedback triage process, with Linear as the queue.
- Planning: sort candidate issues by request count and customer weight. Requests turn prioritization arguments from "sales keeps mentioning SSO" into an issue with the evidence attached.
Step 5: close the loop from the request list
Each request keeps its link to the source conversation, which means when the issue ships you have the exact list of conversations to go back to. Marking an issue done doesn't notify customers by itself — someone still has to write the follow-ups into each Intercom thread, Slack channel, or email. The request list makes that mechanical instead of archaeological. The practice is covered at close the loop.
Where Customer Requests stops
Being clear about the boundary saves disappointment:
- Capture is link-driven. A request exists when a human creates or links it from a conversation. Feedback nobody links — the aside on a sales call, the ambient complaint in a community Slack — never becomes a request.
- Dedupe is human. Linear stacks requests on an issue, but deciding that three differently-worded conversations belong on the same issue is still someone's judgment call, every time.
- Coverage follows the integration list. Sources outside it — Gong calls, Discord, GitHub discussions — need a path in.
That gap in front of Linear is where we sit: Modem captures feedback across Slack, Discord, support tools, email, Gong, and GitHub, auto-dedupes and quantifies it, and files it into Linear so requests accumulate without an agent remembering to link each conversation. Because Modem's context graph links each requester to their company, the request lands in Linear with the account and revenue context already on it. We build Modem, so read that with the bias in mind — and if your feedback volume is modest and arrives mostly through Intercom or Zendesk, native Customer Requests alone is a fine place to be. Other routes into Linear are compared in best tools to turn customer feedback into Linear issues.
The smallest version you can start this week
Connect your support tool, backfill tier on your top accounts, and adopt one triage rule: attach, don't duplicate. Within a month the issues with ten requests stacked on them will be obvious — and so will the next planning meeting.
