Linear for customer support: turn tickets into bug reports and tell customers when it's fixed

A customer reports a bug on Monday. Your agent posts it in the developers' channel, someone opens a Linear issue, and the ticket sits. By Friday 20 more customers have reported the same bug.

The fix went out Wednesday, and nobody told them. This guide shows how to hand bugs to Linear, keep duplicates on one issue and tell customers when the fix is live.

The short version

• Search before you raise. Look for an existing Linear issue first, by key or by words from the title.
• Write the report for a developer. Steps to reproduce, expected and actual result, environment, impact. No customer names or contact details.
• One bug, one issue, many tickets. Every ticket about the same bug links to the same issue. The count of linked tickets tells engineering how big it is.
• Let the status come back to the ticket. Agents shouldn't have to check Linear or paste updates by hand.
• Tell the customer when the fix is live. Done in Linear and live for your customers can be 2 different days.

Deskwoot, the help desk we build, handles the linking and the status part with its Linear integration. Everything else in this guide works with whatever tools you use.

Why bugs get lost between the help desk and Linear

Support lives in the help desk and engineering lives in Linear. A bug report crosses from one to the other once, and after that the 2 records drift apart.

Nobody owns the way back

The agent who raised the issue moves on to the next 40 tickets. The developer closes the issue and moves on too. Unless something carries the status back to the ticket, the customer finds out by trying again.

Linear describes how its own support team avoids this in a post on how its Customer Experience team works in Linear. When an issue is marked Done, the linked support conversation reopens with a note, and the support team then contacts the customer to share the fix and confirm it works.

Status updates by hand

Without a link, someone in support opens Linear every morning, checks a list of issues and pastes the status into tickets. It takes time, it gets skipped on busy days, and it is wrong by the afternoon.

The same bug, 20 times

When agents can't see what engineering already knows, each one raises their own issue. Developers then spend time merging duplicates, and the real size of the problem stays hidden across 5 issues that each show 1 or 2 reports.

Before you raise an issue

Not every ticket that says "it's broken" is a bug. Engineering stops trusting support's reports fast if half of them turn out to be questions about how a feature works.

3 questions to ask first

1. Can you reproduce it? Try it yourself, on the same plan, browser or app version the customer uses.
2. Is this how it's meant to work? Check your help center and product docs. If the behavior is documented, it's a feature question, and the customer may need a better explanation.
3. Does an issue exist already? Search Linear by the words a developer would use in a title, such as "export" or "CSV", and by the screen where it happens.

If the third answer is yes, link the ticket to that issue and add anything new as a comment. Raise a new issue only when nothing matches.

What makes a bug report developers can act on

Mozilla's bug writing guidelines were written for Firefox, and they hold up for any software team. The summary should explain the problem, not your suggested fix, and the report should keep facts apart from guesses.

A template your agents can copy

• Title: what goes wrong and where. "CSV export drops the last row when a filter is set" beats "Export broken".
• Steps to reproduce: numbered, as short as possible, and whether it happens every time or only sometimes.
• Expected result: what should have happened.
• Actual result: what did happen, with the exact error text or a screenshot.
• Environment: plan, browser or app version, device, and the time it happened so developers can find it in the logs.
• Impact: how many customers reported it, whether they are blocked, and any workaround you found.
• What support already tried: cleared cache, other browser, other account.

In Linear's own CX post, bugs its support team files from Slack carry the customer's exact words and a link back to the original conversation. Add both to your reports too. The quote shows developers what the customer saw, in their language.

Leave personal data out

Whatever you paste into Linear stays in Linear. When a customer later asks you to delete their data, your help desk can't reach that copy.

So write "a customer on the annual plan" instead of a name, and leave out email addresses, phone numbers and order numbers that developers don't need. If they need to look at the account, they can follow the link back to the ticket.

One bug, one issue, many tickets

The most useful habit in this whole guide: every ticket about the same bug links to the same Linear issue. Developers get one place to work, and you get one place to look when the fix comes.

Let the count speak

An issue with 20 linked tickets argues for itself in a planning meeting. Ask agents to add a short comment on the issue when a new report brings something new, such as another browser or a customer who is fully blocked.

Skip comments that only say "+1". The linked ticket already counts.

