Support/First-party starter playbook

Bug report packager

Turn Zendesk tickets tagged as bugs into clean, deduplicated Jira issues engineering can act on.

// what it does
  1. 01Find new bug tickets. Search Zendesk for tickets with the bug tag and without the filed tag. Bound the run to 20 tickets.
  2. 02Read the report. From each ticket's description and comments, extract the steps to reproduce, expected and actual behavior, environment (browser, device, app version, account plan), error text, and when it started.
  3. 03Look for an existing issue. Search the Jira project with JQL for an open issue describing the same failure. Compare symptoms, not just wording.
  4. 04Prepare the escalation. For a new bug, draft a Jira issue with a specific title, the reproduction steps, expected and actual behavior, environment, and the ticket link. For a known bug, prepare a comment on the existing issue adding this ticket and customer. List any required field the ticket does not answer.
  5. 05[Approval gate] Review each proposed new issue or comment before anything is created in Jira.
  6. 06File it. Create the approved issues and comments, then add the filed tag to each Zendesk ticket.
  7. 07Notify. Post new issues to the Slack channel with the title, the number of affected tickets, and links.
// guardrails in the draft

Remove customer names, email addresses, and account identifiers from the Jira issue; link the Zendesk ticket instead.

Never reply to the customer or change the ticket's status, priority, or assignee. Adding the filed tag is the only Zendesk change.

Never guess at reproduction steps. If the ticket does not include them, say so in the issue.

One bug gets one Jira issue. When unsure whether two reports are the same bug, keep them separate and say so.

Make bug report packager yours.

Request access and we'll start with a private draft. You keep control of the tools, permissions, tests, and publication decision.