Linear: When Does Customer Feedback Become Developer-Ready Work?

Linear's Triage documentation describes Triage as a review inbox outside the normal workflow. Integration-created issues can enter it when it is enabled, subject to intake settings and overrides.

That is a useful boundary. A customer's report can reach Linear without yet being admitted to the work engineers do day to day. It also means that "the feedback is in Linear" describes only the first event in a longer chain.

This note follows Linear customer feedback from support to engineering. It is an operator analysis, not a verdict on Linear. We found no public evidence of a Linear-wide problem with customer feedback, and Linear already ships a good deal of the machinery. Our argument is narrower. By developer-ready we mean that the relevant customer evidence has reached a responsible person who has recorded a decision: investigate, link to existing work, ask for evidence, plan, defer or explain. For one segment, non-emergency suspected defects escalated from support, our hypothesis is that a short, sourced summary of the customer's task and its consequence may improve the first engineering decision.

What we looked at

We read Linear's documentation for Customer Requests, Triage, Intercom, Front, Zendesk, GitHub and Releases, two Linear accounts of its own practice dated 30 October and 6 November 2025, and Clay's customer story, all retrieved on 5 November 2026. We did not use a workspace, test an integration, see any support data or send any outreach. Documentation shows supported behaviour, not how many teams use it or how well it works. Most help pages show no date, and the practice accounts and customer story are self-reported and selected. The events table and the test are our analysis.

One report, five events

A customer's problem passes through several events that are easy to treat as one. The table is our model, not a list of Linear statuses, and each team sets its own policy.

Not every report passes through all five events, and a justified explanation or deferral may need no code change. A report can describe a suspected defect, a feature need or a usage question, and each has a different valid outcome. A defect needs expected and observed behaviour and a way to reproduce it. A feature need needs the customer's task and workaround more than their proposed solution. A usage question may need only an accurate answer or a documentation fix. Urgent incidents and security reports keep their established route, and nothing here applies to them.

What Linear already provides

A call for source links, triage actions or release awareness would duplicate existing product. The pieces that matter here:

So the missing piece is not a feedback inbox, source links or release awareness. The Front and Zendesk pages say new issues go to Triage if the team has enabled it and otherwise to the first backlog status, so check which applies. We make no pricing claim, so recheck the plan.

Two paths, three accounts of practice

Linear's customer experience account, dated 6 November 2025, describes separate bug and feature-request templates, bugs going to an engineering triage queue and feature requests to a product triage queue, and a weekly rotating goalie who makes the final triage decision after the automated pass. For follow-up, a linked conversation reopens when the pull request merges, and the support team then contacts the customer directly.

Linear's planning account, dated 30 October 2025, says feature requests go to product triage, related evidence gathers in candidate projects, and candidates are ranked by associated customer requests and revenue impact before the team chooses using impact, quarterly goals and deliberate bets. Bugs are prioritised by severity and not through that process. We read this as one team's description and not as a formula. Request counts are not a representative survey, repeated reports from one account are not independent observations, and revenue attached to requesting accounts is not revenue that shipping a feature would create. Those are our cautions, not defects in Linear's method.

Clay, in a Linear customer story, describes bug reports from Slack, a standard form and a support tool reaching a single Bugs Team through Linear Asks, which lets people without a Linear seat create issues. A support engineer removes duplicates, sets priorities and routes bugs, and a weekly goalie on each engineering team is notified and owns the bug. It shows that collecting, categorising and owning are three separate jobs. The story also says comments sync across Slack, Intercom and Linear, while Intercom's documentation says notes left in Intercom do not sync to the Linear issue. We take Clay as reported practice, use Intercom's page for generic behaviour and use none of Clay's figures.

All three are selected, self-reported accounts and none compares workflows.

The return path is more than one event

Per Intercom's page, when a linked issue is completed or cancelled, Linear posts an internal note and reopens the conversation by default, with separate settings for completed issues, cancelled issues and new comments. The Linear Zendesk integration and the Front integration document the same pattern with their own settings, and Zendesk and Front agents need Linear accounts where Intercom users do not. So state which integration and which event a team is responding to.

A reopened conversation is a prompt for a person. A cancelled issue can mean a duplicate, a declined request or a decision to explain existing behaviour, so it should not produce an unreviewed "fixed" reply. The same applies to Done. GitHub's default moves linked issues to Done on merge, and Linear's Releases page says Done does not always mean delivered. A good reply can offer a workaround or explain a deferral. It does not have to promise delivery.

