Everyone who works with technology eventually needs help.
The difference between a frustrating help request and a useful one is often the information you provide.
Compare these two messages:
It doesn't work.
and:
I’m trying to connect to the virtual desktop. I can complete the sign-in, but after authentication the workspace does not open. I tried the connection once more and received the same result. I attached a screenshot of the message that appears. What should I check next?
The second message gives another person something to work with.
You do not have to diagnose the problem before asking for help. Your job is to describe the situation accurately enough that another person can begin diagnosing it with you.
First explain what you were trying to accomplish.
Examples:
I’m trying to sign in to Slack on my computer.
I’m trying to connect to the virtual desktop.
I’m trying to submit the screenshot required for the activity.
This establishes the expected outcome.
Without the goal, the recipient may know what happened but not what you wanted to happen.
Next identify the important action or step that led to the problem.
You usually do not need to list every click from the beginning.
Focus on the step closest to the unexpected result.
For example:
I opened the virtual desktop client and completed the institutional sign-in.
That is more useful than:
I followed all the directions.
Specific actions give the other person a place to start.
Now report the observable result.
Try to separate observation from guessing.
Observation:
After sign-in, the client returned to the connection screen.
Guess:
The server is broken.
The first statement tells the recipient what actually occurred. The second claims a cause that you have not established.
When you do not know the cause, that is fine. Accurate evidence is more useful than an confident guess.
If the system displays an error or warning, include the exact wording when possible.
Do not reduce:
Authentication completed, but the requested desktop could not be started.
to:
It gave me an error.
The exact message may contain the clue that distinguishes one problem from another.
You can type the relevant message or provide a useful screenshot.
Before sharing a screenshot, review it using the four questions from How to Capture a Useful Screenshot:
A short list of relevant checks can prevent repeated suggestions.
For example:
I closed and reopened the client and received the same result.
or:
Slack opens correctly on my computer, but I cannot see the course workspace.
Only include checks you actually performed.
Do not claim that you restarted, reinstalled, tested, or verified something if you did not.
And avoid changing many settings before asking for help. If you make several changes at once, it becomes harder to know which change mattered.
A support request should never require you to send:
A screenshot can accidentally reveal the same information, so review it before sharing.
You can describe a sign-in problem without sharing the information used to prove your identity.
Finish by telling the recipient what kind of help you need.
Weak ending:
Please help.
Stronger ending:
What should I check next?
or:
Is this the correct workspace, or should I be seeing a different one?
or:
Is there another approved connection step I should try?
A clear question helps the other person respond to the actual need.
When you are unsure what to write, use this structure:
Goal
What were you trying to accomplish?
Action
What important step did you take?
Result
What actually happened?
Evidence
What message, screenshot, or observable state supports that description?
Relevant checks
What have you already tried or verified?
Question
What do you need help deciding or doing next?
You do not need to label those sections in every message. The structure is there to help you think.
Here is a weak request:
Hi, VDI doesn't work. I tried a bunch of stuff and nothing fixed it. What do I do?
Before reading further, identify at least three pieces of information that would make the request more useful.
A stronger request would need information such as:
Notice that the stronger version does not need a guessed diagnosis.
When asking for technical help:
You do not need to know the answer before you ask for help. You need to provide accurate information that helps the troubleshooting process begin.