Say No to a Work Request Without Leaving the Next Step Unclear
State what you cannot take on, give the relevant constraint, and say what happens next. If a new request conflicts with work already promised, make the tradeoff visible to the person who can decide. A polite message should not accidentally sound like acceptance, and an alternative should not commit someone else's time.
Miles Crawford
Decide which answer you actually mean
Before writing, separate a refusal from a timing problem. “I cannot own this” and “I can do this after the current deadline” lead to different plans. Our table is a writing aid, not a workplace policy.
| Answer | Use it when | Make explicit |
|---|---|---|
| Decline | You cannot take responsibility for the request | That you are not accepting it |
| Defer | A later start or answer is genuinely possible | Whether the date is a commitment or a check-in |
| Reduce scope | You can deliver a useful smaller part | What is included and what is not |
| Reprioritize | The new work may matter more than existing work | What would move and who decides |
IEEE-USA's workplace advice identifies conflicting priorities, overload and lack of expertise as reasons to discuss or decline a request. Asana and Indeed recommend clear, brief wording and relevant workload context. These are practical recommendations, not evidence that one script guarantees a good reaction.
For a coworker, name the limit without a long defense
Acknowledge the request without saying yes to it. Then give the relevant answer. You do not need a list of personal details to explain that you lack capacity. These examples are fictional and should be changed to match your actual commitments.
I cannot take ownership of the event checklist this week. I can send the version we used last time, but I will not be coordinating the new event.
The useful part is the boundary between sharing a resource and owning the work. “I can help” would leave that boundary open. If even the smaller offer is not realistic, leave it out.
I cannot review the whole proposal today. I can check the two pricing paragraphs tomorrow morning. Would that smaller review help?
This offers a defined part, not a hidden promise to fix the rest. If the requester needs the full review sooner, they can look for another route rather than waiting on an unclear maybe.
For a manager, put the priority conflict on the table
New work may be more important than your current plan. The question is what changes, not whether the original plan must always win. Atlassian's capacity article recommends explaining what would be deprioritized and checking whether the requester can make that call, especially when another team bears the cost.
The supplier reconciliation is committed for this afternoon. Preparing the new comparison would use the same review time, so I cannot complete both today. Should I finish the reconciliation first, or move it and prepare the comparison? The finance owner needs to agree if we move their deadline.
Use real constraints and a realistic estimate. Do not invent a full calendar to make a refusal sound stronger. If you do not know how much work the new request involves, ask for the scope before promising a finish time.
A priority question is not permission to silently drop the old commitment. Get the decision, tell the affected people what changed, and update the shared task or schedule. GitLab's decision process uses a named decision owner and documented alternatives; that is its own operating model, but the idea of naming the decision and owner is useful here.
A later date must mean something
“Maybe next week” can sound like a promise while giving nobody a usable plan. Choose one of these two meanings:
- A commitment: you have checked capacity and can accept a defined piece of work at a stated time.
- A review point: you will check capacity then, but have not accepted the work.
I cannot commit to this yet. I will check capacity after the release review and reply by 3pm with a yes or no. Please do not plan on my support until I confirm.
The reply-by time is itself a commitment. Choose one you can keep. If you later discover the answer is no, say so instead of repeatedly moving the check-in. For a deadline that cannot wait, tell the requester promptly that they need a different plan.
Do not offer somebody else's time or approval
Suggesting a person is different from assigning them. “Alex will do it” is not an alternative you can offer unless that handoff is actually agreed. A safer note is “Alex's team owns that process; please check with them about capacity.” Do not invent an introduction, review slot or client concession to soften a no.
For client work, separate the request from the agreed scope and your authority to change it. You may need the account owner to confirm the new deadline or scope. Do not promise extra work, waive a fee or amend a delivery commitment just to make a chat reply sound helpful.
The requested extra layout is outside the current review. I cannot promise it for this delivery. I will ask the project owner to confirm whether we can add it and what that changes before we commit.
Use words for the answer, not just a reaction
A 👀 reaction may mean that you saw a request. It does not say whether you accepted the work, declined it or need a decision. Write the answer when ownership or timing matters. Keep the discussion with the original request where possible, and use a private conversation when the details are sensitive.
If the exchange becomes heated or the tradeoff is too complicated for a thread, use the appropriate call or escalation route, then write down the agreed result. Do not turn a disagreement into a public contest over who is busier.
Confirmed after our call: I will prepare the comparison first. The reconciliation moves to the next agreed review slot, with the finance owner's approval. I have updated both tasks; the links are in this thread.
Only write that recap after those decisions and updates have happened. Our handoff guide covers the information to preserve when responsibility changes.
Where a message template is not enough
Power, role expectations and workplace culture affect how a refusal is received. APM's interview about saying no specifically warns that expectations and backlash are not equal for everyone. That is a reason to consider the context, not to promise that a more polished sentence removes the risk.
For safety concerns, harassment, coercion or a request you believe violates policy, use the appropriate reporting or support route. For an active incident, follow the incident process rather than treating an urgent request as an ordinary capacity negotiation. This guide is communication advice, not legal advice or a guarantee about employment consequences.
Sources and limits
Reviewed October 29, 2026. The table, examples and recap are ours. The sources offer professional advice and an organizational decision-making example, not a controlled test of these messages. We have not measured response rates, acceptance or career outcomes.
- IEEE-USA InSight: Saying No in the Workplace (2024)
- Atlassian: capacity and priority tradeoffs (2021)
- Asana: clear refusals and alternatives
- APM: context, expectations and saying no (2024)
- Indeed: brief professional replies (updated October 2026)
- GitLab: decision owners and documented alternatives
The hero is conceptual AI artwork about limited capacity, not a measurement of how much work a person can handle.