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 in

When a ticket arrives from Zendesk or Intercom via webhook, Watari reads:

• The ticket subject and body
• The full conversation thread, in order, with author labels and timestamps
• Any attachments — screenshots, screen recordings, log files
• Provider metadata: status, tags, priority, requester name and email, custom fields

What Watari does not read: internal admin notes your support agents write for each other (Zendesk internal notes, Intercom private notes). Those are outside the webhook scope by design.

Structured extraction

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 ticket detail page, edit anything that looks wrong, and manually promote the ticket to the next stage.

Dedup via bug signature

Before a new bug record is created, Watari computes a deterministic signature from the extracted fields and compares it against your existing bugs using semantic similarity. If the new bug is similar enough to an existing one, the incoming ticket is absorbed into 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 bug detail page updates immediately.

Customer-verbatim preservation

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 bug detail 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 see

After the extraction stage completes, the ticket appears in the /tickets 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 in Zendesk or Intercom
• A qualitative confidence indicator
• The customer verbatim in a collapsible section

Non-bug tickets (billing questions, feature requests, account requests) are listed with a skipped status and the reason for skipping. They do not consume any plan quota.

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.