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

A support-to-engineering bug report template has been published that orders fields the way engineers read them, from a precise title and numbered repro steps to environment details, exact log quotes, impact counts and a "already ruled out" section. The template pairs with LLM prompts that extract environment details and quote errors from ticket threads while marking unseen fields as [MISSING] or inferred steps as [CONFIRM], and it separates confirmed duplicates from a "Possible" bucket to keep impact counts honest. A human is expected to run the repro steps before anything is filed.

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 .