Start with the actual journey
Copy the full URL from the browser. Then describe the steps leading to the problem in their real order. For example: “Open the contact page, choose a subject, enter a message, press Send.” Add whether you were signed in and whether the fault happened every time or only once.
Separate expectation from observation. “I expected a confirmation; instead the button stayed grey” is more precise than “The form is broken”. Record the wording of an error message. If no message appears, that is a useful observation too. Avoid guessing the cause before anyone has investigated it.
The device, browser and approximate time can help narrow the problem. A screen recording often explains a moving sequence better than several unlabelled images. For a display fault, a screenshot with the affected area clearly marked may be sufficient. Make sure it includes enough surrounding context to identify where the problem occurs.
Share only the necessary information
Remove confidential messages, passwords and other customers' details from images and recordings. If a problem happens only with particular data, describe its relevant characteristics or agree a suitable private investigation method. A publicly shared fault image should not contain information that the investigation does not need.
Explain the effect: can nobody submit an inquiry, or is a label merely cut off? This helps determine the order of work. If an alternative route exists, mention it factually without treating that workaround as a completed repair.
After a correction, repeat the original sequence. Add the result to the same report. If only part has been fixed, identify the remaining step. The work then ends with a traceable check rather than simply a statement that someone changed something.
