People reporting a technology problem can usually explain how it affects their work, even when they cannot diagnose it. That information is more helpful than choosing an urgent label without context. Design request forms and instructions around the impact the service team needs to understand.
Ask what work is affected
Record the affected task, location, users, and time of the observation. Ask whether there is an approved workaround and whether other people see the same issue. Leave room for the reporter to say that the extent is unknown.
Avoid requiring a technical cause before someone can submit a useful request. A person should not have to guess that a switch failed to explain that a shared application is unavailable.
Explain what happens next
Tell users where the request goes and how the agreed service process assesses it. Keep response commitments aligned with the actual service arrangement.
When the impact changes, provide a way to update the original request. New information should reach the team working on the issue rather than create several disconnected tickets with different descriptions of the same event.
Practical takeaway
Use task, location, affected users, timing, and workaround status as the starting points for a clear support request.