Duplicates that get through anyway

Some will. In Linear, a developer marks one issue as a duplicate of the other. Since May 2026 that gives the issue its own Duplicate status, and Linear moves its attachments and customer requests to the original, as Linear's changelog explains.

When you see a ticket's issue turn Duplicate, link that ticket to the original issue as well. Otherwise the ticket follows an issue that nobody will work on again.

Where new reports land in Linear

A Linear team can switch on Triage, a special inbox for that team. Issues created by an integration, or by someone outside the team, land there first. Someone on the team accepts, declines, marks as duplicate or snoozes each one.

Ask your developers whether they use Triage and who checks it. A clean report with the impact on top gets accepted faster.

Keeping customers informed without pasting updates

Customers don't need every status change. They need to know that you confirmed the bug, that someone is on it, and that you will write when it is fixed.

Match Linear statuses to what the ticket does

Linear's default statuses run Backlog, Todo, In Progress, Done and Canceled, and each team can add its own. A simple mapping for the ticket side:

• Triage, Backlog or Todo: the ticket waits on development. Pause its SLA clock, so it doesn't breach while engineering works.
• In Progress: nothing to tell the customer yet.
• Done: the ticket comes back to an agent, who checks that the fix is live.
• Canceled or Won't fix: the agent writes an honest answer, with a workaround if there is one.
• Duplicate: link the ticket to the original issue and keep waiting.

Done is not always live

Linear says it plainly in its Releases docs: an issue's Done status does not always mean the fix has reached your customers. The pull request may sit on staging, or a mobile fix may wait for the next app release.

So the person who gets the ticket back checks the fix in production, or asks the developer, before writing to the customer.

How long customers might wait

Ask your developers for their targets and share them with your team. Linear publishes its own in a post on its zero bugs policy: 48 hours for high priority bugs and 7 days for the rest.

Your team's numbers will differ. They help agents set honest expectations, but a target is no date to give a customer.

The message when you confirm the bug

"Thanks for the clear description. We can reproduce it, and our developers have it on their list. I'll write to you here as soon as the fix is live, so you don't need to check back."

Give a date only when your developers have committed to one. A missed date costs more trust than no date.

The message on fix day

"Good news: since this morning the CSV export includes every row again, filters too. Could you try once more and let me know it works for you? Thanks for reporting it, your description helped us find it quickly."

Name the problem the customer reported and ask them to confirm. A reply of "works now" closes the ticket for real.

How it works in Deskwoot

Deskwoot is the help desk we build. With Linear connected, agents raise or link issues from the ticket, and the issue's status comes back to the ticket on its own.

Set it up

1. Switch on tickets under Settings > Tickets. Tickets and Linear come with the Enterprise plan.
2. Click Connect Linear under Settings > Integrations > Linear. You need the Manage integrations permission.
3. A Linear workspace admin allows Deskwoot and picks the teams it may see. Then choose the Team for new issues.

Agents need no Linear account, because Deskwoot joins as an app. The Linear help guide shows each step.

What your agents get

• Raise or link from the ticket. Link an issue by its key, such as ENG-123, or click Raise issue. Draft bug report with Copilot writes the report. Copilot is told to leave out the customer's name and contact details, and the agent checks it.
• The status on the ticket. Each status change writes a line in every linked ticket. A search for the key finds every linked ticket, your list for fix day.
• 2 ready rules. One sets a ticket status when an issue is raised or linked, such as a status that pauses the SLA. The other hands the ticket back with a note to whoever linked the issue once it is done.
• Known bugs. When a customer reports a problem, Copilot searches the open issues of the team for new issues and of the teams your tickets link to. It is told to name a fix date only when the issue holds one that is still ahead.

Customers never see the issue or its status lines.

What it costs

Enterprise is $12 per agent a month, or $9.60 billed yearly, so 10 agents pay $120 a month. Connecting Linear costs nothing extra (see pricing). Hacker, Startup and Business don't include it, and each Deskwoot workspace connects one Linear workspace.

Try it on one bug

Pick the open bug with the most tickets behind it. Sign up, connect Linear, link those tickets to its issue and save the ready rule for done issues. The 7 day Enterprise trial needs no card, covers up to 30 seats including yours and includes Linear.