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
Top comments (0)