Your first week
What to expect on day one, day three, and the end of week one, from your first issue to clusters and customer updates.
Watari is useful from the first report. Over the first week your team sees more issues come in, makes a few corrections, and sees repeat reports grouped together.
Day 1: finish the three setup steps
Home shows three setup steps: connect your help desk or tracker, connect your code, and see your first issue (see the quickstart if you have not started). Once the first two are done:
- New reports arrive on their own. You do not need to import history: Watari reads reports as they arrive.
- Watari gets your code ready in the background. Most repositories take a few minutes, a large one up to an hour. Home and Codebase show each repository with the time left.
- A report that arrives before your code is ready is written up straight away, and Watari searches your code for it as soon as the repository is ready.
- When your first issue is in, the owner and admins get one email, and Home shows Setup is done with your first issue. Setup does not come back after that: if a connection stops working later, it is listed under Needs you.
The first issues may feel sparse if your first tickets are billing questions, account access requests, or vague "something seems off" reports. Those tickets hold no defect to fix, so Watari lists them under Not filed with the reason, or answers a how-to question with a reply your team can send.
Watari can misread a report. If a field is wrong (severity, steps to reproduce, the description) edit it on the issue page. Watari uses your corrected words when it searches your code and drafts a fix.
Day 3: first Mapped Issues appearing
By day three, with a steady flow of reports, you should see Mapped Issues on Issues, grouped by whose move it is. Working in Watari day to day explains the screens. A Mapped Issue is an issue Watari found in your code with a Strong match: a specific file and function it believes causes the problem.
Review the first few carefully. This is the highest-value thing you can do early in the relationship:
- Open each Mapped Issue and read Where it happens. Does it point at the right file and function?
- If none of the places is the cause, an owner or admin can report it as wrong for 7 days after it was counted: choose Report Mismapped under Where it happens, pick the reason, and choose Submit credit request. If it was counted this month, it comes off this month's count. The Mapped Issue meter, qualification and mismapped credit policy explains what happens for an earlier month.
- Cluster patterns start forming at this point. If you have recurring issues, you'll see the "X customers affected" count on some bugs start to grow.
End of week 1: clusters, RCAs queued, multi-repo patterns
By the end of the first week, several things come online:
Cluster-grew triggers. When a bug's cluster reaches your configured threshold, Watari fires a cluster-grew notification. This is the "recurring issue" signal, the same underlying defect showing up across multiple customer tickets. An RCA draft is queued automatically when a cluster grows.
RCAs queued for review. Watari drafts RCAs, and the draft sits in your queue until someone on your team approves it from the issue page. Nothing is posted before that. By default, an approved RCA is then posted automatically once the fix is confirmed in production; if you switched off posting on its own in Settings → How Watari works → When the customer hears, someone sends it from the issue page instead.
Multi-repo correlations. If you have more than one repository connected, Watari starts surfacing bugs that span multiple codebases, a frontend component and the API handler it calls, for example. These produce linked PRs across both repositories.
What to expect on accuracy
Watari reads customer-language tickets as they are written: plain prose, support-chat back and forth, screenshots and recordings. Non-English tickets work as well; set the language your engineers read in Settings → How Watari works → For engineers if your team prefers the write-up in a language other than English.
How well Watari finds the code depends on how your repository reads. Descriptive function and variable names help most: a function named handlePaymentGatewayTimeout says far more than one named handler3. For measured results on public repositories, see /proof.
A .github/CODEOWNERS file that maps directories and files to owners is also worth adding. Watari uses it to route draft PRs to the right reviewers.
Showing your team what Watari did
Insights shows one calendar month at a time, with the month before beside it. Three counts lead:
- Reports that became issues: of the customer reports that reached Watari, how many were a bug or a feature request. A setting or a how-to answered without an engineer, or a repeat of an issue already on file, is not counted as a new issue.
- Issues found in your code that got a draft fix: of the issues Watari found in your code with a Strong match, how many have a draft fix, and how many of those your team merged.
- Fixed issues where the customer was told: of the issues whose fix is live, how many customers have had their update.
Below the counts, Insights names one next step when there is one, such as fixed issues still waiting for a customer update, and How these are counted explains each word. Months follow your own time zone. Pick another month from the month list.
Share this month opens a one-page summary of the same month, with the same three counts first, then the detail: customer reports read, bugs written up, repeat reports grouped, reports kept away from engineering, issues found in your code, draft fixes opened and how many your team merged, and Where the issues were (bugs only). Choose Since you started for every month at once. Use Print or save as PDF to pass it on.
A few days after reports start arriving, the workspace owner also gets this summary by email, once, written so it can be forwarded to whoever decides.
Every figure is a count from your own workspace that you can check against the Issues list, and every role sees the same page. Watari does not estimate hours or money saved.
If no issue has appeared
If reports are arriving and no issue has appeared, check three things:
- Home: while setup is not done, Home names the step that is waiting and what is missing.
- Not filed on the Issues page: every ticket Watari read and did not turn into an issue, with the reason.
- Codebase: whether each repository can be searched, and the one thing to do when it cannot.
If none of these explains it, contact us with your workspace name and we will look at it with you.
Next: Ticket to bug: structured extraction and dedup, what Watari pulls out of each ticket and how duplicates are grouped.
Working in Watari day to day
Home shows what needs you and what Watari is working on. Issues sorts every report by whose move it is. Each issue page says the one next step and what to tell the customer. Codebase says whether Watari can search your code and where issues come from. Insights counts what Watari did each month.
Security and compliance
Token encryption, multi-tenant isolation, compliance status, data residency, and the sub-processor list.