Prepare the moment when the request becomes uncertain
A first discussion is easier when the example contains a specific uncertainty. “Our ordering system is unreliable” describes a concern but leaves the possible causes wide open. “Customers sometimes see no receipt, while staff find two similar requests” gives the conversation a place to begin.
You do not need to prove the cause. The purpose of the example is to make the observed task understandable without filling the missing evidence with a guess.
Describe both sides of the same occasion
Write down what the customer did and what appeared next. Then describe what the staff member could find. Use a fictional reference to connect the two descriptions. Include the selected item or task only to the extent needed to explain the issue.
For example, a buyer chooses a replacement filter, changes the quantity and sends the enquiry. The acknowledgement is unclear, and the operator later sees the old quantity. The relevant question is where the change stopped being reflected. A new catalogue design may or may not address it.
If the problem is intermittent, state what is known about the occasions. A particular role, browser condition or recent release may help investigation. Avoid turning a correlation into the cause before the evidence supports it.
Add the context needed to assess the work
Name the organisation, intended users and purpose. Identify current providers and the account owner who can answer questions about their supported arrangement. This information is needed to review the project's circumstances before an engagement is agreed.
Explain the desired outcome in operational terms. An operator might need to distinguish a corrected request from a duplicate. A customer might need a receipt that can be found later. Those outcomes are more useful than requiring a dashboard before its purpose is clear.
Bring the right material, not the largest collection
A public link, a redacted screenshot or a short fictional sequence may be enough initially. Leave out customer exports, credentials and payment information. Access to private systems is arranged later through an agreed method if it is necessary for the scoped work.
Identify who can approve product facts, process rules and language meaning. If there is a deadline, explain what depends on it. The discussion can then distinguish a hard dependency from a preferred date without treating either as a delivery promise.
The next step may be a bounded investigation, a content correction or a proposed development scope. Each should identify the remaining questions. Send the task description, or use the project brief when several people need to agree the example first.