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.
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.
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.
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.
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.
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.