A false-fixed RCA is worse than no RCA at all. The customer reads “we fixed it” and verifies, still broken. Trust is gone in one cycle. Most ticketing tools fire the customer-facing update on merge, before the build is built, before the deploy lands, before a rollback gets a chance to undo the fix.
Sofia Marquez at Northpine Logistics writes to Spendhaven’s support team in Freshdesk. A C# / .NET codebase on Azure DevOps. An illustrative case, with fictional companies.
1. Freshdesk ticket #20417
Access denied when approving expenses
“I manage two teams, and every claim from my second team says access denied.”
Sofia Marquez, Northpine Logistics
2. Bug report
Managers of two teams cannot approve the second team's expenses
High
Expected: Expense approved. Actual: Access denied.
3. Found in your code
src/Expenses.Api/Controllers/ApprovalsController.cs
Approve()
The check only reads the manager's first team, so claims from their other teams are refused.
4. Draft fix, PR 418
Let managers approve expenses for every team they manage
Review in Azure DevOps
5. Customer update
Hi Sofia, you can approve expenses for both of your teams again.
Sent when the fix is live. Posted to ticket #20417.
The customer reads the RCA in production, not against your merge log. For platforms that report deployments to GitHub (Vercel, Netlify, Render, and most CD platforms), Watari holds the customer-facing update until your production deploy contains the fix. Not on merge. Not on build success. Only when the fix is provably live. (Don’t report deployments to GitHub? Switch to merge-confirmation; a periodic check and a manual confirm still keep it honest.)
Deploy confirmed · production
The fix is live as of 10:01 UTC. Customer update posted to the support ticket.
A later deploy can quietly back the fix out, and the customer is the last one to know. Watari re-checks every new production deploy; when the fix is no longer in the live deploy, the RCA holds, engineers see a rollback banner inline in the bug view, and auto-resume fires only when a later deploy re-includes the fix.
Deploy confirmed · production
The fix is live as of 10:01 UTC. Customer update posted to the support ticket.
A trust-killing apology email reads worse in machine translation than in plain English. Watari drafts the RCA in the language of the original ticket; English is the fallback when no language is detected. Internal engineering notes stay in English regardless of customer locale.
Deploy confirmed · production
The fix is live as of 10:01 UTC. Customer update posted to the support ticket.
On merge is too early. The customer is reading the RCA in production. We will not publish until production agrees the fix is live.
14d
Free trial of Growth. 3 repositories, 10 Mapped Issues. No card.
Trial policy
7d
Mismapped credit window
Billing model
0.7
Dual confidence gate
Billing model
The RCA cannot publish until the production deploy contains the fix, so the false-fixed case is closed at the gate. If a later rollback removes the fix from production, the bug re-opens, engineers see a rollback banner, and a follow-up RCA fires only when the fix is restored.
Every new production deploy is checked for every parked fix. If the fix is no longer in the latest production deploy, the bug is flagged as rolled back. The parked RCA holds, the bug view shows the banner, and engineers are notified.
Yes, with an audit log. Engineers can force-publish the customer-facing RCA before the production deploy confirms the fix. The override is recorded with actor, timestamp, and reason: the gate exists by default, the override is the rare exception, and the record makes it reviewable later.
Watari drafts the RCA in the language of the original ticket. English is the fallback when no language is detected on the ticket. Internal engineering notes stay in English so reviewers see consistent context regardless of the customer locale.
Yes. The RCA enters a draft state when generated; engineers can edit, regenerate, or approve before the deploy gate unlocks customer delivery. Once approved, delivery waits only on the production deploy; the edit window closes when the fix lands in production.
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.