Atul Singh logoAtul Singh
← Back to prompts
SupportCustomer Support Specialistbeginner 15 min saved

Customer Feedback to Engineering Issue Report

Turn customer bug reports into neutral, evidence-based engineering issue reports.

Customise & copy

Add the context you have. The prompt updates as you work.

Paste the customer's complete message, including relevant error wording.

Paste log excerpts, screenshot text, error codes, or write Not provided.

Add any account ID, order ID, case ID, or write Not provided.

Include timestamp, timezone, OS, browser, device, product version, and environment when available.

Paste the customer's described actions or write Not provided.

Live prompt

5 fields
Convert the provided customer feedback and context into one neutral, factual engineering issue report. Remove emotional, accusatory, and speculative language. Preserve concrete actions, exact error text, timestamps, environment details, identifiers, and reproduction information. Do not invent, infer, or normalize missing facts. If information is absent, write "Not provided" or list it under Unknowns. Return only this format:

Title: [Feature/Module] - [Brief Issue Summary]

Summary: [One concise factual description]

Steps to Reproduce:
1. [Factual step]
2. [Factual step]

Expected Behavior: [What should have happened]

Actual Behavior: [What happened, including exact errors or observable effects]

Environment: [OS, browser, device, product version, deployment environment, or Not provided]

References: [Relevant account/order ID, incident timestamp, logs, screenshots, or Not provided]

Unknowns:
- [Missing debugging information]

Customer message:
{{customer_message}}

Attached evidence or error details:
{{diagnostic_evidence}}

Account or order context:
{{account_context}}

Incident timing and environment:
{{incident_details}}

Reproduction steps described by the customer:
{{reproduction_steps}}

Proof before you use it

A real example

Tested on gpt-5.6-luna on 2026-09-09

{
  "account_context": "Tenant ID TEN-7742; export job ID JOB-90816",
  "customer_message": "Our payroll export failed again this morning. The dashboard says it finished, but the file has no employee records. We need this fixed before payroll processing.",
  "incident_details": "2025-03-03 07:45 America/Chicago; macOS 14; Safari 17; production payroll platform",
  "reproduction_steps": "Open Payroll, select February 2025, choose CSV export, include all employees, and click Generate.",
  "diagnostic_evidence": "Export job log: status=completed, records_written=0, file_size=2 KB. No screenshot supplied."
}

A small ritual that works

How to use it

  1. 01Paste the complete customer message into Raw customer message.
  2. 02Add available logs, screenshots, error details, and account or order context.
  3. 03Enter incident timing, environment details, and customer-described reproduction steps.
  4. 04Review the structured report and verify that unknowns are explicitly listed.

Why it works

The prompt gives the model a clear transformation task: convert customer-facing material into a neutral engineering issue report. It separates source inputs into distinct fields for the customer message, evidence, account context, incident details, and reproduction steps, which helps preserve the origin of each fact. The required report format covers the core engineering sections—summary, reproduction, expected and actual behavior, environment, references, and unknowns. Instructions such as preserving exact error text, timestamps, identifiers, and observable effects while avoiding invention or speculation establish a disciplined boundary between documented facts and unresolved information.

Where it fails

The prompt cannot supply facts that are absent from the provided material. Its instruction to avoid inference means that incomplete customer descriptions may lead to "Not provided" entries or unresolved items in Unknowns rather than a fully specified incident record. It also depends on the input fields being populated with sufficiently concrete source information; vague, contradictory, or purely emotional feedback leaves limited factual material to organize.

Customisation tips

Adapt the report headings to match the receiving engineering team's workflow, such as adding severity, impact, affected component, owner, or status if those fields are needed. Update the input variables' helper text and placeholders to reflect the identifiers, environments, and evidence types used by your organization. If structured ingestion is important, define whether dates, identifiers, error codes, and environment names should follow specific conventions. Keep the instruction to distinguish documented facts from unknowns, and preserve the raw customer message as a source field so factual wording can be traced back to its origin.

Watch-outs

  • The prompt requests a neutral report, so emotionally important customer details may be reframed as observable effects unless they contain concrete incident information.
  • Expected behavior may be unavailable in the source material; the format does not authorize inventing a product requirement.
  • Customer-described reproduction steps are not the same as independently confirmed steps, so their origin should remain clear.
  • Evidence fields can contain sensitive account, order, log, or screenshot information; apply the organization's handling rules before sharing the resulting report.

Works in

Customer supportTechnical supportBug triageEngineering handoffsIncident intake

Was this useful?

Submit your variation

If your version helps, it may be published with your name and a link back to you.

Want to make AI useful across your team? Explore Atul's training.