Home / Guides / Escalations and support operations

A bug report template from support to engineering that doesn't bounce back

By Draft First. Updated October 2026

A bug report from support has one job: let an engineer make the problem happen again without asking you a single question. When it bounces back with "can't reproduce" or "which version?", the customer waits another day. This template puts things in the order engineers read them.

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.

Why each part is there

• Title. Engineers search old bugs by title. Make it specific enough to find again.
• Steps from a known state. "Log in as an admin and open Reports" beats "go to the report".
• Expected and actual. Two lines, no adjectives. This is what the fix will be tested against.
• Environment. A common reason reports bounce back. Get it from the ticket before you write anything else.
• Evidence, quoted exactly. A paraphrased error message can send someone down the wrong path.
• Impact, counted honestly. It sets the priority, so don't round up. Link the tickets so anyone can check.
• Ruled out. Saves the engineer from repeating your first hour.
• Hypothesis, labelled. Useful if it's marked as a guess. Harmful if it reads as the cause.

Before you file

• Take passwords, tokens, keys and customer personal data out of logs, screenshots and recordings.
• Search for an existing bug. If there is one, add your ticket and impact to it instead of filing a new one.
• Tell the customer what happens next, without promising a fix date.

AI prompts that help

An AI agent is good at the gathering: pulling environment details out of a long thread, sorting log errors and quoting them. Use a tool your company approves, and paste only what you need.

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 other tickets

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.

For reading the logs themselves, start with the AI log analysis prompts. When the bug is fixed and the customer wants to know what happened, the root cause summary template has a customer version. Bugs that keep coming up also belong in your voice of the customer report.

Questions

What's the most important part of a bug report?

Steps an engineer can follow to make it happen again, starting from a known state. Without those, everything else is guesswork.

Should support suggest the cause?

You can, labelled as a hypothesis with the evidence that points to it. Don't present it as the cause, or the engineer may chase it instead of looking.

How do we show impact without inflating it?

Count the tickets and accounts you can link to this bug, and say how you counted. If you're not sure the tickets are the same bug, say so.

Can AI write bug reports from tickets?

It can draft one from the ticket and the logs, and it's good at pulling out environment details and quoting error lines. A person should run the repro steps before it's filed.