A customer writes "it just stopped working after the update". You know that is a bug report in disguise, but engineering will not touch it. They need to know what was expected, what happened, on which version, and what the customer already tried. The message has some of that, scattered, and a lot of feeling.
The usual fix is a round of questions, or an engineer guessing. A better first step is to separate what the customer actually said from everything else, and ask only for what is missing.
What you need
- The customer's message, as they wrote it.
- The product name and version, if you know them.
- Any logs or error text they pasted. Remove passwords and keys first.
The prompt
Paste this into a new chat, then paste the message.
You are writing a bug report from one customer message, pasted below. Work only from that message. Never invent a version, a step, an error text or a cause.
Mark every fact as Stated (with a short word-for-word quote), Inferred (say why) or Missing. Do not give a cause. If the message mentions screenshots or files you cannot see, say they exist and were not read.
Write:
1. A title in the form "what fails, in what situation", with no blame.
2. A two-sentence summary.
3. What the customer says, as bullets with quotes.
4. Environment: a table of what is stated, with [CONFIRM: ...] for what is missing.
5. Steps to reproduce, only if the message gives enough. Otherwise "Not enough to reproduce yet".
6. Expected and actual, in the customer's words.
7. At most four easy questions to ask the customer, most important first. Do not ask for anything already in the message.
8. A reply to the customer of under 120 words that promises nothing about a fix or a date.
MESSAGE:
[paste here]How to check the result
Check the quotes against the message. If the assistant has tidied a quote, put the customer's words back.
Look at the environment table. Anything marked [CONFIRM: ...] is something engineering will ask for in their first reply, so get it before you file.
Read the questions for the customer. Each one should be easy to answer: where to click, what to copy. If a question needs the customer to understand your system, rewrite it.
Read the reply as the customer. It should say what you understood and what you need. It should not promise a fix.
What good output looks like
This is an invented illustration of the shape. Title: "Export button does nothing on the reports page after the update." Stated: "I click export and nothing happens" (quote). Environment: "Version: [CONFIRM: version]. Browser: stated, a recent desktop browser." Not enough to reproduce yet, so the steps are the ones the customer reported, labelled as reported.
The questions might be: "Which browser and version are you using?" and "Does the same thing happen on a different report?" Both can be answered in one line.
Notice that no cause appears anywhere. If the draft says "probably a caching issue", delete it. A guess in a bug report becomes a fact by the time it reaches the third person.
Keep the customer's original message attached to the ticket, next to your cleaned version. Engineers sometimes spot something in the raw text that the summary lost.
Limits
- It cannot open screenshots or log files unless your chat tool can, and it says when it did not read them.
- It does not find the cause. If the message points to an area, it labels that as a guess.
- It does not file the ticket or send the reply.
- One message at a time. A long thread needs you to pick the key messages first.
Follow for new free skills
New free skills and guides appear in all of these as we publish them. Pick whichever you already use.
- RSS feed for any feed reader
- Watch the free skills repo on GitHub
- Follow on Gumroad