A bug report from support has one job: let an engineer make the problem happen again without asking a single question. Every "can't reproduce" or "which version?" adds a day for the customer.

Here's a template that puts things in the order engineers actually read them, plus a few AI prompts that do the boring gathering without making things up.

The template 

Title: [what breaks, for whom, where] Good: "CSV export times out over 10k rows (web app, all plans)" Not: "Customer says export is broken" Steps to reproduce (from a known starting state): 1. [Log in as a user with role X / open page Y] 2. [Action, with the exact data or file used] 3. [Action] Expected: [what should happen] Actual: [what happens, with the exact error text] Reproduced by support? [yes, on date / no, and why not] Environment: [app version or build, browser and version, OS, account or workspace ID, region, plan] Evidence: [log lines quoted exactly, with timestamps and time zone; screenshot or recording; failing request if you have it] Impact: [linked tickets: #IDs | accounts affected: count and how you counted | first seen: date | workaround: yes or no, and what] Already ruled out: [cache cleared, other browser, permissions checked, known issue list searched] Hypothesis (optional): [what you suspect and the evidence for it] Source ticket: [link]. Don't paste the whole customer thread.

The parts that matter most

  • Steps from a known state. "Log in as an admin and open Reports" beats "go to the report".
  • Expected vs actual, two lines, no adjectives. That's the acceptance test for the fix.
  • Environment. A common reason reports bounce. Pull it from the ticket before writing anything else.
  • Evidence quoted exactly. A paraphrased error message sends people down the wrong path.
  • Impact counted honestly, with ticket IDs. It sets priority, so it has to be checkable.
  • Ruled out. Saves the engineer from repeating support's first hour.
  • Hypothesis, labelled as one. Useful as a lead. Harmful if it reads like the cause.

AI prompts for the gathering

An LLM is good at pulling environment details out of a long thread and quoting log errors. It's also good at confidently filling in a field it can't see. So these prompts make missing data visible instead.

Strip passwords, tokens, keys and personal data before pasting anything, and use a tool your company approves.

Draft the report from the ticket 

Using this ticket thread and the log lines below, fill in this bug report template: [paste the template]. Take environment details only from the ticket or logs. If a field isn't there, write [MISSING] so I know what to ask for. Quote error messages and log lines exactly, with their timestamps. Write the steps to reproduce as numbered steps from a known starting state, and tag any step you're inferring as [CONFIRM]. Label any cause as Hypothesis with the lines that point to it. This is a draft for me. Don't file it or contact anyone.

Ask the customer for what's missing 

List every field marked [MISSING] or [CONFIRM] in the bug report. Draft a short, friendly request to the customer for those details as a numbered list. Remind them to remove passwords and personal data before sending logs or screenshots. Don't promise a fix or a date.

Find the duplicates 

Search [ticket export for the last 30 days] for tickets that might be this same bug: [one-line description and the exact error text]. List each with ID, date and the matching phrase. Put tickets that are only maybe the same under "Possible" and say why. Don't count a ticket twice.

The "Possible" bucket matters. Inflated impact counts get bugs prioritized for the wrong reasons, and engineers stop trusting support's numbers.

Then a person runs the repro steps before anything gets filed.

Full guide, with why each field is there and a pre-filing checklist: Bug report template: support to engineering.

Want one complete routine with guardrails and a sample result? Get the free play at https://draftfirstcs.com/free