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.
TL;DR
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 using pgvector and tree-sitter, 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. Inbound Zendesk and Intercom webhooks trigger an Inngest job that calls Claude Haiku 4.5 to extract 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. The extracted bug is embedded with OpenAI's text-embedding-3-small and matched against a tree-sitter-chunked, pgvector-indexed view of your repository. Top-K candidates are reranked by Claude. The output is one or more code locations — file plus function — each scored on confidence.
- Code to PR. When a bug clears the Mapped Bug 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 Bug pricing model
Watari bills one thing: the Mapped Bug. A bug Watari extracted with high confidence AND mapped to a specific code location with high confidence is a Mapped Bug, 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 Bug 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 Bug 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 → Integrations |
| Intercom | Inbound tickets (OAuth) | One-click via Settings → Integrations |
| 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 the engineering details under each pipeline stage — pgvector cost modelling for code embeddings, tree-sitter chunking for twelve languages, the Inngest concurrency patterns that keep the meter idempotent, the Claude prompt design that makes extraction stable across thousand-token tickets. 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 Bug in Watari?
- A Mapped Bug 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 Bug, at the moment the bug and its mappings are persisted.
- Which support tools does Watari connect to?
- Zendesk and Intercom at launch. Both connect via OAuth. One support tool per Watari workspace. If you run separate Zendesk and Intercom deployments, use separate Watari workspaces. Slack, Linear, and Jira are sync destinations — they receive routing notifications and draft tickets but are not bug-source inputs.
- What stays bundled and what is metered?
- Only the Mapped Bug is metered. Draft pull requests, customer-facing root-cause analyses, and sync to Slack, Linear, Jira, and GitHub Issues 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 Bug?
- Under ten minutes for a typical SaaS team. Sign up, connect Zendesk or Intercom, install the GitHub App, and the next qualifying ticket flows through the pipeline automatically. The Quickstart walks through every step.