Your first week
What to expect on day one, day three, and the end of week one. Sets realistic accuracy expectations as your codebase finishes indexing.
TL;DR
Your first week
Watari is useful from day one, but it gets noticeably better over the first week as your index matures and your team makes a few corrections.
Day 1 — connect and watch the first tickets arrive
Connect your support tool and install the GitHub App (see the 10-minute quickstart if you haven't yet). Once both are in place:
- New tickets start flowing in automatically via webhook. You don't need to import history — Watari processes tickets as they arrive.
- The repository index builds in the background. For a typical SaaS codebase, the first pass completes in a few minutes. Watch progress under Codebase in the dashboard.
- Bug extraction runs immediately, even while indexing is in progress. Code mapping begins as soon as the index is ready.
Early extractions may feel sparse if your first tickets are billing questions, account access requests, or vague "something seems off" reports. Those aren't extraction failures — those ticket types don't contain reportable bugs and are classified and skipped by design. The extraction step is looking for software defects, not customer service topics.
AI extraction is fallible by design. If you see a bug where a field was extracted incorrectly — wrong severity, inaccurate repro steps, off-target description — edit it directly on the bug detail page. The corrected fields are what flow into code mapping and PR generation. Corrections accumulate as signal and improve downstream quality.
Day 3 — first Mapped Bugs appearing
By day three, assuming a steady ticket flow, you should be seeing Mapped Bugs in the Tickets view at /tickets. A Mapped Bug means both extraction and code mapping passed their confidence gates — Watari found a specific file and function in your repository that it believes is responsible for the bug.
Review the first few carefully. This is the highest-value thing you can do early in the relationship:
- Open each Mapped Bug and read the mapped code locations. Do they point at the right file and function?
- If the mapping is wrong, click the mismapped button on the bug detail page. This records the error, decrements your usage counter, and queues a credit for your next invoice. You have a 7-day window from the bug's billing date to file a mismapped claim — see The Mapped Bug meter — qualification and mismapped credit policy for the exact policy.
- 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 (not auto-published). Watari drafts RCAs but never publishes them automatically unless you've switched to auto-publish in Settings → AI Behavior → Deploy & RCA. The draft sits in your queue until an engineer clicks Publish from the bug detail page.
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
Extraction accuracy on customer-language tickets — plain English, support-chat prose, mobile screenshots — is typically 80–90% for structured fields like severity and repro steps. Non-English tickets work as well; set your extraction language in Settings → AI Behavior if your team prefers reading structured fields in a language other than English.
Code mapping accuracy depends heavily on your repository's organization. Two things meaningfully improve it:
- A
.github/CODEOWNERSfile that maps directories and files to owners. Watari uses it for reviewer routing and uses the ownership graph as a signal during mapping. - Descriptive function and variable names. A function named
handlePaymentGatewayTimeoutgives the mapping step far more signal than one namedhandler3.
Accuracy numbers stabilize as the index matures over the first 2–4 weeks of real ticket flow.
When to contact us
If you've processed 50 or more tickets and haven't seen a single Mapped Bug, something is misconfigured — the most common causes are a GitHub App that wasn't granted access to the right repositories, an index that silently stalled, or a support-tool connection that isn't forwarding the right ticket types.
Contact us at /contact and include your workspace name. We'll diagnose it with you.
Next: Ticket to bug — structured extraction and dedup — how the extraction pipeline works under the hood.