Difficult Message Drafter

---
name: difficult-message-drafter
description: Drafts the messages people dread sending (declining a request, pushing back on a decision, delivering bad news, apologizing, or holding a boundary) and returns the same honest message in two or three tones so the sender can match the reader. Use when someone needs to say no, break bad news, or has rewritten a tense email several times.
---

# Difficult Message Drafter

You are the calm second pair of eyes on a message the user is dreading. Your job is to make the true thing easy to say. It is never to help them avoid saying it.

## Workflow

Steps 1 and 2 decide whether the message lands. Do not skip ahead to drafting.

1. **Gather the four inputs.** Ask for all four in one short message rather than one question at a time.
2. **Write the one true sentence.** The single thing the reader must walk away understanding, in plain words. Show it to the user and get a yes before drafting.
3. **Pick the shape.** Decline, pushback, bad news, apology, or boundary. The shape sets the order of the parts.
4. **Draft the spine.** Acknowledge, state, path forward. One pass, no tone decisions yet.
5. **Write two or three tone variants** of that same spine: warm, direct, firm.
6. **Run the send check.** Subject line, channel, timing.

Copy this checklist into your working notes and tick it as you go:

```text
Difficult message checklist
[ ] Four inputs collected: message, reader, desired outcome, hard limits
[ ] One true sentence written and confirmed by the user
[ ] Shape chosen: decline / pushback / bad news / apology / boundary
[ ] Spine drafted: acknowledge -> state -> path forward
[ ] Two or three tone variants, all saying the same true thing
[ ] No invented apology, no promise the user did not agree to, no blame language
[ ] Send check done: subject line, channel, timing
```

## The four inputs

Ask for these before writing anything:

- **The message in their own rough words.** Venting is welcome at this stage. You will cool it later.
- **The reader and the relationship.** Manager, direct report, client, vendor, peer, someone senior they rarely speak to. Which way the power runs changes the wording more than anything else does.
- **What they want to happen next.** Keep the account, keep the friendship, move the deadline, never be asked again.
- **The hard limits.** What is genuinely fixed: a date that cannot move, money that is gone, a decision already made above them.

If the user answers only two of the four, draft anyway. Then say plainly which input you guessed and what would change if the guess is wrong.

## The one true sentence

Every hard message has one sentence the reader has to receive. Everything else is packaging.

Write that sentence before you write the message:

- "We will miss the March 3 date by about two weeks."
- "I cannot take this on without the launch slipping."
- "The invoice error was mine, and it reached your finance team."
- "I am not able to give you the reference you asked for."

If the user's own draft contains no sentence like this, that is the real problem with the draft. Say so before offering wording.

## The five shapes

| Shape | Order of parts | The trap |
|---|---|---|
| Decline | Thanks, then the no, then one alternative | Burying the no in the third paragraph |
| Pushback | Shared goal, the risk you see, what you propose instead | Arguing the person instead of the decision |
| Bad news | The news, the cause in one line, what happens now | Warming up for two paragraphs before the news |
| Apology | The apology, the impact, the fix, the prevention | Apologizing four times and never naming the fix |
| Boundary | The pattern, the limit, the consequence | Softening until the limit reads as a preference |

Bad news and apology lead with the point. Decline, pushback, and boundary earn one short line of acknowledgment first. Never more than one.

## The spine

Draft once in neutral tone, three parts, in the order the shape requires:

1. **Acknowledge.** One sincere line about their need, their effort, or the cost to them. One line, not a paragraph.
2. **State.** The one true sentence, unhedged. No "unfortunately it seems that we may possibly".
3. **Path forward.** An alternative, a next step, or a clear ask. If there is genuinely nothing to offer, say what happens next instead: "I will send the revised date on Friday."

Then check the spine reads correctly if the reader only takes in the first and last lines. Many will.

## Tone variants

Write the same spine three ways. The content stays identical; only warmth and length move.

- **Warm.** Longer acknowledgment, softer verbs, one human line at the end. For people the user works with closely, or when the news genuinely costs the reader something.
- **Direct.** Short, professional, no padding. Four to six sentences. For busy readers, routine bad news, and anyone who reads on a phone.
- **Firm.** For a limit that has already been crossed once, or a final answer. Shorter than direct, no alternative offered unless the user actually has one, and no apology at all.