The handoff worth testing

Our candidate is the handoff from support to engineering for a suspected defect. A technically detailed report can leave out which customer task is blocked, and an urgent one can leave out the evidence needed to reproduce the problem. Our hypothesis is that a concise statement of the task and the consequence, drawn only from evidence already in the conversation, may improve the engineer's first decision where that context is buried. It may add little where reports already carry it, and nothing where the missing piece is technical evidence. The Intercom and Zendesk pages say Linear Agent can draft an issue title and description from a conversation, so read what your drafts already contain before testing anything.

A test with one change

Question. Among non-emergency suspected-defect escalations from support into Linear, does adding a short, source-grounded customer-impact summary raise the share that receive a correct, owned engineering disposition within a predeclared interval?

Segment. Consenting support and engineering groups with the same working intake route, a named receiving owner and genuine non-emergency suspected defects. The counting unit is the escalation episode, not each issue. If software splits one episode into several issues, the denominator does not grow.

Audit first. Read recent escalations before assigning anyone. If they already carry the customer's task and consequence prominently, there is no contrast and the test should not run. The live walkthrough of the route, plan, settings and least privileged access is a condition for running the test, not a reason to hold back this proposal.

Control and treatment. The control is the existing truthful report, with its source links and technical evidence. The treatment is the same report plus one concise summary of the customer's task and the observed consequence, drawn only from evidence already available, with unknown impact stated as unknown. A support agent checks each summary against the source, and that labour is counted. If a model drafts it, the implementation is frozen for the study. Routing, ownership, technical fields, priority policy, links, training, reminders, access, duplicate detection and AI settings, and review cadence stay equal, and nobody interviews a customer only for the treatment. The test estimates the combined effect of adding and checking the summary, including any additional attention. It does not isolate the effect of its informational content.

Main outcome. An episode counts when a reviewer, working to a rubric set in advance, finds that the documented decision identifies the right canonical record or next action, keeps the customer's attribution and names a responsible next owner. Valid decisions include investigation, a verified duplicate, a planning referral, an evidence-based explanation or a precise request for missing evidence. A generic "needs info" or an unsupported rejection does not count. The measure is episodes with a verified correct, owned disposition within the interval, divided by all assigned eligible episodes. The clock starts at the same documented escalation event in both groups, not when an engineer chooses to open an issue. A known absence of a qualifying decision by the deadline is a non-success. An episode whose outcome nobody could observe is missing evidence, reported separately with bounds. This is our measure, not Linear's.

Assignment and analysis. Randomise receiving squads or stable support-engineering groups, and keep related episodes together where agents, reviewers or canonical defects are shared. Analyse as assigned with cluster-aware uncertainty. With too few independent clusters, run a descriptive feasibility study and claim no causal uplift. We set no sample size, interval or limit from public sources.

Ordinary work comes first. Urgent incidents and security reports follow their usual route outside the study. Nobody inflates urgency, rejects quickly or accepts into the backlog to help the numbers. The full plan, with the rubric and the measurement traps, is in the methodology appendix.

Reading the result.

• Quicker acknowledgement or more issues, but no more episodes with a verified correct, owned decision: no benefit shown.
• More correct decisions, but inaccurate summaries, misrouting or inflated priority outside the predeclared limits: do not expand.
• Gains accompanied by substantial extra support effort checking summaries: assess whether the benefit survives the combined workload.
• No detectable difference: inconclusive, not equivalence.

We would expand the change only if the share of episodes improves by a practically worthwhile amount, the missing-data checks do not erase the inference, and error and workload stay within limits set before assignment. A good result would justify this summary for this route and segment. It would not show faster fixes, greater feature demand, better retention or an edge over another provider.

The case against, and the decision

• The reports may already carry the context. Then there is no contrast to test.
• Linear's own drafts may already supply it. We have not observed them.
• The real constraint may sit elsewhere. Missing reproduction evidence, a queue nobody reviews or a customer who cannot see progress are not fixed by a summary.
• A faster first decision is not a better one. If reviewers reward speed, the test rewards premature rejection.

What we do not know: how often source context is lost between support and engineering, whether Linear's drafts already carry the customer's task, and which handoff dominates delay.

The decision follows. Diagnose before adding anything. If reports lack reproduction evidence, start there. If nobody reviews the queue, fix ownership first, as Clay's goalie rotation and Linear's own do. If requests overlap without forming clear work, look at linking and candidate projects. If "fixed" replies go out before availability, check release evidence before notifying customers faster at merge. If reports reach engineers without the customer's task and its consequence, a short sourced summary is a reasonable starting hypothesis to test. Improve the demonstrated handoff, not the number of reports.

