Write an IT support request that someone can act on

A useful IT request tells the support team what happened, who is affected and what the business needs restored. Clear evidence saves the first conversation from becoming a guessing exercise.

Lead with the symptom and impact

Write a short subject such as “Two users cannot open the shared project folder since 09:20” rather than “Urgent IT problem”. In the message, explain the task that is blocked and whether there is a temporary alternative.

Do not diagnose beyond the evidence. “The screen shows this error” is more useful than “the server is broken” when you do not know the cause. Support can investigate the technical explanation once the symptom and scope are clear.

Use a five-part request

Part	What to include
Affected service	Application, device or location, with an existing reference if available.
Observation	Exact visible error or behaviour, with private information removed.
Timing	When it began, frequency and whether it previously worked.
Scope	One person, several people or the whole site.
Impact	The work blocked, deadline and contact who can discuss it.

Include changes and safe checks

Mention a recent update, move, new device or other relevant change. Explain what you already tried so the next person does not repeat it unnecessarily. If a restart or another action would disrupt unsaved work or important evidence, say so before proceeding.

Use the organisation’s approved support process for any remote access or diagnostic collection. Do not install a tool from an unsolicited message or grant access to someone merely because they claim to be helping with the ticket.

Remove secrets from screenshots

A screenshot can expose customer records, email content, account names or one-time codes. Crop or redact unnecessary private information and use the approved channel for sensitive evidence. Never include a password or recovery key in an ordinary support request.

If the issue concerns missing data or a suspected security event, preserve what you observed and avoid repeated experiments. State the data priority or security concern clearly so the request can follow the appropriate assessment or escalation route.

Keep follow-up in one traceable place

• Use the existing reference when adding new information.
• State what changed since the last update.
• Confirm whether the original task now works.
• Identify any remaining symptom instead of replying only “still broken”.
• Close the request when the agreed outcome has been checked.

Severity and response commitments depend on the service agreement. Sending the same issue through multiple channels does not create an emergency-response contract and can split the evidence. Follow the agreed escalation route when the impact changes.