Ticket to bug

The first pipeline stage turns a free-form support conversation into a structured bug record with consistent fields your engineering team can act on.

What gets sent inCopy Anchor Link

When a ticket arrives from Zendesk, Intercom, or Freshdesk via webhook, or an issue arrives from Jira, Linear, GitHub Issues or Azure Boards because your team handed it to Watari, Watari reads:

• The ticket subject and body
• The full conversation thread, in order, with author labels and timestamps, including internal notes your agents add (Zendesk internal comments, Intercom notes, Freshdesk private notes). Agents often record the most useful triage detail there, such as the account affected or what they already tried.
• Any attachments, whatever the format. Screenshots and screen recordings are read visually; PDFs are read page by page (so a scan works too); logs, HAR captures, CSVs, stack traces and Office documents are read as text; and voice notes (including the narration on a screen recording) are transcribed. Archives are stored for download but not opened.
• Provider metadata: status, tags, priority, requester name and email, custom fields

Internal notes are read as part of the ticket and inform the bug record. If there are notes you do not want Watari to read, keep them out of the tickets your trigger forwards (for example, forward only tickets with a needs-engineering tag).

Structured extractionCopy Anchor Link

The AI reads the ticket and proposes a structured bug with the following fields:

• Title: a short, engineering-readable summary of the defect
• Severity: one of critical, high, medium, or low, assessed from customer impact language in the ticket
• Steps to reproduce: an ordered list derived from the conversation, if the customer described them
• Expected behavior: what the customer expected to happen
• Actual behavior: what actually happened
• Affected feature: the product area or surface where the issue occurred
• Customer impact: a concise summary of how many customers are affected and what they cannot do

The AI also assigns an extraction confidence score. If the ticket does not clearly describe a software bug (billing questions, account access requests, onboarding help, feature requests) it does not pass the threshold and no bug is created. The ticket is marked with a classification reason in the dashboard so you know why it was skipped.

Bugs with a confidence score below the threshold are held for human review rather than discarded. You can review the draft fields on the issue page, edit anything that looks wrong, and manually promote the ticket to the next stage.

Dedup via bug signatureCopy Anchor Link

Before a new bug is created, Watari checks whether it describes a problem you already have. If it does, the ticket joins that bug's cluster instead of creating a duplicate.

This is what makes recurring-issue counts meaningful. If 12 customers have reported the same checkout bug over the past two weeks, you see one bug with 12 linked tickets, not 12 separate bug records that look unrelated because each customer described the issue in their own words.

When a ticket is absorbed into an existing cluster, the original ticket link, the customer verbatim, and the requester details are all preserved on the canonical bug record. The cluster count on the issue page updates immediately.

Writing a ticket Watari can act onCopy Anchor Link

Watari works from what the ticket says. A two-line ticket with no screen name, no steps and no customer message gives it very little to locate, and it gives an engineer just as little. If your support team would like a format to follow, the free bug report template lists the nine fields that matter and copies the finished report as plain text, Markdown or Jira markup. It runs in the browser and needs no account.

Customer-verbatim preservationCopy Anchor Link

Even though the extracted bug fields are AI-summarized, the original customer language is kept verbatim alongside the structured record. The verbatim is surfaced on the issue page so engineers can read the raw customer experience, not just the normalized summary.

When an RCA is drafted later, Watari pulls from the customer verbatims across the cluster to make the "customer impact" section of the RCA reflect real language, not a summary of a summary.

What you seeCopy Anchor Link

After the extraction stage completes, the ticket appears in the /issues view with:

• A status of mapped (if mapping already completed), mapping (if mapping is in progress), or pending review (if extraction confidence was too low to proceed automatically)
• The extracted bug fields
• A link to the source ticket or issue
• A qualitative confidence indicator
• The customer verbatim in a collapsible section

Tickets Watari did not fileCopy Anchor Link

Some tickets hold nothing to file: a how-to question, a billing query, or an account change your team makes by hand. They appear under Issues → Not filed, each with the reason Watari gave:

• Nothing to file. Watari read the ticket and found no bug or feature request in it.
• Not clear enough to file. Watari saw a possible issue but was not confident enough to file it.
• No text to read. The ticket arrived with no description and no replies.
• Could not process or Stalled. Processing stopped before Watari could read the ticket.

Tickets under Not filed never count toward your plan's Mapped Issues. If one should have become an issue, a workspace owner or admin can click Read again to have Watari read it again, up to three times per ticket. A ticket that joined an existing issue as another report of the same problem is not listed here; it appears on that issue.

---

Next: Bug to code: how Watari maps bugs to files and functions in your repository, how Watari maps the structured bug to specific files and functions in your repository.