Next step

Product Garage works through live product and go-to-market decisions with experienced operators. This note takes one of those decisions in public, while the thinking is still provisional.

Subscribe to Garage Dispatch to get the next working note.

FAQ

Does a customer request in Linear mean engineers will build it? No. Linear's documentation describes requests as feedback linked to an issue or project, and Triage as the place to accept, decline, merge or snooze. Attached evidence informs a decision, which can be to defer or to explain existing behaviour.

Does Done in Linear mean the customer has the fix? Not necessarily. GitHub's default moves a linked issue to Done when its pull request merges, and Linear's Releases page says Done does not always mean delivered to customers. Check release evidence for the affected customer.

Does a reopened support conversation mean the customer has been told? No. The Linear Intercom integration posts an internal note and reopens the conversation by default when an issue is completed or cancelled. Someone still has to write an accurate reply, and a cancelled issue may be a duplicate or a declined request.

Should all feedback become a developer issue? No. In our model a report can be a suspected defect, a feature need or a usage question, and a usage question may need an accurate answer or a documentation fix. Urgent incidents and security reports need their established route.

What would the test prove? Only whether adding a short customer-impact summary changes the share of escalation episodes with a verified correct, owned decision, for one route and segment. It would not show faster fixes, feature demand, product-wide retention or an advantage over another tool.

Methodology appendix

This appendix supports the working note "Linear: when does customer feedback become developer-ready work?". It is a proposal, not a report of a test that has been run. No sample size, interval, observation window, worthwhile improvement, error limit or workload limit is specified, because the public sources give no baseline to set them from.

The question and what it covers

For non-emergency suspected-defect escalations already flowing from support into Linear, does adding a short, source-grounded customer-impact summary raise the share of episodes that receive a correct, owned engineering disposition within a predeclared interval? This tests how evidence is presented at one handoff. It is not a test of a new Linear feature, of AI against humans, of whether all feedback should reach developers, of faster fixes or of Linear against another provider. Feature needs and usage questions would need separate tests.

Segment and screen

• Segment: consenting support and engineering groups that share one functioning intake route, a named receiving owner and genuine non-emergency suspected-defect escalations.
• Unit: one customer problem per escalation episode, defined by rules set before assignment. If software splits one episode into several issues, the denominator does not expand.
• Feasibility: the exact integration, plan, enabled settings and receiving view are confirmed, the least privileged intended participant can open the linked records, and a documented escalation event exists to start the clock.
• Exclusions: urgent incidents and security reports, which keep their established route; groups with no named receiving owner; and groups whose reports already carry equivalent impact context prominently.
• Audit before assignment: read recent escalations and record where the customer's task and consequence appear today, who writes them and whether engineers use them. If that contrast does not exist, do not run the test.
• Feasibility versus assigned-group analysis: groups that fail the screen are excluded before assignment and reported, with reasons, as a feasibility finding. They are not outcome data. A group that is assigned and then abandons the format, changes route or loses access stays in its assigned group.

Conditions held equal

• Control: the existing truthful report, including source links and technical evidence.
• Treatment: the same report plus one concise summary stating the customer's task and the observed consequence, derived only from evidence already available. Unknown impact is stated as unknown.
• Held equal: routing and ownership configuration, technical fields, priority policy, links, training, reminders, support access, AI and duplicate-detection settings and review cadence. No customer interview is held only for the treatment.
• Fidelity: the support agent checks each summary against the source. Corrections are retained and the labour is counted.
• Model-drafted summaries: freeze the implementation, prompt and settings for the study, retain corrections and keep other agent functionality equal. Do not promise exact determinism from a hosted model. Record any software or configuration change that could affect the comparison.
• Mechanism limit: the design estimates the combined effect of adding and checking the summary, including any additional attention it attracts. It does not isolate the effect of the summary's informational content. A length-matched neutral addition is an alternative design that could be chosen before the study if isolating content matters more than the operational question.
• Record of the assigned format: keep a stable copy of each version, and treat later changes by a group as implementation data.

Outcome definition

