Which support tickets already have an engineering issue filed

Thursday morning, and the support lead has forty-one open tickets tagged bug in a Zendesk view she built herself. The engineering manager has a Linear triage board with nineteen issues in it. Both of them are in the same room, on a call that was scheduled for twenty minutes, trying to work out one thing before it ends: of those forty-one tickets, which ones already have an issue filed, and which ones are still sitting with nobody in engineering aware they exist.

She reads a ticket subject out loud. He searches Linear for a word from it. Sometimes he finds something. Sometimes he finds three things and has to read all three to work out whether any of them is the same problem. Sometimes he finds nothing, and neither of them is confident that means nothing exists, because the issue might have been filed by a different agent under a different phrasing three weeks earlier. Twenty minutes covers maybe nine tickets. The other thirty-two get a shrug and a follow-up thread.

This is not an unusual meeting. It happens at most companies that run support in one tool and engineering in another, which is most companies.

What Zendesk shows on its own

Zendesk is genuinely good at the support side of this. Views, filters and custom fields will get you a clean list of every open ticket carrying a bug tag, sorted by requester, by organisation, by age, by priority, by satisfaction score. Explore will chart that list over time: bug tickets by week, first reply time on them, how many are still open past fourteen days. If your agents are disciplined about tagging, that reporting is trustworthy and fast.

Where it stops is the part outside its walls. Zendesk knows what an agent typed into the ticket. It does not know whether a Linear issue exists unless somebody recorded that fact inside Zendesk, in a place Zendesk can query.

In practice that recording is uneven. The official Zendesk and Linear integration does link the two: an agent can create a Linear issue from a ticket, and the link is stored. But the link only exists on tickets where an agent used that path. On the ticket where an engineer filed the issue themselves after seeing it in Slack, there is no link. On the ticket where an agent pasted the Linear URL into an internal note, the URL is in the comment body, which is text, not a field. On the ticket where a second customer reported the same crash and the agent wrote "same as the one Priya raised Tuesday," there is nothing structured at all. Zendesk reporting works over fields and tags. Free text in comments is not something Explore can group by.

So Zendesk can tell you, with real precision, how many bug tickets are open. It cannot tell you how many of them are known to engineering, because for most of them that fact was never written down as data.

What Linear shows on its own

Linear is equally good at its own half. Every issue has a state, an assignee, a project, a cycle, labels, an estimate. Insights will show you throughput, cycle time, how the triage queue is trending, how much of this cycle is bug work versus feature work. If an issue was created from a Zendesk ticket through the integration, Linear holds the customer request attached to it, with the requester and the ticket link, and you can see how many customer reports are attached to a given issue. That is a real and useful feature and it does part of this job well.

The direction it runs, though, is issue-first. Linear can tell you which issues have customer requests attached. It cannot tell you which tickets do not have an issue, because tickets without an issue never entered Linear. They are absent, and absence is not something you can query for from inside the system the records are absent from. There is no view in Linear that lists the thirty-two things nobody filed.

The other limit is scope. An engineer filing an issue writes a title that means something to engineers: "429 from billing provider on retry path." The agent handling the customer wrote "Payments failing intermittently for Northwind." Both describe the same defect. Neither string contains the other. Linear search is fast and good, and it is still search over the words engineers chose.

Why the gap is structural, not a missing feature

Look at what each half of the evidence physically is.

The engineering half is a record. It has an ID, a state, a timestamp, an owner. Any tool with an API can read it and count it.

The support half, for the majority of tickets, is not a record. It is a sentence written by a person in a comment, in whatever words came to mind, in a field designed for a human to read later. Nobody was ever going to fill in a "linked engineering issue" dropdown at the pace support runs. And even where they did, the interesting judgement, whether this ticket is really the same defect as that issue or just adjacent to it, was never a dropdown to begin with.

This is why the answer does not fall out of either product's reporting. Zendesk Explore can group tickets by any field you give it, and this fact is not in a field. Linear Insights can slice issues every way you like, and the tickets you care about are not issues. A BI tool sitting over both, connected to a warehouse with both datasets loaded, hits the same wall from a third direction: it can join the rows that carry a link ID, and the rows where the link lives inside a paragraph of English are, to a SQL engine, just a text blob it can substring-match against and nothing more.

The gap is not that anybody built the reporting badly. It is that half the evidence was never structured, and reporting tools operate on structure.

What the join actually requires

Two things, and only one of them is mechanical.

The key. Where an explicit link exists, use it: the Linear issue ID stored by the integration, or a ENG-1174 style identifier pasted into a comment or an internal note. That is a clean join and it should be taken first, because it is certain. It will cover some meaningful fraction of the tickets and it will not cover most of them.

The judgement. For everything else, the connection has to be established by reading. Read the ticket subject and the customer's description. Read the open Linear issues in the same area. Decide whether "Payments failing intermittently for Northwind" and "429 from billing provider on retry path" are the same defect. That decision is not string matching and it is not fuzzy string matching either. It needs the two descriptions understood, and it needs a stated confidence, because sometimes the honest answer is "probably, worth an engineer confirming."

Any approach that only does the mechanical half will report thirty-two unfiled tickets when the true number is eleven, and will send engineering twenty-one duplicate issues.

Answering it with Skopx

Skopx connects to Zendesk and Linear along with nearly 1,000 other tools, and reads across them in one pass. The question goes into chat the way you would ask a colleague:

Go through our open Zendesk tickets tagged bug. For each one, check whether there's a matching Linear issue, using explicit issue IDs where they exist and reading the descriptions where they don't. Show me the ones with no match, and flag anything you're unsure about.

What comes back is a list in three parts: tickets with a confirmed linked issue and its current Linear state, tickets that match an existing issue by description with the issue named and a confidence noted, and tickets where nothing in Linear appears to cover the problem. Every line cites the ticket and the issue it was matched against, so the engineering manager can open both and disagree.

When that stops being a one-off and becomes the Thursday meeting, you can say so in chat and get a console over the same query. Skopx's Internal Apps builds one from a sentence: three columns, unfiled first, each row showing the ticket, its age, the customer, and the matched issue where there is one. It reads live from both tools every time somebody opens it, so it is never a stale export. And because an app can act as well as read, the unfiled column can carry a File in Linear button per row, which drafts the issue from the ticket and asks for confirmation before it creates anything. One click, one confirmation, one issue.

What this does not do

It does not replace the integration. If you want issues linked at the moment an agent creates them, install the Zendesk and Linear integration and let it do that job. This answers the question about the tickets where that did not happen.

It does not run on its own. Nothing here is scheduled, nothing watches your ticket queue overnight, and nothing sends an alert when the unfiled count crosses a number. The console is something a person opens.

It stores nothing. There is no new database of ticket-to-issue mappings accumulating on Skopx's side, no forms, no records created by the app itself. It reads your two tools at the moment you ask and shows you what it found. The single exception is the button, which writes an issue into Linear only when a person clicks it and confirms.

The matching is not certain. Descriptions written by two different people about the same defect can be matched with good confidence and not with proof. The output flags what it is unsure about specifically so a human makes the final call, and you should expect to overrule it occasionally.

And it is bounded by what your team wrote down. If a ticket's only description is "site broken, please fix" and nobody added detail, no amount of reading will connect it to anything. The judgement layer works on evidence. It does not invent it.

---

Skopx is $16 per seat per month on Team, including 2.3 million AI tokens per seat, or $5 for Solo. Connecting Zendesk and Linear takes a few minutes each, and the first version of this question can be asked in chat before you decide whether it deserves a console.