Intercom Ticket to Bug Report: Structured Handoff to GitHub Without the Rewrite

To turn an Intercom conversation into a bug report engineering can act on, someone has to read the whole thread, reassemble the repro steps scattered across messages, state expected vs. actual behavior, and file it where the code lives. Intercom's own GitHub app makes the filing a single click, which is enough for many teams. What it does not do is the reading and reassembling, or tell anyone where in the codebase the bug lives. This guide covers why chat is a hard input, what the free integrations handle, and how Watari hands GitHub a structured bug pinned to code.

Why an Intercom conversation is a poor bug reportCopy Anchor Link

Intercom is designed for fast, human conversation, and that is exactly what makes it an awkward source for engineering.

• No subject line. A Zendesk ticket at least has a subject that roughly names the problem. An Intercom conversation has a thread, so a useful bug title has to be written from the content.
• The thread is the record. There is no single description field. A tool, or a person, that reads only the first message misses the repro detail that arrived in message four.
• Repro detail is fragmented. The same customer who would write one paragraph in an email sends five short messages in chat, sometimes across sessions, interleaved with agent questions and greetings.
• Live chat attracts more non-bugs. How-to questions and billing queries make up more of a chat queue than an email queue, so separating real defects matters more.
• The useful context is in metadata. Plan, workspace and other custom attributes, plus the tags your team applies, often say more about severity than the customer's tone does.

Copying that into a GitHub issue means reading the entire conversation, pulling out the fields in your head, rewriting them as engineering prose, and filing. That rewrite is where escalation time goes, and where detail like the exact error message gets lost.

What Intercom's free integrations already doCopy Anchor Link

Before adding anything, use what is included.

• Intercom's GitHub app creates a GitHub issue from a conversation or ticket in a click, including the conversation text, images, a link back to the conversation and customer details. When the linked issue is closed, it leaves a note and reopens any linked conversations so the agent can update the customer. It connects to a single repository.
• Intercom's Jira app and Linear's Intercom integration do the equivalent for those trackers, and Linear can reopen the conversation when its issue is completed.
• Zapier covers other combinations without code.

These are enough when volume is modest, most bugs live in one repository, engineers already know where to look, and your agents write a good repro when they file.

They stop short when the issue still contains whatever the agent wrote (so the rewrite remains), duplicates across conversations are only linked if someone notices them, the issue says nothing about which code is responsible, and "closed" reopens the conversation when the issue closes rather than when the fix is live in production.

What engineering needs from an Intercom bugCopy Anchor Link

Whether you file by hand or with a tool, a bug from a chat conversation should arrive with:

• A title that names the failure, written from the content ("Checkout fails when a discount code is applied during a renewal")
• Numbered repro steps assembled from all the customer's messages, in order
• Expected behavior and actual behavior as two separate statements
• Severity grounded in impact, using plan or account attributes where you have them
• The customer's exact words, verbatim, including any error text, next to your summary
• The attachments the customer shared, not a note saying they exist

If a conversation cannot fill the repro and expected-vs-actual fields, ask the customer while they are still in the chat. That is far cheaper than an engineer asking a week later. Our guides on escalating a ticket without rewriting it and telling a bug from a feature request cover both steps in more depth.

How Watari turns an Intercom conversation into a GitHub-ready bugCopy Anchor Link

Connect once. Connect Intercom from Settings, Connected tools through Intercom's OAuth screen; Watari registers its own webhook, so there is no URL to paste. You choose which Intercom team routes conversations to Watari, and only conversations assigned to that team are processed. Webhooks are verified against Intercom's signature, and the conversation is re-fetched from Intercom before processing rather than trusting the webhook body. The support tools guide walks through it.

Read the whole thread. Watari reads the customer and teammate messages in order with author labels and timestamps, the conversation's tags and custom attributes, and attachments of any format: screenshots and screen recordings are read visually, logs, HAR files and PDFs as text, and voice notes are transcribed. Private notes your agents write to each other are not read.

Extract a structured bug. From that thread it writes the fields above: a title, severity, repro steps, expected and actual behavior, customer impact and the verbatim quote. Conversations that are not bugs (a how-to, a billing question) are skipped with a reason, and extractions that are not confident enough are held for human review. If the conversation describes a bug Watari has already seen, it joins that bug's record instead of creating a duplicate, so four conversations about the same failure show up as one bug with four affected customers.

Pin it to the code. Watari then maps the bug to the files and functions most likely responsible in your connected repositories. Only when both checks clear, a confident extraction and a confident code location, does it become a Mapped Issue.

Hand engineering a draft, not a chat log. For a Mapped Issue, Watari opens a draft pull request on GitHub with the structured bug in the description and the code owners requested as reviewers, and files an issue to Jira, Linear or GitHub Issues if you use them. The draft is a starting point; an engineer reviews every diff, and nothing merges automatically.

Reply in the same conversation. After the fix is confirmed in production, Watari drafts a customer-facing RCA for your team to review, and once approved posts it as a reply on the original Intercom conversation for every customer who reported the bug.

Tracker sync, draft PRs and the RCA are included in every plan. Watari bills only the Mapped Issue; conversations that never qualify cost nothing. See plans and pricing for what each tier includes.

---

Intercom's GitHub app solves filing. If filing is your bottleneck, start there. If the real cost is reading long threads, reassembling repro steps, spotting duplicates and working out which part of the codebase a chat is about, that is the handoff Watari is built to remove.