Separate expectation from observation
Explain the task you intended and what happened instead. “Saving shows an error, and reopening does not show the change” says more than “not working”. Include the exact error text where it contains no confidential information.
State the time and relevant environment, such as application version, browser or device, where known. Avoid presenting assumptions as facts. A problem appearing after a change does not establish that the change caused it.
Reproduce a small example
Record steps from the starting state to the fault. Use appropriate sample data if the issue also occurs with it. A reduced case makes investigation easier and avoids unnecessarily sharing complete client records.
Check whether the problem happens every time or only occasionally. If it cannot be reproduced reliably, describe the frequency observed and any differences. Do not repeat a potentially harmful action merely to improve the report.
Attach evidence selectively
A screenshot should show the relevant state. Remove or obscure unnecessary personal details and access information before sharing it. Add a brief description of what the recipient should notice.
List measures already tried and their results. “Signed in again; fault unchanged” prevents repeated suggestions more effectively than claiming to have tried everything. If a temporary workaround exists, explain its limits.
Keep replies connected to the case
Use the ticket reference in later messages. Add observations in the same context instead of opening several disconnected reports. Say when the state changes or the fault no longer occurs.
Then test the support response in the affected workflow. A suggested step is not a confirmed outcome. Record what actually helped so the team can use a traceable finding when a similar case arises.
