# Refusal Copy Patterns

> What the product will not do, said in a way that reads as competence rather
> than limitation. Refusal is the most under-designed surface in AI products and
> the one users judge fastest, because a bad refusal is indistinguishable from a
> broken product. Four categories, the two-part rule, and copy you can adapt.

---

## The two-part rule

Every refusal has exactly two jobs:

1. **Name the reason**, in a category the user can understand.
2. **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 parts, every time, in that order.

That is the whole standard. Everything below is how to do it well.

---

## The four categories

Users forgive refusals they can classify. They do not forgive a refusal that
sounds the same as a failure.

### 1. Cannot (capability)

The product does not have the ability or the data.

> "I do not have access to your billing records, so I cannot check that invoice.
> Your account team can pull it in a few minutes, or you can find it under
> Billing, Invoices."

**Get right:** 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.

### 2. Will not (policy)

The product could and has been designed not to.

> "I do not give dosage amounts. I can explain what the label says and flag the
> interactions worth asking a pharmacist about."

**Get right:** own the decision. Passive voice here ("that is not supported")
sounds like the product is hiding behind a rule it will not name, and users read
that as evasion. Someone decided. Say so plainly.

### 3. Not yet (state)

It needs something first.

> "I need at least a few weeks of data before the trend is worth showing.
> Connect the second source and this fills in on its own."

**Get right:** name the condition that changes the answer, and make it an action
if you can.

### 4. Not like this (scope)

The request is possible in a different shape.

> "I cannot rewrite all four hundred at once. I can do a batch of twenty and show
> you the pattern before the rest."

**Get right:** offer the smaller version immediately rather than asking whether
they want it.

---

## The copy patterns

### Pattern: state, boundary, path

The default. Three short sentences.

```
<What the product understood.>
<What it will not or cannot do, and which category.>
<The nearest thing it can do, as an action.>
```

### Pattern: partial delivery

When most of the request is fine and one part is not. Deliver the good part
first, then the boundary. Leading with the refusal buries work the user can use.

```
<The part that was completed, delivered.>
<The part that was not, and why.>
<What would let the rest through.>
```

### Pattern: hard stop

For irreversible or high-harm requests. Short, plain, no hedging, no apology
spiral.

```
<Plain statement of what will not happen.>
<The human path, named specifically.>
```

Do not soften this one. A hard stop delivered apologetically invites negotiation,
and negotiation on this surface is exactly what you do not want.

---

## Words to cut

**"Unfortunately."** Adds nothing, and pairs badly with a boundary you chose on
purpose.

**"I'm just an AI."** Undercuts the product on every other surface. It also is
not the reason for most refusals, which are policy decisions made by people.

**"I cannot help with that."** Almost always false. It can usually help with
something adjacent, and the adjacent thing is the entire value of the response.

**Any apology longer than four words.** One acknowledgment, then the path
forward. Repeated apology reads as a product that knows it is failing you and
plans to continue.

**"As mentioned previously."** Nobody wants to be corrected by software.

---

## The refusal set

The artifact. One row per refusal your product makes, written once, used
everywhere including the eval set.

| Trigger | Category | Copy | Nearest available action |
|---|---|---|---|
|  |  |  |  |
|  |  |  |  |
|  |  |  |  |

Two rules for maintaining it:

**Refusals are versioned like any other spec.** When the product gains a
capability, the matching refusal comes out of the set the same day. Stale
refusals for things the product can now do are worse than no refusal at all.

**Every refusal goes in the eval.** Score both fields: did it name the reason,
did it offer the nearest action. This is one of the easiest evals to write and
one of the most useful, because refusal quality degrades silently with every
model change.

---

## Consistency across channels

The same boundary has to sound the same everywhere: in the chat, in the empty
state, in the error, in the email. When the interface refuses politely and the
API returns a bare error code, users conclude the polite version was theatre.

---

## The one thing to do this week

Write the refusal copy for the five things your product most often declines.
Actual sentences, not descriptions of sentences. Read them out loud in order. If
any of them sounds like a system failure rather than a decision somebody made,
rewrite that one first.

---

_From "Designing Refusal", chapter 10 of The Design Operating Model._
_falkster.com/design/designing-refusal_