Is Linear Enough for Managing Customer Feedback?

Linear by itself isn't enough to manage customer feedback for most teams, though it gets closer than people expect. Linear tracks issues well, and its Customer Requests feature attaches who asked and what they said directly to an issue. What it doesn't do is notice feedback on its own. A request exists in Linear because a human created or linked it from a conversation in a source Linear already talks to. Feedback that arrives anywhere else, or that nobody thought to link, never becomes a request at all.

That gap is small for a team whose feedback already lives in Intercom, Zendesk, or a shared Slack channel, since those are exactly the sources Linear's own integrations cover. It gets real the moment feedback also shows up on sales calls, in a Discord community, in plain email, or scattered across three of those at once, because nothing catches the version that never gets typed into a linkable conversation, and nothing merges "SSO" and "single sign-on" and "the thing enterprise keeps asking about" into one count unless a person does it by hand. This shows up often enough as its own question that it has separate threads on r/Linear and r/SaaS asking almost the exact same thing independently.

Triage and Customer Requests, specifically

Two features do the real work, and both are more capable than "just an issue tracker" implies.

Triage is Linear's staging inbox. Per Linear's own docs, issues land there automatically when they're created through an integration (Slack, Sentry, and others), created from inside the Triage view, or filed by someone outside the receiving team, and they sit there until a person accepts, declines, merges, or snoozes them. It is a real inbox, and it's a better one than most trackers ship with.

Customer Requests is the newer piece, and the one that addresses "feedback" rather than "issues." A customer in Linear is an organization, with attributes like tier, revenue, and size that can sync in from Salesforce. A request is one piece of feedback from one customer, attached to an issue, holding the original message and a link back to where it came from. Several customers can stack requests onto the same issue, which is what turns "sales keeps mentioning this" into "11 requests, 4 enterprise" without anyone building a spreadsheet.

Requests get created three ways, per Linear's docs: automatically from Intercom (on issue creation or linking, with customer attributes synced live), from Zendesk and Front (when a conversation is linked to an issue), from Slack (optionally, when an issue is created from a message), from Linear Asks, from Salesforce cases, or manually by anyone with access to the issue. That list is comprehensive for the tools on it and silent about everything else.

The two limits that compound

Two limits matter more than the rest, and they compound.

Capture depends on a human doing something first: a create-or-link action, from inside a source Linear already integrates with. Linear itself doesn't claim otherwise. That means the offhand line on a sales call ("we'd probably switch if you had SAML"), the recurring complaint in a Discord server, and the reply-all email thread nobody forwarded into Intercom are all invisible to Customer Requests, permanently, unless someone manually types them in after the fact.

Merging duplicates is manual too. Per Linear's docs, Linear will prevent duplicate customer records from being created in most cases, but deciding that three differently worded requests belong on the same issue is still a judgment call a human makes every time. That's fine at ten requests a month. At a hundred, it's a part-time job that quietly stops happening, and the count on an issue understates how many people asked, because half the requests never got attached.

Neither gap shows up as a bug. They show up as an issue that has three requests on it when it should have twelve, and a channel your team swears customers complain in that has zero requests filed from it all quarter.

Corvel Labs, eight months in

Marcus Aldana runs support at Corvel Labs, a 65-person devtools company. Corvel's engineering team lives in Linear, and Marcus turned on the Zendesk integration for Customer Requests eight months ago. It works exactly as advertised for tickets: a support rep links a Zendesk conversation to an issue, and the requester and their account show up on it automatically.

The gap showed up in his Monday planning notes:

Marcus, in the roadmap doc: "Data export to Snowflake" has 6 requests on it in Linear, all from Zendesk. But three different AEs have told me it's come up on calls too, and I know at least two people asked about it in our Discord. None of that is attached anywhere. When I bring 6 to the eng lead, he correctly points out that 6 requests isn't obviously worth a sprint. It's probably closer to 15, but I can't prove it without re-listening to call recordings.

Nothing in his setup is misconfigured. Zendesk-sourced feedback is doing exactly what Customer Requests promises. The calls and the Discord messages are simply outside what the feature was built to see, and reconstructing them by hand is the part that doesn't scale past a handful of issues a month.

Deciding if this is enough for you

Linear plus Customer Requests is a reasonable stopping point if most of your feedback already arrives through Intercom, Zendesk, Front, or a Slack channel someone reliably links from, and your monthly request volume is something one person can dedupe by eye. A lot of small teams are exactly there, and adding another tool on top of that would be solving a problem they don't have yet.

The point to add a layer in front of Linear is when feedback routinely arrives somewhere Linear doesn't watch (calls, Discord, community forums, plain email) or when the manual linking and merging has become a job someone does badly under time pressure instead of well. That's the gap Modem sits in: it listens across Slack, Discord, support tools, email, and call transcripts, matches different phrasings of the same ask into one counted topic before anything reaches Linear, and files or attaches the Linear issue itself, with the requester's account and quote already on it. It doesn't replace Customer Requests or Triage; it's the capture and dedup step that decides what shows up in them. Modem is what we build, and that doesn't erase how well the Linear-only baseline above already covers plenty of teams. A wider comparison of what else can fill this role sits in the best tools to turn customer feedback into Linear issues, and the mechanism underneath Modem's dedup is covered in what a customer context graph is.

The short answer again

Linear is enough for issue tracking, full stop, and Customer Requests makes it a legitimate place to hold customer-linked feedback too, as long as that feedback shows up through a source Linear already talks to and someone keeps up with linking and merging it. It stops being enough exactly at the edges of that sentence: feedback from an unwatched channel, and dedup work that outgrows one person's spare time. Most teams don't hit both limits on day one. When an issue's request count feels lower than what you actually hear from customers, that mismatch is the signal, not a coincidence.