A report that the network is slow may describe a problem with one business application, one location, or one part of a workflow. The application owner can help define the actual experience before a technical team starts changing the environment.
Describe the transaction
Ask what the person was trying to do, which step failed or took longer, and whether the same task worked elsewhere. Record the time and any relevant changes that the application team already knows about.
Compare observations rather than trading conclusions. A network measurement and an application log may each be useful, but their relationship needs investigation by the responsible teams.
Agree on the next test
Choose a repeatable user action and identify which teams need to observe it. Confirm the approved conditions and how results will be recorded. Avoid exposing business data in screenshots or informal messages.
Keep the follow-up focused on the unresolved question. If one part of the path has been checked, record what that check establishes and what it does not establish. This prevents a partial result from becoming a blanket declaration that another team owns the problem.
Practical takeaway
Start troubleshooting reviews with a specific user task and a shared description of the observed failure.