Ask for Help at Work Without Making People Guess
Put the problem and the ask in the same message. Say what you are trying to do, what happened, what you have already checked, and which next step you need. Add a real deadline when one exists. You can be friendly without making someone reply to a bare 'got a sec?' before they know what you need.
Miles Crawford
A useful request has a clear next step
Our working pattern is goal, observation, attempt, ask, timing. It is a checklist, not a form you must complete before you deserve help. If you do not know what to try, say that. If work is urgent or unsafe, use your team's escalation route instead of polishing a chat message.
| Part | What to include | What to avoid |
|---|---|---|
| Goal | The outcome you need | Only naming a tool or a guessed solution |
| Observation | What you can actually see | Presenting your theory as a confirmed cause |
| Attempt | Relevant checks and their results | A full diary or a claim that you tried everything |
| Ask | A decision, explanation, review or hands-on help | Making the reader infer the job |
| Timing | When the answer is needed and why | Calling something quick without knowing the effort |
GitLab's support handbook uses a similar idea: a short problem summary, relevant links, notable behavior and a direct ask. It also explicitly says its guidelines should not block people from asking for help. That second point matters as much as the checklist.
Replace the vague opening, not the friendly tone
Community guides such as No Hello and Don't Ask to Ask recommend including the actual question rather than waiting for someone to confirm they are available or qualified. Treat that as a useful writing habit, not a reason to scold a coworker. A greeting can stay in the same message as the request.
Compare these original examples:
Hi! Are you good with the booking system? I have a quick question.
Hi Sam, I need to move the client workshop from six seats to eight. The booking page shows six after I save. I reopened it and checked the confirmation email; both still show six. Could you tell me whether I need a new booking or an amendment? We need to confirm the headcount by 2pm.
The second message does not assume the system is broken, promise a quick job or hand off the whole booking without saying so. Sam can answer the specific question or explain who owns it. Use real observations in your version; do not invent checks to make the request look prepared.
Separate the problem from your proposed fix
If you ask only how to carry out a fix, you may hide the original problem. Thoughtbot's question-writing guide calls this the XY problem: asking about an attempted solution instead of the goal. In work chat, include both, and label the second as a theory.
I am preparing the monthly supplier total. The sheet's total is $240 higher than the invoice list. I checked for duplicate invoice numbers and found none. I think a tax row may be counted twice, but I have not confirmed that. Could someone review the total formula with me? Please do not change the source invoices.
This asks for a review and preserves a boundary. It does not instruct someone to delete a tax row based on a guess. The numbers are fictional examples, not a tax or accounting rule.
For a technical issue, include expected behavior, actual behavior and a small reproducible example when appropriate. Stack Overflow's guidance is for programming questions; adapt the principle rather than demanding code from someone reporting a nontechnical problem.
Include enough evidence, not the entire workspace
- Link the relevant ticket or document and summarize the issue in the message itself.
- Quote the exact error text when it matters. Use a screenshot when the problem is visual, such as a clipped button or wrong layout.
- Say which version, page, file or environment you checked if that distinction changes the answer.
- Remove passwords, tokens, personal data and unrelated customer details before sharing. Check the audience and file permissions.
A short excerpt can be more useful than a pile of logs. GitLab's ticketing guide recommends requesting only the information needed and explaining why it is needed. The same restraint helps when you are the person sending evidence. Do not publish private work material to a public paste site just because an online guide suggests a paste service.
Choose an audience and give people room to answer
Use the team's help channel or named owner when there is one. If the topic is sensitive, use the approved private route. Do not post the same question in several channels without connecting the copies; otherwise people may investigate separately without seeing each other's answers.
Name the response you need: a pointer to the right instructions, a decision between options, a review of your work or someone to take over. Those are different requests. For a larger job, ask about capacity rather than disguising it as a quick question.
For an ordinary follow-up, include new evidence or the approaching deadline instead of sending a bare question mark. No answer does not prove someone is ignoring you. If a deadline is at risk, use the team's agreed escalation path. Our mentions guide covers the platform controls; this is not a reason to notify everyone.
Close the loop with the result
Keep clarifications and the answer with the original request where possible. Slack documents replies in a thread as a way to organize the discussion. In Teams, follow the reply structure your conversation uses rather than scattering the result into an unrelated chat.
Resolved: the booking needed an amendment, not a new reservation. Sam confirmed the steps, I applied them, and the confirmation now shows eight seats. The updated booking is linked here. Thanks for the help.
A reaction is fine for a quick thank-you, but write the outcome when other people need to know whether the problem is still open. If a suggested fix did not work, state what you tried and what happened. Do not mark something resolved just because someone supplied an answer.
Sources and limits
Reviewed October 28, 2026: GitLab's help-request workflow, GitLab's ticketing style guide, Thoughtbot on clear online questions, No Hello, Don't Ask to Ask, Stack Overflow's reproducible-example guidance, and Slack's thread controls.
The community essays are advice, not research proving a response-time benefit. GitLab's rules describe its own support work, not a universal workplace policy. Our checklist and fictional examples adapt those ideas for everyday work chat. No message format guarantees an answer. The hero is conceptual AI artwork, not an instruction to build or repair a bridge.