A support ticket without repro steps is not a bug report yet. It is a signal that needs structured extraction before it crosses to engineering. Skipping that extraction step and escalating anyway costs 2 to 5 business days per round-trip: engineering bounces it back for more information, the customer waits, and the engineer loses context switching between that follow-up and their current task.

The structural problem is that free-form tickets, whether they come from Zendesk or Intercom, are optimized for empathy and resolution speed, not for reproducibility. A customer writing in frustration describes symptoms. They do not write severity ratings, expected versus actual behavior tables, or ordered repro steps. That translation work has to happen somewhere. The question is whether it happens before or after the escalation reaches engineering.

Watari's pipeline places that translation work before the handoff, at the extraction stage. When a ticket arrives with no explicit repro steps, the extraction model reads the full conversation thread, screenshots, attachments, and screen recordings to reconstruct what the customer never wrote directly. If the extraction confidence clears the gate, a structured Mapped Issue is produced and engineering sees a complete bug report. If confidence falls below the threshold, the ticket is held and the support lead is prompted to add context before retry.

Why Engineering Bounces Vague Escalations

Engineering cannot act on a ticket that says "the checkout is broken" without knowing which checkout flow, which browser, which account state, and what "broken" means. The missing fields are almost always the same three.

Repro steps. An ordered sequence of actions that reliably produces the failure. Without this, the engineer cannot confirm the bug exists in their environment before writing a fix.
Expected versus actual behavior. What the customer believed would happen, and what happened instead. This distinguishes a bug from a misunderstanding of intended behavior.
Severity and customer impact. How many customers are affected, whether there is a workaround, and how much revenue or workflow is blocked. This determines queue priority.

When any of these three fields are missing, a responsible engineer returns the ticket to support. That is not an engineering failure. It is the system working as designed, just not the design you want.

The round-trip cost is concrete. Two business days minimum for the support agent to gather the missing information, rewrite the escalation, and route it again. Five days if the customer is in a different timezone or the original agent has moved on to other tickets. During that window, the customer has no status update and the bug is unfixed.

How Watari Reconstructs Repro Steps from an Incomplete Ticket

Watari's extraction step is the first stage of the four-stage pipeline described in the ticket-to-bug docs. When a ticket arrives via webhook from Zendesk or Intercom, the extraction model reads everything attached to that ticket, not just the opening message.

Specifically, the model reads:

The ticket subject and body
The full conversation thread, in order, with author labels and timestamps
Screenshots and screen recordings (read visually)
PDFs, logs, HAR captures, CSVs, stack traces, and Office documents (read as text)
Voice notes (transcribed)

A customer who never wrote "step 1: click Add to Cart, step 2: enter promo code SAVE20, step 3: observe 500 error" may have written those facts across four messages over two days: a complaint about the error, a follow-up with a screenshot, an agent's question about the promo code, and a reply confirming it. The extraction model reconstructs the ordered repro sequence from that conversational signal.

The output is a structured bug record with consistent fields: title, description, severity, repro steps, expected behavior, actual behavior, and customer impact. That record is what engineering reviews, not the raw ticket.

Two independent confidence gates then evaluate the record. The first gate scores the extraction itself: did the model produce a high-confidence structured item? The second gate scores the code mapping: was at least one file or function in your repository matched with high confidence? Both gates must clear before the Mapped Issue is recorded and the billing meter fires. If either gate fails, the ticket is held, not escalated. You can tune where those thresholds sit from Settings → AI Behavior.

The Step-by-Step Workflow for a Ticket with No Repro Steps

This workflow applies when a Zendesk or Intercom ticket has arrived, the extraction step has either held the ticket below threshold or produced a low-confidence structured record, and a support lead needs to decide what to do next.

Step 1: Identify the missing fields

Open the ticket in the Watari dashboard. The bug detail page shows which structured fields were populated and which were absent or low-confidence. Look specifically at:

Repro steps: empty, vague ("tried to use the app"), or partial (only one of three actions captured)?
Expected vs. actual behavior: did the customer describe what they wanted versus what they got, or only the symptom?
Severity: is the impact on the customer clear? Is there a workaround?

