Why Watari bills the Mapped Bug — and bundles the rest of the pipeline

Watari bills exactly one event — the Mapped Bug, a customer support bug that has been extracted and mapped to a specific file and function with high confidence. Draft pull requests, customer-facing root-cause analyses, and sync to Slack, Linear, Jira, and GitHub Issues are bundled into the subscription and never increment the meter. We chose this model after walking through every alternative and watching each one create the wrong incentive.

Why the meter fires at extraction-plus-mapping

The Mapped Bug is Watari's value metric — the moment a stream of customer support pain becomes an actionable engineering task. Before extraction, the ticket is a string of customer prose. Before mapping, the bug is a structured description without an owner. The instant Watari binds the bug to a specific file and function, every downstream step becomes mechanical: draft the PR, run CI, request review, iterate on comments, deploy, write the RCA, post it to the customer.

Pricing on the value moment has two compounding effects. First, it lets customers predict cost as a function of inbound ticket quality, not pipeline behaviour. Second, it removes the incentive to skip later stages — there's no money to save by not using the PR draft, so teams use it.

Why we bundle PR drafting, RCA, and ticket sync

Once a Mapped Bug exists, the rest of the pipeline is mechanical. Charging per draft PR would create a perverse incentive: skip the PR to save the line item. Charging per RCA would do the same — and worse, would discourage the customer-facing communication that closes the loop. Charging per Slack notification would push teams to disable routing.

Every gameable edge a metered pricing model creates is a feature your customers will eventually exploit, because pricing pressure is a real force. The right move is to align price with value at one well-defined moment, then make everything downstream feel free. The Mapped Bug meter doc describes the qualification rules in detail; the pricing page has the tier table.

What we considered and rejected

The Mapped Bug stayed standing because it's the only metric where the customer's incentive (more high-confidence bugs mapped) matches Watari's value delivery (more high-confidence bugs mapped).

The fairness rails

Pricing on AI output requires fairness rails because customers can't audit the model themselves. Watari ships three:

1. Confidence thresholds, not soft fuzzes. A bug only qualifies as Mapped when its extraction confidence AND at least one code-location confidence both clear the configured thresholds. The thresholds live in the Mapped Bug meter doc and are not silently tuned.
2. The 7-day mismapped credit window. From the moment the meter fires, you have a week to flag the bug as mismapped with a reason code. Credits apply to your next invoice automatically — there's no Razorpay refund ceremony, no support-ticket escalation.
3. Configurable hard caps. Every tier carries an allowance, an overage rate, and a hard cap. At 80% of allowance, Watari posts a warning. At the hard cap, the meter pauses — new bugs queue without billing until you raise the cap or the next cycle starts.

Why this matters for prospects evaluating Watari

The objection most teams raise when evaluating usage-based AI tooling is bill predictability. "We can model how many tickets we get per month. We can't model what the AI charges us." The Mapped Bug answers that objection by making the meter behaviour-predictable: tickets that aren't reportable bugs don't meter, bugs that don't map don't meter, bugs that map but get flagged mismapped within a week refund. The variable you have to forecast is "how many high-confidence bugs will our support tickets surface this month" — which is a known quantity for any team running Zendesk or Intercom for six months.

If you want to see the model in practice, the Quickstart walks through the first ticket-to-PR cycle. The invoices and credits doc covers everything else.