Customer bugs logged in your issue tracker, mapped to your code

Not every team runs a help desk. If customer problems land in Jira, Linear, GitHub Issues or Azure Boards, hand the issue to Watari there. It writes the repro, finds the file and function, drafts a pull request, and comments its progress on the issue.

The issue exists. The engineering has not started.

A customer problem logged in the tracker is a title, a paragraph and maybe a screenshot. Someone still has to read it, decide whether it is a real bug, reproduce it and hunt through the code for where it lives, and that someone is usually the engineer you hoped would be fixing it. Watari does that first pass on the issue your team already wrote, so the engineer starts from a located bug and a draft fix.

The way your team already works.

Nobody learns a new tool. Add a label, mention Watari, assign the issue, or let a rule pick up new issues in the projects or teams you choose. On Linear, delegate the issue to Watari from the assignee menu. Pickup is off until an owner or admin turns it on, and your existing backlog is never pulled in.

Four trackers
Jira, Linear, GitHub Issues and Azure Boards.
Your choice of gesture
Label, mention, assignment or a rule.
Scoped to what you pick
Only the projects, teams or repositories you tick are read.

Issues

3 need you. Watari is working on 2.

Your move3

You can do these

  • Checkout button hangs on Safari over $200Northwind Trading · Intercom · +2 more customersWatari asks10:44
  • Where do I change the invoice footer?Skyline Realty · Freshdesk #51807Send this answer11:41

Waiting on your engineers

  • Onboarding greeting is missing the required phraseAcme Robotics · Zendesk #48213Review the fix11:02

Watari's move2

  • Export to Excel drops the last columnFernwood Health · Zendesk #48240Drafting a fix12:29
  • Notification bell does nothing when tappedAcme Robotics · Zendesk #48251Looking for the cause12:41

Done this week1

  • Invoice PDF shows the wrong tax rateSkyline Realty · Freshdesk #51722Customer updatedMon
The Issues list in Watari, sorted by whose move it is, with the customer behind each issue.

The file and function, not a guess.

Watari reads the issue like a support ticket, works out whether it is a real bug, and writes the report an engineer needs: the steps to reproduce, severity, and the files and functions in your GitHub or Azure DevOps repository most likely behind it. A question or a how-to gets a suggested answer and no pull request.

Real bug or not
Questions and settings get an answer, not a pull request.
Ranked code locations
Each with a plain reason for the match.
Draft pull request
Opened when Watari is confident, checked by your own CI.
Where it happens
#1Strong match
prompts/router.prompt.mdsystem prompt: tool schema

router prompt fails to constrain tool names to the declared whitelist

#2Possible match
src/ai/tool-schema.tsTOOL_DEFINITIONS

transfer_funds is described in docs but never registered in the live schema

Where it happens: the file and function behind the bug, with how sure Watari is of each match.

Progress on the issue, not in another tab.

Watari comments on the issue when it picks it up and again when it drafts a fix, opened as a draft pull request. If it does not draft one, the comment says why and what a developer can do next. It links the pull request to the issue where the tracker allows it (on Jira only for a private issue, on Azure Boards for a pull request in Azure Repos). When the fix ships and your team approves the customer-facing summary, it is posted on the issue for your team to pass on. On GitHub Issues, Jira and Linear that happens only where people outside your team cannot read the issue.

Two comments, not a stream
Picked up, then a fix drafted.
Pull request linked
On the issue wherever it is safe to show it.
Summary for your team
Held until the deploy that carries the fix.

Deploy confirmed · production

The fix is live as of 10:01 UTC. Customer update posted to the support ticket.

10:01 UTC
Customer update
published

Checkout button hang on Safari 18: fix shipped

Hi Maya, the checkout button on Safari 18 was failing because of a null intent guard that misfired when cart totals crossed $200. We have shipped a fix to production at 10:01 UTC and your charge for #4928 is now reattempting automatically. No further action is needed on your end.

The update for the customer, held until production confirms the fix is live.
A customer bug your team already logged should not need a second ticket to reach the code.

4

Trackers Watari picks issues up from today

Jira, Linear, GitHub Issues, Azure Boards

14d

Free trial of Growth. 3 repositories, 10 Mapped Issues. No card.

Trial policy

0.7

Confidence an issue must clear before it is billed

Watari billing model

Frequently asked questions

Do we need a help desk to use Watari?

No. If your team logs customer problems in Jira, Linear, GitHub Issues or Azure Boards, Watari can start from the issue there. Connect the tracker and your code, turn on pickup, and hand an issue over.

Is an issue from our tracker billed differently from a support ticket?

No. It is billed exactly like a support ticket, only when it becomes a Mapped Issue. Progress comments, draft pull requests and the customer update are included.

Will Watari file a second issue next to the one we handed it?

No. An issue Watari picked up is its own issue, and Watari posts progress on it. Issues Watari files for help-desk tickets are never picked up as new reports, so both can run in the same project.

Who reads the customer update?

Your team. It is posted on the issue for your team to pass on to the customer, and on GitHub Issues, Jira and Linear only where people outside your team cannot read the issue. Otherwise it stays in Watari.

When a support ticket reports a bug, your engineers get a drafted fix.

Connect your help desk or your issue tracker, then GitHub or Azure DevOps. Watari maps each bug to the exact file and function in your code and drafts the fix as a pull request your CI checks.

14 days free. No card. Cancel any time.