# A Bug Report Template From Support to Engineering (So Nobody Has to Ask "Which Version?")

> Source: <https://dev.to/draftfirst/a-bug-report-template-from-support-to-engineering-so-nobody-has-to-ask-which-version-2d4a>
> Published: 2026-10-19 02:09:31+00:00

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](https://draftfirstcs.com/guides/bug-report-template-support-to-engineering).