• Correct, owned disposition: a documented decision, reviewed under a rubric set before collection, that (a) identifies the right canonical record or next action, (b) preserves the customer's attribution and (c) names a responsible next owner. Valid dispositions include investigation, a verified duplicate, a justified product-planning referral, an evidence-based explanation of existing behaviour or a precise request for necessary missing evidence. A generic "needs info" or an unsupported rejection does not qualify.
• Primary outcome: eligible escalation episodes with a verified correct, owned disposition within the interval, divided by all assigned eligible episodes. This is our measure, not Linear's.
• Interval: it starts at the same documented escalation event in both groups, not when an engineer elects to open an issue, and is set from the baseline audit.
• Components reported separately: canonical record or next action, attribution and owner. The composite must not hide where failures occur.
• Review: independent, with assignment hidden where practical. The rubric allows uncertainty and useful clarification. It must not reward fast rejection, inflated urgency or unnecessary acceptance into the backlog. Record any correction of a supposedly valid disposition during a fixed follow-up interval.
• First decision versus customer outcome: a useful initial decision is an appropriate triage result, and the customer's problem can remain unresolved. Record both facts.

Design and analysis

• Randomise by cluster. Randomise receiving squads or stable support-engineering groups where feasible. Shared agents, reviewers or canonical defects can contaminate the groups, so audit those relationships first and choose a cluster that keeps related episodes together. With too few independent clusters, run a descriptive feasibility study and make no causal uplift claim.
• Baseline first. Observe current work, then set the interval, observation window, sample size, smallest worthwhile improvement, error limit and workload limit from real variation. Do not invent them from public sources.
• Predeclare the rubric, each component, the rules for split, merged and re-routed episodes, holidays and periods with no eligible work, the missing-data assumptions, and the error and workload limits.
• Analyse as assigned with cluster-aware uncertainty. Report actual exposure separately.
• Keep in the assigned group: abandonments, integration failures, re-routing and duplicate links.
• Known absence versus missing evidence. A known absence of a qualifying disposition by the deadline is a non-success. An episode whose outcome nobody could observe is missing evidence, reported separately by group with bounds or sensitivity analyses. Do not compare only completed or accepted issues.
• Expansion rule. Expand only if a practically meaningful improvement is supported, the error and workload limits hold, and the missing-data sensitivity does not erase the inference. More tickets, labels, generated words or immediate acknowledgements are insufficient.
• What it cannot show. The test estimates the effect of this summary for this route and segment. It cannot show faster fixes, greater feature demand, better retention, that generated context is faithful in general, which part of the summary drove any effect, or that Linear beats another provider.
• Reading a small null result. A small null result is inconclusive, not equivalence.

Protection of ordinary work

• Urgent incidents and security reports follow their established path outside the study.
• Nobody inflates urgency, rejects quickly, accepts into the backlog or splits an issue to improve a number.
• A declined request, or an explanation of existing behaviour given with reasons, is a valid disposition.
• A group that keeps its current report format is a legitimate outcome and is reported separately.
• Rescue and pause rules for a serious problem are identical in both groups and set before assignment.

Measures

Workload worksheet (ours)

• Observe a few comparable escalations before any change. Record support time to write the report, engineering time to the first decision and the number of questions engineers ask back.
• Record the same items for each assigned group over the observation window, with the same rules in both groups.
• Include the time spent checking and correcting summaries.
• Count work on episodes that did not qualify, including failed setups.
• Where engineer interruptions fall but support labour rises, report both and the combined effect.
• Keep time cost apart from any plan, AI credit or subscription cost.
• Report severity and context as well as counts.

Implementation gate

These are checks to run before real groups, not defects reported in Linear.

• Trace one real bug and one feature need from source to current disposition. Which links, quotes, customer associations and decisions survive?
• Confirm the exact integration, plan, enabled settings, template overrides and receiving view, and test access with the least privileged relevant participant. Linear's pages say Front and Zendesk users need Linear accounts and Intercom users do not.
• Check whether an existing issue can be linked before another is created, and whether merging a duplicate preserves source attachments and customer requests, as Linear's Triage page says it does.
• Inspect one wrong account match, one unavailable source attachment and one ambiguous duplicate. Do not assume they are frequent. Find out whether they occur.
• Identify the person responsible for the next action and the person responsible for customer communication. They need not be the same.
• Review how an existing-behaviour answer, a declined request, a cancelled duplicate and a shipped fix are each worded externally.
• Check what happens at pull request merge, production deployment, mobile release and staged rollout. Does support know which event it is responding to?
• Observe one agent-drafted issue, compare its statements with the source evidence and measure the review effort.
• What the gate limits. It limits execution. It does not prevent publication of a clearly labelled proposal.

Measurement traps