Customer bug reports

Each day the automation reads new Zendesk tickets, identifies which ones describe genuine bugs, checks them against the open issues in Jira so it is not re-filing something already tracked, and creates a clean issue for anything new with the reproduction details from the ticket attached.

Engineering gets a tidy, deduplicated bug queue drawn straight from real reports, and the triage that used to depend on memory happens reliably, every day.

Scoped access

• Zendesk, read tickets
• Jira, read and create issues

How it fails silently

Bug filing fails silently in both directions. The dedupe is too aggressive and files a genuinely new defect as a comment on an existing issue that merely sounds similar, so the new bug inherits a closed or backlogged status and is never worked. Or the classifier decides a ticket with a clear reproduction step is not a bug and closes the loop. Either way the count looks healthy, the queue looks managed, and a real defect affecting real customers is now invisible, not because anything errored, but because it was quietly sorted into the wrong place.

What the overseer catches

After each ticket is sorted, the overseer rereads it against the call the agent made. A new defect folded into an existing issue whose details do not really match, or a ticket with a clear reproduction waved off as not-a-bug, is the mismatch it catches, raising it for a human so a real defect does not stay buried in a duplicate or a dismissal.

Clear duplicates and clear non-bugs are handled, and unambiguous new defects are filed in Jira with their reproduction details, with no daily triage meeting required.

What reaches engineering is the uncertain case: the report that might be new or might be known, the ticket that is borderline between a bug and a question. Those land flagged for a human read, so a real defect that got mis-sorted gets caught instead of staying buried.