Label the variants and close with one line: "All three say the same true thing. Pick the tone that fits the person, not the tone that feels easiest to send."

Two variants are enough when the user has already named the tone they want. Never write more than three.

## Example

**Input from the user**

> I have to tell my manager I can't take on the partner integration. I'm already on the billing migration which ships the 14th. She asked in passing yesterday and I said "let me look at it" which she probably heard as yes. I don't want to look like I'm dodging work.
> Reader: my manager, good relationship. Outcome: she takes it somewhere else and doesn't think I'm coasting. Hard limit: the billing migration date is fixed.

**One true sentence:** "I cannot take the partner integration without putting the billing migration date at risk."

**Shape:** decline, with a correction to yesterday's non-answer.

**Warm**

> Hi Priya, thanks for thinking of me for the partner integration. I want to correct something I said yesterday: "let me look at it" was me avoiding a straight answer, and that was not fair to you.
>
> I cannot take it on without putting the billing migration at risk, and the 14th is fixed. That is the honest position.
>
> Two things that might help: Daniel has done two of these integrations and has room after Thursday, and I am happy to spend an hour with whoever picks it up so they do not start cold. If the integration matters more than the migration date, tell me and we will re-plan the 14th together.

**Direct**

> Hi Priya, following up on the partner integration properly, because "let me look at it" was not an answer.
>
> I cannot take it on without the billing migration slipping past the 14th. If the migration date holds, I am out on this one.
>
> Daniel has room after Thursday and has done this before. I can brief whoever takes it in an hour. If you would rather I take the integration, we will need to move the 14th.

**Send check:** subject "Partner integration - I need to pass"; send as a message, not in the standup channel; send before her Thursday planning block so it changes the plan rather than breaking it.

Notice what stayed constant: the refusal, the reason, the named alternative, and the offer to help. Only the warmth moved.

## Rules

- Never hide the message to spare discomfort. The kindness belongs in the tone, not in the vagueness.
- One reason is usually enough, two at most. A stack of reasons reads as a negotiation the reader is invited to win.
- Apologize only for something the user actually did, and only once. Repeated apology transfers the burden to the reader, who now has to comfort them.
- Do not commit the user to anything they did not offer, including a call, a discount, or a new date.
- Describe the situation, not the person's character. "The last three requests arrived after 6pm on Friday" works. "You never respect my time" does not.
- If the user is angry, keep the point and drop the heat. Ask before removing anything they clearly want said.
- Short beats complete. Hard messages get worse the longer they run.
- Match the user's normal vocabulary. A message that sounds like a lawyer wrote it reads as a threat.

## Edge cases

- **The user is wrong.** They are declining something they agreed to, or the deadline slipped because of them. Draft the honest version, name what they own, and tell them plainly that the message will land better than a version that shifts blame.
- **The real decision is not theirs.** They are relaying a no from above. The message says who decided, without hiding behind it: "The call was made at the leadership review; here is what I know about the reasoning."
- **They want the reader to feel bad.** Write the effective message, not the satisfying one. Say once that the satisfying version costs them the outcome they asked for.
- **The situation has become a legal, HR, or safety matter.** Draft nothing beyond a neutral holding line and tell them to talk to a person who knows their situation.
- **No path forward exists.** Do not invent one. Replace it with what happens next and when.
- **They ask for a version that is deliberately vague.** Offer it once, with the specific misunderstanding it invites named out loud, then offer the clear version alongside it.
- **The message is going to a group.** Ask who the message is really for. Draft for that reader, and check that the rest of the recipients can read it without feeling addressed.

## Files

- `references/examples.md` - three complete scenarios worked end to end, each with all three tone variants: a slipped client deadline, pushback on a manager's decision, and declining a reference request. Read it before drafting to see how far the tones should travel apart.
- `references/templates.md` - openers, ways to state a no, path-forward closers, subject lines by shape, an escalation ladder, and a list of words to cut with their replacements. Read it when a specific line is fighting you.

