


When something stops working, writing a support request can feel like another job standing between you and the work you need to finish. You should not need to understand the technology or diagnose the fault before asking for help.
A useful request simply explains what happened and why it matters. For business owners and office managers, giving staff a short, consistent way to report problems can make the first conversation with IT more productive. Here is a practical approach your team can use.
“My computer is broken” tells support that something is wrong. “I cannot open the quoting application, so I cannot send today's customer quotes” explains the business problem.
Describe what you were trying to do, what you expected and what happened instead. Include the application or device name if you know it. Copy the exact error wording rather than translating it into a diagnosis. If there is no error message, say so.
A useful subject line combines the affected task with the symptom: “Quoting application will not open on reception laptop”. Avoid putting confidential customer information in the subject line.
Tell support whether the problem affects you, several colleagues or an entire location. Describe any workaround and whether essential work has stopped. A printer fault has a different impact when a second printer is available than when a dispatch team cannot print any shipping labels.
Include the real time constraint, such as a payroll submission or a customer meeting. This helps support assess priority alongside other incidents. Writing “URGENT” repeatedly does not provide the same context, and a requested deadline is not a confirmed resolution time.
Office managers can help by identifying one contact for a widespread problem and collecting updates from affected staff. Keep support informed if the impact changes.
Note when you first noticed the issue, whether it happens every time or intermittently, and when the task last worked. Mention relevant changes you know about, such as moving desks or connecting a new monitor. Do not assume that the most recent change caused the fault.
List any steps already taken and their results. “Restarted once, same message appeared” is more useful than “tried everything”. Avoid repeating disruptive troubleshooting or changing settings just to fill out a request.
This reflects a principle used in formal vendor support: Microsoft's Azure support guidance asks for the problem's start time, reproduction steps, business impact and contact details. Your everyday helpdesk request can be much simpler, but those details remain useful.
A screenshot can show an error that is difficult to describe. Before attaching it, check for visible passwords, customer records, private messages, financial details and unrelated browser tabs. Crop or obscure unnecessary information while keeping the error readable.
Never include passwords, recovery codes or one-time sign-in codes in a ticket. If support needs logs or sensitive diagnostic files, ask which approved transfer method to use. A first report rarely needs a complete export of your mailbox or a folder of customer documents.
Include a contact method that will still work if the affected system is unavailable. If email is the problem, tell support how else to reach you and when you can be available to test a fix.
The following is a hypothetical example, not a customer incident:
Subject: Quoting application will not open on reception laptop
What happens: After signing in, the application shows “Connection unavailable”. I expected to see the quotes screen.
Impact: Two staff are affected. We cannot send quotes from these laptops. Another colleague can still access the application.
Timing: First noticed at 8:40 am today. It worked yesterday afternoon. We need to send a customer quote by 11 am.
Already tried: Closed and reopened the application once. The same error returned. A screenshot of the error is attached.
Contact: Please call my work mobile. I am available until 10:30 am.
Use the same headings for other issues. Unknown details can stay unknown. Send what you have, then add useful information to the existing ticket rather than starting a separate conversation each time.
A suspected security incident or major outage needs prompt attention through your organisation's agreed escalation route. Report what you have observed without waiting for a perfect screenshot or confirmation from every colleague.
The Australian Signals Directorate advises reporting potential cyber security incidents early, including when you think something may be a false alarm. For staff, the practical first step is to alert the designated IT or security contact and follow the organisation's response process. A routine support template does not replace that process.
Our view is that a support request should help a conversation, not become an entry test. Zarbtech's Helpdesk Services cover end-user troubleshooting, devices, connectivity, email and software issues. Understanding your environment matters, but so does understanding the work being interrupted right now.
If you are a Zarbtech customer, use our Concierge Support contact options to raise your issue. Bring the details you know. You do not need to arrive with the answer.