A bug report template developers can act on
Most bug reports bounce back with one question: "How do I reproduce this?" A good report answers it before anyone asks.
The template
Title: what broke, where. "Save button does nothing on the invoice page", not "Bug in billing".
Steps: numbered, starting from a page anyone can open.
Expected: one line.
Actual: one line, plus a screenshot of the moment it went wrong.
Environment: browser and version, OS, screen size, account role.
Console errors: copied as text, not as a photo.
Failed requests: the URL, status code and response, if any.
How often: every time, sometimes, once.
What developers actually need
The console error and the failed request usually point straight at the cause. They are also the part reporters skip, because opening dev tools mid-bug is awkward and the error is gone after a reload.
Keep customer data out
Bug reports travel: from the support tool to the tracker, into chat, into a vendor's inbox. Screenshots of a customer's account go with them. Replace real names, emails and card numbers before you attach anything, and check the request payloads too.
Record it instead
Pexli records the steps as you reproduce the bug and attaches console errors, failed requests and the environment for you. Detected emails, phone numbers, card numbers, and names and addresses in labelled form fields and table columns are hidden in the screenshots, and you review the report before you send it. See the bug report.