Intercom ticket to bug report: structured handoff to GitHub without the rewrite

Watari connects to Intercom via OAuth, registers a webhook on your account, and reads every conversation update automatically. When a ticket contains a reproducible bug, the extraction model produces a structured record with severity, repro steps, expected versus actual behavior, and customer impact. Both confidence gates must clear before a Mapped Issue is recorded, so engineering only sees escalations that are already pinned to a specific file and function in your GitHub repository.

Why Intercom conversations are a poor input for GitHub issues

Intercom conversations are written for human empathy, not engineering triage. A multi-turn chat thread trades in reassurance and clarification, not severity labels and stack traces.

A support conversation about a broken checkout flow might span eight messages across two agents, two customer replies, and an internal note. The repro steps are scattered across messages three, five, and six. The severity is implicit in the customer's language, not stated as a field. Expected versus actual behavior has to be inferred from what the customer says they expected to happen versus what they reported. Copying that thread into a GitHub issue or Jira ticket means reading the entire conversation, extracting those fields mentally, rewriting them into engineering prose, and then filing the issue. That manual rewrite is where escalation latency hides, and it compounds across every bug your support team touches in a week.

Intercom's conversation model is also structurally different from a Zendesk ticket. There is no single "description" field. The thread is the record. Any tool that reads only the first message misses the repro detail that arrived in message four. Watari reads the full thread, in order, with author labels and timestamps, before attempting extraction.

How Watari extracts a structured bug from an Intercom conversation

Watari reads the complete conversation thread, including attachments, screenshots, PDFs, logs, HAR captures, and voice notes, before producing any structured output. The extraction model does not treat the first message as the bug description.

The ticket-to-bug pipeline works as follows:

1. Ingest the full thread. When an Intercom conversation update fires the webhook, Watari reads the subject, the ordered message thread with author labels and timestamps, and every attachment. Screenshots are read visually. Voice notes are transcribed. PDFs and logs are read as text.
2. Extract structured fields. The extraction model produces: a concise bug title, a severity classification, a numbered repro sequence, expected behavior, actual behavior, and a customer impact statement. These are consistent fields your engineering team can act on without reading the original thread.
3. Check extraction confidence. The structured record only advances if the extraction confidence gate clears. If the model is not confident enough that a real bug is present, the ticket stays in triage and no escalation artifact is created.
4. Run duplicate detection. Duplicate detection operates at the structural level, comparing extracted repro sequences and failure signatures rather than raw message text. Four Intercom conversations describing the same broken payment flow collapse into one Mapped Issue rather than four separate GitHub issues.

The concepts reference defines these confidence gates in detail. The short version: a structured record that does not reach the extraction confidence threshold is never promoted to a Mapped Issue, and your engineering queue stays clean.

How the code mapping step works before GitHub sees anything

A structured bug record is not the same as a Mapped Issue. The second confidence gate requires that at least one code location in your repository match the bug with high confidence.

When you connect a GitHub repository, Watari indexes it using tree-sitter to parse supported source files at the function level. Each chunk is embedded and stored in a pgvector HNSW index. The bug-to-code pipeline retrieves the top candidates, then a reranking step promotes the most relevant file and function before writing the confirmed code locations.

Only when both gates clear, extraction confidence and code-location confidence, does the Mapped Issue meter fire and the draft PR work begin. Engineering receives an escalation that includes:

• The structured bug fields (severity, repro steps, expected versus actual, customer impact)
• The specific file and function where the fix most likely belongs
• A draft pull request opened against your default branch
• Any Linear, Jira, or Slack sync you have configured, all bundled, never metered separately

Ticket volume does not affect your bill. PR iterations do not affect your bill. The only unit Watari charges for is the Mapped Issue itself.

Connecting Intercom and routing to GitHub

The connection takes under ten minutes. The support tools setup guide walks through every step, but the sequence is:

1. Connect Intercom via OAuth. Go to Settings → Integrations and click Connect next to Intercom. Complete the OAuth flow. Watari registers its own webhook on your Intercom account and begins receiving conversation updates immediately. No manual export. No CSV.
2. Install the GitHub App. Install the Watari GitHub App on your GitHub organization and select the repositories you want indexed. The index builds in the background. For a typical SaaS codebase, the first pass completes within the first day.
3. Configure routing destinations (optional). If your team uses Linear, Jira, or Slack, connect them from Settings → Integrations. Watari will sync the Mapped Issue to whichever destinations you configure. These are optional and bundled.
4. Review your first Mapped Issues. As Intercom conversations arrive and pass both confidence gates, Mapped Issues appear in your dashboard. Each one shows the structured bug fields, the confirmed code locations, and a link to the draft PR.

The Watari confidence thresholds are tunable. If you find that too many low-signal conversations are being promoted, or that legitimate bugs are being held back, you can adjust extraction and code-location thresholds from Settings → AI Behavior. Changes apply to future processing only.

What engineering actually receives

The handoff artifact that lands in GitHub is a draft pull request, not a raw Intercom thread. The PR description contains:

• The bug title and severity
• The numbered repro steps extracted from the conversation
• Expected versus actual behavior
• Customer impact (how many conversations in the cluster, what they reported)
• The file and function identified as the most likely fix location
• A proposed diff generated by the fix loop, which reads the relevant source files and the structured bug description before writing any code

The draft PR is marked as a draft. It does not merge automatically. A human engineer reviews the diff, runs CI, and approves the merge. The fix loop is a starting point, not a final answer. Watari's own documentation states this plainly: never merge a Watari PR without review.

After the fix ships and Watari detects the production deploy, a customer-facing root-cause analysis is drafted and published back to the original Intercom conversation. The RCA is bundled. It is never metered.

The cost of not structuring the handoff

The manual copy-paste path has three compounding costs that are easy to undercount.

• Latency. Every minute a support agent spends rewriting a conversation thread into a GitHub issue is a minute the bug sits unrouted. For a team handling twenty escalations a week, that latency adds up.
• Information loss. Manual rewrites drop context. The attachment in message six, the customer's exact repro sequence, the internal note that identified the affected account segment: these are the details that would have let an engineer reproduce the bug in thirty minutes instead of three hours.
• Duplicate filing. Without structural deduplication, the same broken flow gets filed as three separate GitHub issues by three different agents. Engineering triages all three, closes two as duplicates, and loses the cluster signal that would have shown the bug was affecting a significant portion of accounts.

Watari's duplicate detection addresses the third cost directly. The deduplication operates on extracted structure, so four conversations about the same checkout failure, each worded differently, collapse into one Mapped Issue with a cluster count that reflects the real scope.

For teams evaluating whether the structured handoff is worth the setup, the plans and pricing page shows what is included in each tier. The ten-minute quickstart is the fastest way to see your first Mapped Issue without committing to a paid plan.