thinkhard.SI

Prompt repository Customer support & success

Turn a customer complaint into a bug report for engineering

You need steps to reproduce, expected and actual behavior, and impact written from a messy ticket.

Registry no.
SUP-015
Collection
Customer support & success
Laid out for
Any chat model
Score
10 out of 10
Blanks to fill
4
Added

Customer support & successAny chat

The prompt

Score 10 of 10, Excellent

Use it when You need steps to reproduce, expected and actual behavior, and impact written from a messy ticket.

  • {{ticket}}
  • {{support_notes}}
  • {{technical_details}}
  • {{severity_levels}}
Full prompt and why it works
Prompt
Turn the customer ticket below into a bug report for our engineering team. Engineers will use it to reproduce and fix the problem, often without talking to the customer, so it must contain only observed facts, in steps they can follow.

Customer ticket and replies:
"""
{{ticket}}
"""

What support has checked or tried, including whether we reproduced it:
"""
{{support_notes}}
"""

Account and technical details we have (plan, browser, device, app version, account ID): {{technical_details}}

Our severity levels:
"""
{{severity_levels}}
"""

Use this format, with these exact labels:
Title: under 12 words, in the form "Area: what fails, when", for example "Invoices: PDF export fails for invoices over 100 lines".
Summary: two sentences.
Environment: plan, browser or device, version, and account ID.
Steps to reproduce: numbered, one action each, starting from a named screen.
Expected result:
Actual result: including any error message, copied exactly.
Frequency: every time, sometimes, or once, and whether support reproduced it.
Impact: who is affected, how many customers if known, and whether there is a workaround.
Suggested severity: one level from the list above, with a one-line reason.
Attachments mentioned: screenshots, logs or files the ticket refers to.
Questions for the customer: what we still need to know.

Rules:
- Separate what the customer saw from what they think caused it. Put any theory of theirs in Summary as "Customer believes...".
- Do not invent steps, versions or error text. Write "Not in the ticket" for anything missing.
- Leave out the customer's name, email, phone number and payment details. Keep the account ID only.
- Leave out apologies, frustration and back-and-forth that do not change the facts.
- If the severity levels say "none", leave out Suggested severity.

The report must be clear enough that an engineer can start reproducing the bug from the steps alone. If the ticket describes more than one problem, write a separate report for each. If the steps are too vague to reproduce, say so at the top and make the questions for the customer specific enough to fill the gap.

Variables

{{ticket}}
The customer's ticket and the replies so far, exactly as written.
{{support_notes}}
What support checked, tried or reproduced, and the results.
{{technical_details}}
Plan, browser or device, app version and account ID, as far as you know them.
{{severity_levels}}
Your team's severity definitions, or "none" to leave severity out.

Why it works

  • Format. Fixed labels in the order engineers work (environment, steps, expected, actual, impact) mean a bug can be picked up without a follow-up meeting.
  • What to avoid. Personal details stay out and the customer's theory is kept apart from what they saw, so engineers start from facts, not guesses.
  • If unsure. Missing details are written as "Not in the ticket" and turned into specific questions for the customer, instead of made-up steps.

How to use it

  1. Press Fill in variables and type your details into each blank. What you type stays in this browser.
  2. Copy the filled prompt into the AI tool you already use, such as ChatGPT, Claude or Gemini, or open it in the Grader or the Prompt Tester here.
  3. Before you rely on it, try it on three or four real examples. The Prompt Tester runs them all at once and shows which ones go wrong.