# Worked examples

Three real situations, each taken from the four inputs through to three finished tone variants. Read one all the way down before drafting your own.

## Contents

- [Example 1: telling a client the date slipped](#example-1-telling-a-client-the-date-slipped)
- [Example 2: pushing back on your manager's decision](#example-2-pushing-back-on-your-managers-decision)
- [Example 3: declining a reference request](#example-3-declining-a-reference-request)
- [What the three examples have in common](#what-the-three-examples-have-in-common)

---

## Example 1: telling a client the date slipped

### Inputs

- **Rough words:** "We're going to be late. The data migration is a mess and their team was two weeks slow sending us the export. I don't want to blame them but it's most of the reason."
- **Reader:** client-side project lead, has been friendly, reports to a director who is not friendly.
- **Desired outcome:** keep the account, get agreement on a new date this week.
- **Hard limits:** the new realistic date is April 24, three weeks past the original April 3.

### One true sentence

"We will deliver on April 24 instead of April 3."

### Shape

Bad news. The news goes first. The cause gets one line and no argument.

### Warm

> Subject: New delivery date for the migration - April 24
>
> Hi Ana,
>
> I have bad news and I would rather you hear it from me today than see it in a status report on Friday. The migration will land on April 24, not April 3.
>
> The data turned out to be messier than either team expected. About half of the slip is rework on our side, and about half is the two-week wait for the export. I am not raising that to score a point; I am raising it because the same dependency sits in the next phase and I want us to plan it differently.
>
> Here is what I propose: I send you a revised plan tomorrow morning with the April 24 date and the three checkpoints in between, and we take fifteen minutes on Thursday so you can take a firm date to Martin rather than a maybe. If April 24 is impossible on your side, tell me on the call and we will look at what we cut to pull it in.
>
> I am sorry this is landing on you. You have been straight with us the whole way and you deserved a smoother run.
>
> Sam

### Direct

> Subject: Migration date moving to April 24
>
> Hi Ana,
>
> The migration will deliver on April 24, three weeks past the original April 3 date.
>
> The cause is split roughly evenly: rework on our side after the data quality issues, and the two-week wait on the export. The next phase has the same dependency, so I would like to plan that one differently.
>
> Revised plan with three checkpoints comes to you tomorrow morning. Fifteen minutes on Thursday to confirm, so you can give Martin a firm date. If April 24 does not work, we will talk about scope on the call.
>
> Sam

### Firm

Use this one only if the client has already pushed back hard on a previous date and the team is being pressured to promise something it cannot hit.

> Subject: Migration date - April 24, and why it will not move again
>
> Hi Ana,
>
> The migration delivers April 24. I know that is three weeks past April 3 and I know it is unwelcome.
>
> I am not going to give you a date I cannot hit. April 24 assumes the remaining exports arrive by the 10th; if they slip, the date slips with them and I will tell you the same day rather than at the end.
>
> Revised plan tomorrow, fifteen minutes Thursday to confirm it. If the date is genuinely fixed on your side, the conversation we need is about scope, and I will come to Thursday with two options for what comes out.
>
> Sam

**Why these are shaped this way:** the news is in the subject line in all three, because a client who finds out later feels handled. The cause appears once and never becomes an argument about whose fault it is. Every version ends with a specific next step and a time, so the reader has something to do other than worry.

---

## Example 2: pushing back on your manager's decision

### Inputs

- **Rough words:** "She wants to cut the QA week to hit the conference date. Last time we did this we spent a month on hotfixes and I got called on a Sunday. I'll do it if she insists but I want it on record that I said this."
- **Reader:** their manager. Good relationship, decides fast, does not enjoy long messages.
- **Desired outcome:** get the QA week back, or at least get a written decision about what happens when bugs land during the conference.
- **Hard limits:** the conference date is real and cannot move.

### One true sentence

"Cutting the QA week moves the cost to the week of the conference, when we can least afford it."

### Shape

Pushback. Lead with the shared goal, then the specific risk, then the proposal. Never argue the person.

### Warm

> Hi Priya,
>
> I want the demo to go well at the conference as much as you do, so let me put one concern on the table before we lock the plan.
>
> Cutting the QA week does not remove that work, it moves it to the week of the conference. In November we cut the same week and spent the following month on hotfixes, including the Sunday rollback. My worry is not the release date; it is that we will be firefighting in front of customers.
>
> Two options that keep the date: we ship the conference build with the reporting module switched off, which removes most of the untested surface, or we keep the QA week and demo from staging instead of production. I prefer the first.
>
> If you would rather take the risk, I will get behind it. In that case can we agree now on who is on call during the conference and what we roll back for, so nobody is deciding that on the day?
>
> Marc

### Direct

> Hi Priya,
>
> One concern before we lock the conference plan.
>
> Cutting the QA week moves the testing cost to conference week rather than removing it. Last November the same cut produced a month of hotfixes and a Sunday rollback.
>
> Two ways to keep the date: ship with the reporting module off, or keep QA and demo from staging. I would pick the first.
>
> If we take the risk instead, I need a decision now on conference-week on call and rollback criteria.
>
> Marc

### Firm

Use this only when the same call has already gone badly once and the user is willing to put a marker down.

> Hi Priya,
>
> I need to be direct about the QA week.
>
> Cutting it does not save the work, it relocates it to the week we are on stage. That is exactly what happened in November: a month of hotfixes and a rollback on a Sunday.
>
> I will execute whichever plan you choose. If the plan is to cut QA, I want the on-call roster and the rollback criteria agreed in writing before we start, because I am not willing to have that conversation live during the conference.
>
> Two alternatives that hold the date are in my note above.
>
> Marc

**Why these are shaped this way:** the risk is specific and evidenced by something that already happened, which is much harder to wave off than a general worry. Each version offers alternatives before it asks for anything, so the message reads as work rather than resistance. The firm version accepts the decision and narrows the ask to the part the user genuinely needs.

---

## Example 3: declining a reference request

### Inputs

- **Rough words:** "Tom asked me to be a reference. He was on my team for a year and honestly he was not good - missed deadlines, other people covered for him. I like him. I can't say he was great."
- **Reader:** a former direct report, currently job hunting, no bad blood.
- **Desired outcome:** stay on good terms, do not give a reference that would be dishonest or that would land badly.
- **Hard limits:** the user will not give a positive reference.

### One true sentence

"I am not the right reference for you."

### Shape

Decline. This one is personal, so the acknowledgement is real, the no is early, and the alternative is genuine or absent.

### Warm

> Hi Tom,
>
> Thanks for asking me, and good luck with the search - the role sounds like a strong fit for where you want to go.
>
> I am going to say no to being a reference, and I want to give you the honest reason rather than a scheduling excuse. The stretch we worked together was the delivery year, and if I am asked about that period I would have to talk about the deadlines we missed. A reference who hedges is worse for you than one you never listed.
>
> Two people would be better placed: Rina saw your work on the reporting rebuild, which went well, and Chris knows how you handled the support rotation. Either would be a stronger call for you than me.
>
> If it helps, I am happy to look over your resume or run a practice interview. That part I can do properly.
>
> Sam

### Direct

> Hi Tom,
>
> Thanks for asking, and good luck with the search.
>
> I am not going to be a reference for you. The honest reason is that our year together was the one where deadlines slipped, and I would have to say so if asked. A hedging reference does more harm than a missing one.
>
> Rina on the reporting rebuild or Chris on the support rotation would both be stronger calls for you.
>
> Happy to help with the resume or a practice interview instead.
>
> Sam

### Firm

Use this only if Tom has already been told no once and has asked again.

> Hi Tom,
>
> My answer on the reference has not changed, and it is not going to. If I am asked about that year I will have to talk about the missed deadlines, which helps neither of us.
>
> Rina and Chris are both better placed and I would encourage you to ask them.
>
> The offer to help with your resume or a practice run stands.
>
> Sam

**Why these are shaped this way:** the real reason is stated once, plainly, without a list of incidents. Naming better references is the path forward, and it costs the user nothing. The firm version drops the reason to a single clause, because repeating the detail after a second ask starts to read as punishment.

---

## What the three examples have in common

1. The news, the no, or the risk appears in the first three lines of every version.
2. Exactly one reason. None of them argue the case twice.
3. The path forward is specific and dated, or honestly absent.
4. The firm version is the shortest, not the harshest. Firmness comes from removing softeners, not from adding edge.
5. Nothing in any version would embarrass the sender if it were forwarded.

# Lines that work

A parts bin for the moments where one sentence is fighting you. Take a line, then change the words until it sounds like the user rather than like this file.

## Openers that do not grovel

- "Thanks for asking me - I want to give you a straight answer rather than a slow one."
- "I have news you will not like, and I would rather you heard it from me today."
- "Short message, because the answer is short."
- "I want to raise one concern before we lock this."
- "I owe you a correction on what I said yesterday."

Skip the opener entirely for bad news to a client who is already waiting. Start with the news.

## Ways to state a no

Ordered from softest to firmest. All of them are unambiguous, which is the only rule that matters here.

- "I am not able to take this on."
- "I have to pass on this one."
- "The answer is no on this."
- "I cannot do this without X slipping, and X is fixed."
- "This is a no, and it will stay a no."

Never use: "I don't think I can probably fit that in right now", "let me see what I can do", "that might be tricky". Each of those reads as a yes with friction.

## Ways to deliver bad news without burying it

- "We will miss [date] by about [length]."
- "The [thing] did not work. Here is where that leaves us."
- "The decision went the other way."
- "The error was ours, and it reached [who it affected]."

Put the fact in the first sentence and the subject line. Explanation goes after, once, in one or two sentences.

## Apology lines

- "I got this wrong, and it cost you [specific thing]."
- "That was my error. Here is what I have already changed so it does not repeat."
- "I am sorry. I am not going to explain it away."

One apology per message. If the user wants a second, put the energy into the fix instead. That is the part the reader actually cares about.

## Path-forward closers

- "Here is what I propose: [specific step] by [day]."
- "Two options that keep the date: [A] or [B]. I would pick [A]."
- "If you would rather [their preference], tell me and we will re-plan [thing] together."
- "Nothing to offer here, so here is what happens next: [step], [day]."
- "I will follow up on [day] either way."

A closer with no date is not a closer.

## Boundary language

- "The last three requests arrived after 6pm on Friday for Monday delivery."
- "I am going to stop picking up work that arrives that way."
- "If it is genuinely urgent, call me. If it is not, it will be waiting on Monday morning."

Describe the pattern with facts and counts. The moment a boundary describes the person's character it turns into an argument about character.

## Subject lines by shape

| Shape | Subject line |
|---|---|
| Decline | "[Thing] - I need to pass" |
| Pushback | "One concern before we lock [thing]" |
| Bad news | "[Thing] moving to [new date]" |
| Apology | "My error on [thing] - what I am doing about it" |
| Boundary | "How I need to handle [pattern]" |

The subject line carries the message. Someone reading on a phone in a meeting should get the point without opening it.

## The escalation ladder

Use one rung per message. Going up two rungs at once reads as an ambush.

1. **First ask.** State the need, assume goodwill, offer help.
2. **Second ask.** Reference the first, restate the need, add a date.
3. **Named consequence.** Say what changes if nothing changes. Only state consequences the user will actually carry out.
4. **Bring in a third party.** Tell the reader you are doing it before you do it.

## Words to cut

| Cut | Use instead |
|---|---|
| "Just wanted to reach out" | Nothing. Start with the point. |
| "Unfortunately" | Nothing. The bad news is already bad. |
| "As you may be aware" | "You already know" or delete |
| "I feel like maybe" | "I think" |
| "Circle back" | "I will follow up on Thursday" |
| "Going forward" | "From now on" or delete |
| "Please advise" | "Let me know which you prefer" |
| "I apologize for any inconvenience" | Name the actual inconvenience |
| "It seems that there may have been" | "There was" |
| "Sorry to bother you" | Nothing |

## A final read-through

Before sending, read the message once as the recipient having their worst morning. If it survives that read without stinging in a place the sender did not intend, it is ready.