Introducing Watari: turning Zendesk and Intercom tickets into draft GitHub pull requests mapped to your code
Watari converts customer support tickets from Zendesk and Intercom into structured bug reports, maps each bug to a specific file and function in your GitHub repository, drafts a pull request for the fix, and publishes a customer-facing root-cause analysis after production confirms the deploy.
Updated October 2026. This is the launch announcement from May 2026 and it describes what shipped that day. Since then Freshdesk has joined Zendesk and Intercom as a support source, Azure DevOps has joined GitHub as a code host, and Azure Boards has joined Jira, Linear and GitHub Issues as a filing destination. Since October 2026, Jira, Linear, GitHub Issues and Azure Boards can also be where a report starts. For the current list, see how Watari works.
Watari converts customer support tickets from Zendesk and Intercom into structured bug reports, maps each bug to a specific file and function in your GitHub repository, drafts a pull request for the fix, and publishes a customer-facing root-cause analysis after production confirms the deploy. The whole loop runs without manual triage.
Why we built Watari
The gap between a customer support ticket and a fixed line of code is one of the longest, most expensive paths in B2B SaaS. A Zendesk ticket lands. A support agent reads it. Maybe they reproduce the bug. They tag an engineer. The engineer opens the repo, searches for what they think is the relevant file, asks the agent for more detail, eventually finds the function, writes the fix, opens a pull request, and, if the team is mature, circles back to the customer with a status update.
Watari collapses that loop. Connect Zendesk or Intercom, install the GitHub App, and the next qualifying ticket lands in the pipeline. The output is a draft pull request mapped to the specific function the bug describes, with a structured bug record, a customer-facing RCA template, and Slack notifications routed by CODEOWNERS. The engineer's first action is a code review, not a search.
How the pipeline works
- Ticket to bug. Every inbound Zendesk and Intercom ticket is turned into a structured bug: title, severity, reproduction steps, expected vs actual behavior, affected components, and customer impact. Tickets that aren't reportable bugs (billing questions, feature requests, account changes) are filtered out before any code mapping happens.
- Bug to code. Watari indexes the repositories you connect, then scores the code most likely responsible for the bug and keeps only the locations it is confident in. The output is one or more code locations (file plus function), each with a confidence level.
- Code to PR. When a bug clears the Mapped Issue confidence threshold, a draft pull request opens against the mapped file. The PR carries the bug context, the proposed fix, and a generated test. Reviewer comments trigger an iteration loop, leave a comment, Watari pushes a follow-up commit on the same branch.
- Bug to RCA. After the PR merges and a successful production deploy is confirmed, Watari drafts a customer-facing root-cause analysis and posts it back to the original ticket. The customer learns what happened, what was fixed, and what prevents the issue next time, without an engineer hand-writing the response.
The Mapped Issue pricing model
Watari bills one thing: the Mapped Issue. A bug Watari extracted with high confidence AND mapped to a specific code location with high confidence is a Mapped Issue, and the meter fires exactly once when the bug and its mappings are persisted. Draft pull requests, customer-facing RCAs, and sync to Slack, Linear, Jira, or GitHub Issues are bundled into your subscription. They never increment the meter.
We chose this model because everything downstream of the Mapped Issue compounds. Once Watari knows the bug exists and where it lives, drafting a PR is mechanical, drafting an RCA is mechanical, and syncing a Linear ticket is mechanical. Charging for the mechanical parts would penalise teams that lean into the automation. Charging once at the moment of extraction-plus-mapping aligns the price with the value: customer support pain converted into engineering action. The pricing page has the full tier breakdown and the Mapped Issue meter doc covers the qualification rules in detail.
What's connected on day one
| Source / sync | Role | Setup |
|---|---|---|
| Zendesk | Inbound tickets (OAuth) | One-click via Settings → Connected tools |
| Intercom | Inbound tickets (OAuth) | One-click via Settings → Connected tools |
| GitHub App | Repo indexing + PR drafting | Install on the org; pick repos |
| Slack | Routing notifications + RCA delivery | Bot install + channel invite |
| Linear | Draft ticket destination | OAuth |
| Jira | Draft ticket destination (ADF) | OAuth |
The full per-provider setup walkthroughs live under /docs/connect-your-stack.
What's next on this blog
Future posts will cover how support and engineering teams use Watari day to day. Subscribe to the Watari Blog RSS feed or the newsletter: one email when a new post lands, no spam, unsubscribe in one click.
If you'd rather get hands-on, the Quickstart walks through the full setup in under ten minutes.
Get new posts in your inbox
One email when a new post lands. No spam. Unsubscribe in one click.
Frequently asked questions
- What is a Mapped Issue in Watari?
- A Mapped Issue is a bug Watari has extracted from a customer support ticket with high AI confidence AND mapped to at least one specific code location (file plus function) with high confidence. The billing meter fires exactly once per Mapped Issue, at the moment the bug and its mappings are persisted.
- Which support tools does Watari connect to?
- Zendesk, Intercom, and Freshdesk. Zendesk and Intercom connect via OAuth; Freshdesk connects with a domain and API key. Only one support tool per Watari workspace. If you run separate deployments, use separate Watari workspaces. Slack receives routing notifications. Linear, Jira, GitHub Issues, and Azure Boards are where issues are filed, and Watari can also pick up issues your team hands it there.
- What stays bundled and what is metered?
- Only the Mapped Issue is metered. Draft pull requests, customer-facing root-cause analyses, and sync to Slack, Linear, Jira, GitHub Issues, and Azure Boards are bundled into your subscription. The meter never fires for a PR draft or an RCA.
- How long does it take to see the first Mapped Issue?
- Under ten minutes for a typical SaaS team. Sign up, connect your support tool, connect GitHub or Azure DevOps, and the next qualifying ticket flows through the pipeline automatically. The Quickstart walks through every step.