There is one customer email I think about more than I would like to admit. They asked for a feature we had absolutely no plans to build. Instead of saying that, I wrote something soft and cowardly: "That's a great suggestion! I'll pass it along, and hopefully we can look into it down the line." I felt kind. I felt diplomatic. I felt like I had dodged an unpleasant moment.
Three weeks later they emailed back asking for a status update on "the feature you said you were building." I had never said that. But that is exactly what they heard, because I had been too scared to give a clear no, and a soft maybe always decodes as a yes in the reader's head. I had to write a second email that was now twice as hard, because I was not just delivering a no — I was also walking back a yes I never technically gave but absolutely implied.
Why vague refusals quietly backfire
When you soften a no into a maybe, you are not being kind. You are deferring the disappointment and making it bigger, while also signing yourself up for a follow-up conversation that is now more awkward than the original would have been. The customer plans around a fantasy. When reality arrives, it arrives as a second, worse no, and now you also look like you misled them.
A clear, respectful no — delivered early, explained honestly — is genuinely the kinder option. It lets the customer make real decisions with real information instead of waiting on something that is never coming. I have come to think of false hope as a debt: it feels free when you take it on, but you pay it back later with interest, in the form of an angrier customer and a harder conversation.
The refusal prompt I now lean on for the hard ones
I run these through the A Clear, Kind 'We Can't Do That' That Keeps the Customer prompt on Gemini 3 Pro Preview. I give it the request, the honest reason, and any genuine alternative. Gemini 3 Pro is excellent at holding a precise, even tone across a delicate message — it gives the no early, explains the reason in plain words, and when there is a real workaround it frames it as actual help rather than a pity prize.
What I appreciate most is the discipline around the alternative. My instinct, when delivering a no, is to soften it by gesturing at some vague workaround I have not actually thought through — which is just a smaller version of the false-hope problem. The prompt refuses to invent an alternative when I leave that field empty. If there genuinely is no workaround, it gives the honest no and keeps the door open warmly, rather than papering over the gap with a fake consolation. A real no with no fake comfort attached is more respectable than a no smuggled inside a maybe.
- The no lands early, not buried under three sentences of hedging
- The 'never say coming soon unless it's true' rule killed my false-roadmap habit
- Customers stopped sending follow-ups about features I never actually promised
- Several customers thanked me for being straight with them, which still surprises me
The rule that exposed a bad habit I didn't know I had
The rule against blaming 'the system' or another team caught me red-handed. I used to deflect ownership of a no by quietly making it someone else's fault — "the product team won't prioritize it," "our policy doesn't allow it." It reads as weak and evasive, and customers can smell it. Owning the no plainly — "we've decided not to build this because it doesn't fit how the product works" — is more respectful and more honest, even though it feels scarier to type.
When a no comes attached to genuine fury, I reach for my De-escalate a Furious Customer Without Over-Promising prompt first to handle the heat, then this one to deliver the boundary cleanly. The de-escalation prompt cools the temperature; the refusal prompt delivers the actual no without reheating it. Used together, a hot 'why won't you build this' ticket ends with the customer disappointed but not angry — which, on the hard ones, is the best honest outcome available.
And there is a quieter benefit I did not anticipate: feature requests I decline now actually reach the product team in a useful shape. Because the prompt only offers to 'pass it to product' when that is genuinely true, the requests I do forward are real signal, not me CYA-ing a customer with a promise to make the conversation end. My product manager noticed the change before I told her about the prompt — the requests coming from me got more specific and more honest, because I had stopped using 'I'll pass it along' as an exit hatch from an uncomfortable moment.
Grab the A Clear, Kind 'We Can't Do That' That Keeps the Customer prompt on Prompt Dock and run it on the request you have been avoiding in your drafts folder. Clarity, it turns out, is a form of kindness — and this prompt keeps me from confusing the two.