Intercom Ticket to Bug Report: What Changes When Support Is a Conversation

Watari turns an Intercom conversation into a structured bug report by reading the full thread, stripping bot and macro turns, synthesising a title from content rather than copying a subject line, and running the same extraction-confidence gate it applies to Zendesk tickets — before the bug ever reaches your GitHub, Linear, or Jira workflow. The chat format introduces specific preprocessing decisions that a Zendesk-first pipeline would get wrong.

Why Intercom Conversations Are Structurally Harder to Extract From

An Intercom conversation has no subject line. A Zendesk ticket has a subject field that acts as a natural bug title — imperfect, but it exists. An Intercom conversation is a thread of short messages, often sent across multiple sessions, interspersed with bot replies, macro expansions, qualification questions, and CSAT prompts. There is no single field you can copy into a bug title.

That structural difference has four concrete consequences for automated extraction:

1. The title must be synthesised, not copied. The extraction model reads the full thread and produces a bug title from the content — a sentence that captures what went wrong, not a label the customer typed into a subject field.
2. Bot and macro turns must be stripped first. A typical Intercom conversation contains bot-authored turns: greeting messages, qualification flows, CSAT requests, and macro-templated replies from agents. If those turns reach the extraction step unfiltered, boilerplate text competes with real repro context and degrades confidence.
3. Repro steps are fragmented across turns. A customer describing a checkout failure in Zendesk often writes one coherent block. In Intercom, the same customer sends five short messages across ten minutes. The extraction step has to assemble a coherent repro sequence from those fragments — reading author labels and timestamps to order the turns correctly.
4. Intercom metadata carries signal that Zendesk lacks. Intercom conversations can carry custom attributes (plan tier, workspace ID, feature flags) and tags applied by your team. That metadata is available to the extraction step for severity routing in ways a plain Zendesk ticket body is not.

None of this makes Intercom harder to integrate — the OAuth connection is identical in shape to Zendesk, taking one authorisation with no manual webhook URL. But it does mean the extraction step makes different decisions depending on which provider sent the conversation.

What the Extraction Step Actually Reads from an Intercom Conversation

When an Intercom conversation arrives via webhook, Watari's ticket-to-bug pipeline reads the following from the payload:

• Every message turn in the thread, in order, with author type (customer vs. agent vs. bot) and timestamp
• Tags applied to the conversation by your team
• Custom attributes set on the conversation or the contact
• Assignee and team metadata
• Attachments — screenshots, screen recordings, log files shared inline

What it does not read: internal notes your agents write for each other. Just as Watari excludes internal admin notes from Zendesk tickets to avoid polluting the bug report with agent commentary, it excludes Intercom's private notes from the extraction context.

Before the extraction model runs, the pipeline filters the thread to customer and human-agent turns only. Bot turns are identified by author type in the payload and removed. Macro-expanded turns — agent messages that are templated responses — are also excluded where the payload identifies them as such. What remains is the signal: what the customer actually experienced and what your agent actually asked in follow-up.

From that cleaned thread, the extraction step produces the same structured fields it produces from any Zendesk ticket:

• Title — synthesised from thread content, not copied from a subject
• Description — a coherent summary of the reported behaviour
• Severity — inferred from language, customer metadata, and Intercom tags
• Repro steps — assembled from fragmented customer messages in thread order
• Expected vs. actual behaviour — extracted as distinct fields
• Customer's original words — preserved verbatim as a quote field
• Customer impact — who is affected and how severely

This is the Mapped Bug concept — a structured record that passes two independent confidence gates. The first gate is extraction confidence: the structured bug must score above the threshold for the extraction to be considered reliable. Conversations that are feature requests, general questions, or too fragmented to yield a confident repro are routed to manual triage and never advance to the mapping stage.

How Confidence Gating Handles the Chat Format

The confidence threshold for extraction exists precisely because not every Intercom conversation contains a bug. Live chat surfaces a much higher proportion of how-to questions, billing inquiries, and vague complaints than email-style ticket queues. A pipeline that tried to map every conversation to code would produce noise.

The extraction confidence gate filters that noise. A conversation where the customer asks how to export a CSV, gets an answer, and closes the chat will not produce a high-confidence structured bug — the extraction model will score it below threshold, and the conversation will be routed to manual review rather than advancing. A conversation where the customer reports that a specific action produces an error, provides a screenshot, and the agent confirms the behaviour is reproducible will score high and advance.

You can tune where the confidence boundary sits. AI behavior controls in Settings let you shift the extraction threshold — tighter means fewer draft PRs and more manual routing, looser means more drafts and more review work. The tradeoff is the same regardless of whether your tickets come from Intercom or Zendesk; the chat format just means a higher proportion of conversations will land below threshold by default.

Once a conversation clears extraction confidence, the second gate — code location confidence — operates identically to the Zendesk path. The structured bug is embedded and matched against your repository index using pgvector HNSW vectors over tree-sitter chunks. The top candidates are reranked; at least one code location must clear the location confidence threshold before the billing meter fires and the draft PR begins.

From Structured Bug to GitHub PR, Linear, and Jira

Once both gates clear, the source provider is irrelevant. A Mapped Bug that originated in an Intercom conversation follows exactly the same downstream path as one that came from Zendesk:

1. A draft pull request opens on GitHub, routed by CODEOWNERS to the team responsible for the matched files.
2. The fix loop reads the relevant source files, the bug description, and the repro steps — then proposes a diff.
3. CI runs against the draft. If CI fails, the fix loop iterates.
4. If you have Slack, Linear, or Jira connected, a secondary ticket is created and a Slack notification is posted to the configured channel.
5. After the fix ships, an RCA is drafted and published back to the original Intercom conversation.

All of steps 2–5 are bundled into your plan. The only thing the billing meter charges for is the Mapped Bug itself — not the PR iterations, not the Linear or Jira sync, not the RCA publish.

The Intercom integration is also symmetric with Zendesk at the connection layer. Both connect via OAuth. Both have their webhook registered automatically during the OAuth flow — you never copy a webhook URL or generate an API key. Both encrypt the access and refresh tokens with AES-256-GCM before writing them to the database. If you're already running Zendesk through Watari, adding Intercom is the same three-click flow from Settings → Integrations.

What a Well-Formed Bug Report from an Intercom Conversation Looks Like

The output of a successful extraction from an Intercom conversation should be indistinguishable in quality from one extracted from a Zendesk ticket — even though the inputs are structurally different. A well-formed bug report from a live-chat conversation contains:

• A synthesised title that a developer can act on without reading the raw thread ("Checkout fails with 500 when applying a discount code during active subscription renewal")
• Ordered repro steps assembled from the customer's fragmented messages
• Expected and actual behaviour as distinct fields, not combined into a paragraph
• A verbatim customer quote that preserves the original complaint without paraphrase
• A severity label grounded in the customer's plan tier or Intercom tags where available
• Confirmed code locations pointing to specific files and functions in the repository

That last item is what makes the bug report actionable rather than informational. A bug title and repro steps tell an engineer what is broken. A confirmed code location tells them where to look — and gives the draft PR a starting point that is specific enough to generate a meaningful diff.

The gap between "we received a support chat about a checkout error" and "here is a draft fix in the billing middleware, routed to the payments team via CODEOWNERS, with a Linear ticket already created" is what the extraction and mapping pipeline is designed to close — regardless of whether the conversation started in Intercom's in-app messenger or a Zendesk email queue.