Watari maps a Zendesk or Intercom support ticket to a Linear issue by first extracting a structured bug — severity, repro steps, expected-vs-actual behavior, customer impact — then running duplicate detection, confirming code locations against your GitHub repository, and finally syncing the completed record to Linear as a routing destination. The Linear issue arrives pre-filled; your engineering team never rewrites a ticket.

Why raw tickets make bad Linear issues

Support tickets are written for empathy, not reproduction. When a support agent pastes a Zendesk thread into Linear manually, the resulting issue almost always omits repro steps, conflates symptom severity with customer frustration, and carries no code-location context. The engineering team then spends time in triage that should go toward fixing.

The structural problem is that the two formats serve different jobs. A Zendesk ticket answers "what is the customer experiencing?" A Linear issue needs to answer "what is broken, how do I reproduce it, and how severe is it?" Bridging that gap by hand — a Slack message, a copy-paste, a half-filled template — drops information at every step.

Three concrete failure modes appear repeatedly in teams that rely on informal escalation:

Severity mismatch. The customer wrote "urgent" because they were frustrated; the Linear issue inherits that word without a structured severity field. Engineering triages it as P1 when it is P3.
Missing repro steps. The ticket thread has enough context to reproduce the bug, but the person filing the Linear issue summarised rather than extracted. The engineer assigned to the issue has to go back to Zendesk.
Duplicate filing. Three support agents independently notice the same Zendesk symptom over two days and file three Linear issues under different titles. Each gets assigned to a different engineer.

None of these failures are human error — they are predictable consequences of a workflow that asks people to manually transform unstructured prose into structured engineering records.

What structured extraction does before the Linear sync

Structured extraction is the prerequisite step, not an optional add-on. Before Watari creates anything in Linear, the pipeline runs a ticket-to-bug extraction stage that pulls consistent fields from the raw ticket:

Title — a concise, engineer-readable summary
Severity — P1 through P4, derived from signal in the ticket, not copied verbatim from the customer's language
Repro steps — ordered, numbered, drawn from the conversation thread and any attached logs or screenshots
Expected vs. actual behavior — the delta that defines the bug
Customer impact — how many users are affected and what workflow is blocked
Customer's original words — preserved verbatim so context is never lost

This extraction step is gated by a confidence threshold. If the extraction model cannot produce a high-confidence structured record from a ticket, the ticket does not become a Mapped Bug and nothing syncs to Linear. That threshold is what separates a meaningful Linear issue from noise.

Duplicate detection runs immediately after extraction. When a new structured bug arrives, Watari compares it against existing bugs using vector similarity over the same pgvector index that powers code mapping. If the incoming bug matches an existing Mapped Bug above the similarity threshold, it is merged rather than filed as a new issue. The same Zendesk symptom reported by three different customers on three different days becomes one Linear issue with an updated customer-impact count — not three separate issues clogging the backlog.

CODEOWNERS-aware assignment and what it changes

Once extraction and duplicate detection clear, Watari maps the structured bug to specific files and functions in your GitHub repository using tree-sitter chunking and a pgvector HNSW index. That mapping step produces code_locations — the specific files and functions most likely responsible for the bug.

Those code locations feed directly into assignment. Watari reads your repository's CODEOWNERS file and routes the Linear issue to the team that owns the implicated code — not to a general triage backlog. An issue touching your payment flow lands with the payments team. An issue in the API gateway lands with platform engineering.

The practical effect is that Linear triage time drops to near zero for Mapped Bugs. The issue arrives with:

Structured severity and repro steps from the extraction stage
Named files and functions from the mapping stage
The owning team pre-assigned from CODEOWNERS
A link back to the originating Zendesk or Intercom ticket
A draft pull request already open in GitHub

The engineer assigned to the issue does not need to read the original ticket, guess at severity, or figure out where to start. They review the draft PR.

See the routing and notifications guide for how Linear assignment is configured once the integration is connected.

How to connect Zendesk or Intercom to Linear in four steps

The setup path is linear (no pun intended): connect your support tool, install the GitHub App, add Linear as a routing destination, and confirm the first sync.

Step 1: Connect Zendesk or Intercom

Go to Settings → Integrations and connect your support tool. Zendesk and Intercom both connect via OAuth — you authorise Watari's access and the webhook registration happens automatically. Watari reads the ticket subject, body, full conversation thread, attachments, and provider metadata. Internal agent notes are not read.

For a full walkthrough including sandbox recommendations for teams that want to test before touching live tickets, see the support tools connection guide.

Step 2: Install the GitHub App

Install the Watari GitHub App on your GitHub organization and select the repositories you want Watari to index. The App requests read access to your code for mapping and write access to open draft pull requests — nothing broader. Watari clones the selected repositories, parses supported source files with tree-sitter, and builds the vector index in the background. For most SaaS codebases, the first index completes within a few minutes.

CODEOWNERS routing requires your CODEOWNERS file to exist in the repository root or .github/ directory. Watari reads it automatically once the App is installed.

Step 3: Add Linear as a routing destination

In Settings → Integrations, connect Linear using the OAuth flow. Once connected, you configure which Linear team and project incoming Mapped Bugs sync to. You can also set per-team overrides — bugs owned by a specific CODEOWNERS team can route to a specific Linear team rather than the default.

Slack and Jira can be added in the same flow. All three are routing destinations that receive structured output after the Mapped Bug is created — they never affect the billing meter. As documented in the Mapped Bug meter, every action Watari takes after a Mapped Bug is recorded — Linear sync, Jira sync, Slack notification, RCA publish — is bundled into your plan. The routing layer is a free byproduct of the Mapped Bug.

Step 4: Watch the first Mapped Bug sync

Once both the support tool and GitHub App are connected, new tickets begin flowing in via webhook. When a ticket passes both confidence gates — extraction confidence and code-location confidence — a Mapped Bug is created and synced to Linear automatically.

The first Linear issue you receive from Watari will look different from what your team has filed manually. It will have a structured title, a P1–P4 severity, numbered repro steps, a named file and function in the body, and an assignee from CODEOWNERS. The originating Zendesk or Intercom ticket is linked. The draft PR in GitHub is linked.

If your team wants to observe the pipeline before committing to live ticket processing, connect a Zendesk sandbox subdomain or an Intercom test workspace at Step 1. The pipeline runs identically against test traffic.

The billing mechanic that makes routing free

One clarification worth making explicit: the Linear integration does not cost extra. Watari bills on a single unit — the Mapped Bug — and every downstream action is bundled. See plans and pricing for current tier details.

The implication for support-ops and engineering managers evaluating the workflow is that you can add Linear, Jira, and Slack routing simultaneously without changing your cost model. The meter fires once when the structured bug qualifies. Everything after that — routing, PR generation, RCA publication — is included.

Duplicate detection reinforces this. Because Watari merges duplicate bugs before the Mapped Bug is created, you are not billed once per customer report of the same issue. Three Zendesk tickets about the same payment-flow bug produce one Mapped Bug, one Linear issue, and one meter increment.

What the workflow does not replace

Watari is not a no-review pipeline. The draft PR that accompanies a Mapped Bug requires human review before merge — that is an explicit constraint in the code-to-PR docs. Similarly, the Linear issue Watari creates is a starting point, not a final spec. Your engineers may have context the ticket did not surface.

The structured handoff removes the formatting and extraction work, not the engineering judgment. The goal is that when an engineer opens a Watari-created Linear issue, they spend their time evaluating the proposed fix — not reconstructing what the bug actually is.

Support ticket to Linear issue: structured bug handoff without the rewrite