A product refuses requests dozens of times a day and almost nobody designs that surface. Capability gets specs, reviews, and launch plans. The boundary gets a fallback string somebody wrote in an afternoon, and that string is what users hit on their first bad day.
The standard is two parts. Name the reason. Name the nearest thing you can do.
A refusal with the first and not the second is a wall. A refusal with the second and not the first is evasive. Both, in that order, every time. The usual objection, that naming the reason exposes something, almost never holds at the level of category, which is all the rule asks for. "I do not have access to your billing records" exposes nothing and tells the user exactly how to route around it.
Four categories, because users forgive a refusal they can classify.
Cannot is capability. Be specific about what is missing. "I do not have access to X" is information. "I am unable to help with that" is a shrug.
Will not is policy. Own the decision. Passive voice here, "that is not supported," sounds like the product is hiding behind a rule it will not name, and people read that as evasion. Somebody decided. Say so.
Not yet is state. Name the condition that changes the answer and turn it into an action. Connect the second source, wait for a few weeks of data, finish the setup step.
Not like this is scope. Offer the smaller version immediately instead of asking whether they want it. "I cannot rewrite all four hundred at once. I can do a batch of twenty and show you the pattern before the rest."
Three shapes carry nearly all the copy.
State, boundary, path is the default. What the product understood, what it will not or cannot do and which category that is, the nearest thing it can do as an action.
Partial delivery is for when most of the request is fine and one part is not. The good part first, then the boundary, then what would let the rest through. Leading with the refusal buries work the user could have used.
Then the hard stop, for irreversible or high-harm requests. Plain statement of what will not happen, then the human path named specifically. No softening.
Words to cut, in order of how often they show up. "Unfortunately," which adds nothing and pairs badly with a boundary you chose on purpose. "I'm just an AI," which undercuts the product on every other surface and is not the real reason for most refusals, since most refusals are policy decisions made by people in a room. "I cannot help with that," which is almost always false, because something adjacent is available and the adjacent thing is the entire value of the response. Any apology longer than four words. And "as mentioned previously," because nobody wants to be corrected by software.
Two maintenance rules keep a refusal set honest. Refusals are versioned like any other spec, so when the product gains a capability the matching refusal comes out the same day. And every refusal goes in the eval, scored on both fields: did it name the reason, did it offer the nearest action. That is one of the easiest evals anybody will write and one of the most useful, because refusal quality degrades silently with every model change and the alternative discovery channel is a customer.
One last thing that gets missed. The same boundary has to sound the same in the chat, the empty state, the error, and the email. When the interface refuses politely and the API returns a bare error code, users conclude the polite version was theatre.
This week: write the actual sentences for the five things your product most often declines, then read them out loud in order. If any sounds like a system failure rather than a decision somebody made, rewrite that one first.
The categories with example copy, the three patterns, and the blank refusal set are in Refusal Copy Patterns. The argument is in Designing Refusal.