Every product team drowns in feedback and starves for signal. Requests arrive through support chats, sales calls, Slack threads, and the occasional loud email, and by the time they reach engineering they have lost the one detail that would let anyone prioritize them: which customers actually asked, and how much they are worth. Linear Customer Requests, which Linear shipped in December 2024, is built to keep that detail attached to the work from intake to ship.
This guide covers what the feature is, the three ways a request gets created, how the customer record turns raw feedback into a priority you can defend, which integrations feed it on each plan, and the one gap that matters if your support runs on HubSpot rather than Intercom or Zendesk.
In this article
1.
2.
3.
4.
5.
6.
7.
8.
9.
What Linear Customer Requests Is
Customer Requests links a piece of customer feedback directly to a Linear issue or project. Each request captures the original message, who said it, when, and a link back to the source conversation, and it ties that feedback to a customer, an organization with its own record in Linear. That record carries attributes like revenue, tier, size, status, and owner. So a request is never just a note. It is a note with a customer, and a dollar figure, behind it.
The reason this design matters is aggregation. One issue can hold many requests. When ten customers ask for the same capability, you do not get ten disconnected tickets, you get one issue with ten requests stacked on it, and the customer records behind those requests add up into a number a product manager can rank against everything else in the backlog.
A backlog sorted by gut feel prioritizes the loudest voice. A backlog sorted by customer requests prioritizes the most demand. The feature exists to replace the first with the second.
How a Customer Request Links Feedback to an Issue
The mechanic is simple and worth being precise about, because the customer request and the issue are two different objects doing two different jobs.
The issue is the unit of work: the bug to fix or the feature to build, with a status that moves through your team's workflow. The customer request is the evidence attached to it: proof that a named customer wants this, with the quote and the source link intact. Engineers and designers working the issue can see every request on it, so the customer context travels with the work instead of getting lost in a triage handoff. Product managers, meanwhile, read the aggregated requests across issues to decide what gets built next.
This is the same separation that makes Linear Triage work, applied to feedback instead of incoming issues: keep the raw input and the committed work as distinct things, and decide deliberately how one becomes the other.
Three Ways to Create a Customer Request
Requests reach Linear through three doors, and most teams use all three.
- 1
Automatically, from a connected tool
When you link a Linear issue from Intercom, Zendesk, Front, Asks, or Salesforce, Linear creates a request and matches it to a customer by email domain. This is the highest-volume path, because it captures feedback without anyone remembering to log it. It requires the Business plan, or Enterprise for Salesforce.
- 2
From Slack
Turn a Slack message into a customer request directly from the channel. This works on the Free plan, which makes it the easiest way for a small team to start, especially if you run shared Slack channels with customers.
- 3
Manually, inside Linear
Add a request from the Customers section of an issue, from a customer page, or with the keyboard shortcut Ctrl R on macOS or Ctrl Alt R on Windows. This is how feedback from a sales call, a user interview, or an in-person meeting gets captured when it never passed through an integration. Create the customer first with the Cmd K command if they do not exist yet.
The Customer Record: Revenue, Tier, and Size
The attributes on the customer record are what turn a pile of feedback into a ranked list. When an integration is connected, these can populate automatically from the source tool, and they are always editable through the API.
Revenue
What the customer is worth, in units you configure. This is the attribute that lets you weight a feature by the money behind it rather than the raw count of requests.
Tier
Your segmentation, for example Enterprise, Mid-Market, and Startup. Filtering by tier lets you answer questions like what do our Enterprise customers actually want, separately from the long tail.
Size, status, and owner
Headcount, the customer's lifecycle status, and the internal owner of the relationship. Together they let you build views like requests from churned customers or requests owned by a given account manager.
Prioritizing by Demand, Not the Loudest Voice
With requests attached and customer attributes in place, prioritization becomes a filtering problem instead of an argument. You can order issues and projects by request count to surface the most-wanted work, and you can filter by tier or revenue to weight that demand by value.
The canonical view is a good habit to build: filter for a target tier, say Enterprise, then order by customer count. What rises to the top is the work that the customers you most want to keep are most asking for. Mark individual requests as important to separate the critical needs from the nice-to-haves, and subscribe to a customer page or a custom view to get notified when new requests land or when work those customers wanted ships. You can also export customer requests to CSV per customer, issue, or project when you need the data outside Linear.
Which Integrations Feed Customer Requests, and the Plan Each Needs
The intake source decides both how requests get created and which plan you need. Here is the shape of it.
| Source | Creates requests | Plan required |
|---|---|---|
| Manual (Ctrl R) | Yes | Free |
| Slack | Yes | Free |
| Intercom | Yes, real-time, syncs revenue and tier | Business |
| Zendesk | Yes | Business |
| Front | Yes | Business |
| Asks | Yes | Business |
| Salesforce | Yes, with custom-field triage rules | Enterprise |
| GraphQL API | Full create and update | Any |
If Your Support Runs on HubSpot, Not Intercom or Zendesk
Linear built its customer request intake around the support and CRM tools its own customers use most, and HubSpot Service Hub is not one of them. For the large number of teams whose support lives in HubSpot, that leaves a hole: a customer reports a bug in a HubSpot ticket, and nothing carries it into Linear where engineering works. Someone copies it by hand, or it never makes the trip.
This is the gap IssueLinker closes. It turns a HubSpot ticket into a linked Linear issue in one click, carrying the ticket context across, and it keeps the two in step in both directions: status flows from Linear back to the ticket, and comments and notes sync both ways so support can answer the customer without leaving HubSpot. It is worth being precise about what this is and is not. IssueLinker solves the intake half of the problem, getting customer-reported work from HubSpot into Linear as a tracked, synced issue. It does not populate Linear's native revenue-attributed customer record the way an Intercom connection does. If your priority is simply getting HubSpot ticket work into Linear and keeping the customer in the loop when it ships, that is exactly what it does. The full setup, and the other options, are in the Linear HubSpot integration guide and the best HubSpot to Linear integration roundup.
Get HubSpot ticket work into Linear, the tool Customer Requests can't reach
HubSpot Service Hub is not a native Linear customer request source. IssueLinker bridges it: a HubSpot ticket becomes a linked Linear issue in one click, with two-way status and comment sync so the customer hears back the moment the fix ships.
The Bottom Line
Linear Customer Requests fixes the oldest problem in product management: knowing what to build next without guessing. By keeping each piece of feedback tied to a customer, and each customer tied to a revenue and a tier, it turns prioritization from an argument into a filter. Start free with manual and Slack requests, move to the Business plan when you want your helpdesk feeding requests automatically, and if that helpdesk is HubSpot rather than Intercom or Zendesk, bridge the gap so the customer-reported work still reaches the team that has to fix it. The distinction the whole feature protects is worth remembering: track the work as issues, track the demand as requests, and never let the second get separated from the first.


