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:
and:
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:
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:
That is more useful than:
Specific actions give the other person a place to start.
Now report the observable result.
Try to separate observation from guessing.
Observation:
Guess:
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:
to:
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:
or:
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:
Stronger ending:
or:
or:
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:
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.