Start with business impact
Describe what is being affected in the business first. That may be a department, workflow, user group, or customer-facing process. Engineers can work backwards from impact much faster than they can from isolated symptoms.
If the issue is intermittent, explain what the business experiences when it happens. Even a short explanation of when the problem appears can reduce wasted troubleshooting time.
Identify the systems involved
List the systems, applications, devices, or locations that seem connected to the issue. You do not need to know every dependency, but naming the visible parts of the environment gives the support conversation a stronger starting point.
It also helps to say whether the issue affects one person, one office, or a broader group. Scope matters early.
Clarify urgency honestly
Urgency should reflect operational impact, not just frustration. If revenue, security, access, or critical workflows are at risk, say that directly. If the issue is important but not business-stopping, that context matters too.
Clear urgency helps an engineer prioritize without guessing what pressure the business is actually under.
End with what good looks like
It is helpful to explain what resolution means from your perspective. That might be restored access, reliable performance, reduced risk, or a clearer support path for future issues.
That gives the conversation an outcome to work toward instead of staying stuck in symptoms alone.