Note every gap. This list drives what you gather in the next step.

Step 2: Gather context from the thread and attachments

Read the full conversation thread yourself, including any internal notes your agents left. Customers often reveal repro steps in follow-up messages that arrived after the ticket was first triaged. Check:

Follow-up replies from the customer after the initial message
Any screenshots or recordings attached to secondary messages
Agent notes describing what they tried when attempting to reproduce the issue
Any linked account data (user ID, session ID, order ID) that pins the failure to a specific state

If the thread does not contain enough information, send the customer a structured follow-up asking for the three missing fields directly. Most customers will provide an ordered repro sequence if you ask for it in plain language: "Can you walk me through the exact steps you took, starting from the page you were on before the error appeared?"

Step 3: Add context and retry the extraction

Once you have gathered additional information, add it to the ticket as an internal note or as an edit to the structured fields on the bug detail page. Then click Retry on the bug detail page. Retrying re-runs the extraction pipeline on the enriched ticket without creating a duplicate Mapped Issue. The model has access to everything in the thread, including the context you just added.

This retry mechanism matters because the alternative is manual escalation: a support agent writes up a bug report in their own words and emails or Slacks engineering. That report is only as complete as the agent's understanding, and it bypasses the confidence gate entirely. Engineering receives an unvalidated escalation. Retry keeps the structured pipeline in the loop.

Step 4: Review the confidence score on the resulting Mapped Issue

After retry, check whether the extraction confidence has crossed the threshold. If it has, a Mapped Issue is recorded: engineering sees a structured bug report paired with specific files and functions in the repository. The ticket does not need another human touch.

If the confidence score is still below the gate, the ticket stays held. That is the correct outcome. It means the pipeline does not have enough signal to map the bug to code with confidence. Escalating at this point would put an unactionable item in front of engineering, recreating the round-trip you were trying to avoid.

Step 5: Escalate manually only as a last resort

If two retries with additional context still do not clear the gate, the bug may be genuinely ambiguous, a product-behavior question rather than a code defect, or a symptom of a customer configuration issue. At this point a human decision is appropriate:

Mark the ticket as needing a live session with the customer to capture a recording of the failure
Route to a senior support engineer for manual investigation
Close with a workaround if one exists and the root cause is unclear

The confidence threshold exists to protect engineering's queue. Overriding it manually is sometimes right. But it should be a deliberate choice with a named owner, not the default path for every ticket that lacks repro steps.

The Cost Calculation That Makes Holding Tickets Worth It

Holding a ticket for structured extraction feels like adding latency. It is actually removing latency from the system as a whole.

Consider the alternative path: a support agent escalates the vague ticket immediately. Engineering receives it, cannot reproduce the bug, and writes a reply asking for repro steps, expected versus actual behavior, and severity. That reply routes back through the support tool to the agent, who routes it to the customer, who replies two days later. Engineering re-receives the enriched ticket, re-reads the context, and begins actual triage. The total elapsed time is 2 to 5 business days, often longer across timezones.

The extraction-and-hold path: Watari reads the ticket immediately on arrival, attempts structured extraction, holds it below threshold, and surfaces the gap to the support lead within minutes. The support lead sends one structured follow-up request to the customer. The customer replies. The support lead adds the context and retries. If the retry clears, engineering receives a complete, code-mapped bug report. Elapsed time from ticket arrival to actionable escalation: typically the same 2 days it took the customer to reply, with no engineering time spent on the round-trip at all.

The engineering context-switch cost is the part that rarely appears in the calculation. An engineer pulled off a task to read a vague escalation, write a reply, and context-switch back loses 20 to 40 minutes even if they spend only 5 minutes on the ticket itself. Multiply that by every vague escalation in a sprint and the number is significant.

For more on how confidence thresholds work and how to tune them for your team's precision-recall preference, see AI behavior controls and the core concepts reference.

Support Ticket Has No Repro Steps? Here Is What to Do