Decide if it is a bug at all
Before you write anything up, check the basics: is the feature meant to work this way, and has the customer got the right plan, permissions and settings? Many reports turn out to be questions. Answer those and keep the engineers for real bugs.
Ask for the five things engineers need
Most reports become reproducible once you have the same five details. Put them in a saved reply so you ask every time.
- What the customer was trying to do.
- What they expected to happen.
- What happened instead, with the exact error text.
- Where it happened: page, device, browser or app version.
- A screenshot or short screen recording.
Try to reproduce it yourself
Follow the customer's steps in a test account. If it happens for you too, you have a report an engineer can start on at once. If it doesn't, note what you tried; that tells the engineer where not to look.
Write the report in a fixed shape
Use the same headings every time so engineers know where to look: summary, steps to reproduce, expected result, actual result, who is affected and a link to the ticket. Keep opinions out; state what you saw.
Say how many people are affected
Engineers prioritise by impact. Say whether one customer or many have hit it, whether there is a workaround and whether money or data is at risk. Count the tickets rather than guessing.
Keep the customer in the loop
Tell the customer you have passed it on, what you need from them if anything and when you will next update them, even if the update is that there is none yet. Tag the ticket so you can find everyone to tell when it is fixed.