Declining a request by email: six scripts to copy

This page is the wording, not the argument. Why a no should be recorded as a decision and what a good one contains when you say it to a stakeholder are separate essays. What follows is six short emails you can copy, edit and send, one for each honest answer a request can get, each with a note on when it is the right one.

Pick the script after you have made the decision, not instead of making it. An email cannot turn an undecided request into a decided one; it can only report the decision clearly. Replace everything in square brackets, and keep the result about as short as it is here: a long refusal reads as a negotiation.

What every script has in common

• The request, restated in one sentence, as the problem rather than the proposed solution. If you cannot write that sentence, send script 3 instead.
• The decision, in plain words. No, not now, not yet, a smaller yes, or wrong team. Never two of them at once.
• One honest reason, tied to capacity or priority rather than to whether the idea is any good.
• What happens next: the condition that would change the answer, the date you will look again, or the person who now has it.

1. The decline

When to use it: you have understood the request and you are not going to do it, at any priority you can foresee.

Subject: [Request name]: decision

Hi [name],

Thanks for sending this. As I understand it, you need [the problem, in one sentence].

We have decided not to take this on. The reason: [one sentence, e.g. "it is worth doing, and it lost to X and Y, which we are already committed to"].

What would change that: [the condition]. If I can't see one, I'd rather say so: please don't plan around this happening.

I've recorded the decision and the reason in [where], so it is there if this comes up again.

[You]

If there is genuinely no condition, the last honest line is the "please don't plan around this" one. A decline that hints at a future it does not mean is a slow maybe with better manners.

2. Not now: parked until a review date

When to use it: the request is a real candidate, but something specific stands in the way: a migration, a contract, a commitment that has to finish first.

Subject: [Request name]: parked until [date]

Hi [name],

Thanks for this. As I understand it, you need [the problem, in one sentence].

We are not starting it now. It is parked, not declined: it is waiting on [the specific thing], and starting before that would mean [the cost].

I will look at it again on [review date] and write to you either way. If [the condition] changes before then, tell me and I'll bring it forward.

Until then, please don't plan around it landing this quarter.

[You]

The review date is the part that makes this a park rather than a hiding place, and "write to you either way" is the part that makes the date mean something. If you honestly cannot name a date, say so: "parked with no review date; if this becomes pressing, bring it back with what changed." That is still an answer. A "maybe next quarter" with no date is not.

3. Not enough to decide yet

When to use it: the request names a subject ("SSO", "reporting", "the mobile app") rather than something that should change, or it says what is wanted but not who it matters to or why now.

Subject: [Request name]: two questions before we decide

Hi [name],

Thanks for raising this. Before I can give you a real answer I need two things, a sentence or two each:

1. What should be different once this is done? Not the feature: what changes, and for whom.

2. Who is affected if nothing changes, and why does it matter now rather than next quarter?

Once I have those I'll come back with a decision by [date].

[You]

Send it the same day the request arrives, while the requester still has the context in their head. Two questions is the limit: a third starts to read as a form. And put the follow-up date in your own calendar, because a question nobody chases is a wait with no end. If you want to see which of the two a request is missing before you write, paste it into the free request check: it shows whether the need, the impact and the why-now are there, and drafts the questions to send back for whatever is not.

4. Yes, but smaller

When to use it: part of the request fits and the rest does not, and the part that fits would still solve something real for the requester.

Subject: [Request name]: what we can take on

Hi [name],

We can do part of this. As I understand it, the core need is [the problem, in one sentence].

What we can take on: [the smaller scope], which the team has sized at [their figure].

What we are not doing: [the named exclusions], because [one reason].

If the smaller version does not actually solve [their problem], please tell me now rather than at the demo. I'd rather change the scope this week than deliver the wrong half.

[You]

The exclusions are the working part of this email. An out-of-scope list is what holds in week six, when the missing half is asked for again as a small favour. And only quote a size the delivering team gave you; a figure you guessed in the reply will be quoted back as a promise.

5. Wrong door: redirect to the right owner

When to use it: the request is reasonable, and another team or person owns the system or decision it touches.

Subject: [Request name]: [owner's name] owns this

Hi [name], [owner's name],

[Name], this sits with [owner's team] rather than mine: they own [the system or decision]. I've copied [owner's name] with what you sent me, so you don't have to explain it twice.

[Owner's name], the short version: [the problem, in one sentence]. Could you confirm to [name] that you have it?

My team isn't taking this on, so please don't count on us for it. If it turns out to need work from us as well, I'm happy to talk about that part.

[You]

Redirect to a person, not to a channel or a queue, and copy the requester, so that the handover is something both sides can see. "Not our team, try the platform channel" is a decline that makes the requester do the routing.

6. When sales has already promised a date

When to use it: a customer has been given a date before engineering has seen the work. This one is not a refusal, because the promise already exists. It is a reply that books the promise as what it is.

Subject: [Customer]: [date] commitment

Hi [sales lead],

Thanks for the heads-up on [customer] and the [date] date. We'll treat it as a commitment: the customer has it, so there's no point pretending otherwise.

It was made before we sized the work, so I'm recording it as an early commitment, with four things on the record: why it was made early ([the deal]); what we don't know yet ([the open questions]); who accepts the risk if the date turns out to be wrong, which I'd suggest is [sales leader], by name; and what would change the date.

The team will size it by [date]. If it doesn't fit, I'll come back with what it displaces or what we'd cut, before the customer hears anything different. Can we agree now who tells the customer if the date moves?

[You]

The "who accepts the risk" line meets the most resistance and does the most work. It turns an argument about blame into a commitment exception with a name on it, which is the only record from which a pre-promised date can later be counted.

The emails not to send

"We'll look into it." "Let's add it to the backlog." "Maybe next quarter." Each of these is polite in the moment and gets received months later as a no that nobody sent. That is the slow maybe, and it costs more goodwill than any of the six scripts above. If you are tempted to send one, it usually means the decision has not been made yet. Make it, then pick the script that matches.

If you use DeliverySheet

The emails stay yours to write and send; the product records the decision each one reports. At the Decide stage a shaped demand gets one of four outcomes: plan it, run a time-boxed discovery, park it, or decline it. Parking and declining both require a written reason, and a park requires either a review date or an explicit choice to park it indefinitely, so the reason line in scripts 1 and 2 already exists before you open your email. Capture holds the bar that script 3 asks for: a request does not enter the lifecycle without a stated need plus either an impact or a trigger.