KoltrixSaying no to a customer by email without losing them
How to turn down a feature request, an out-of-policy refund or a custom contract term by email, with worked examples and the mistakes that make a no sting.
On this page(7 sections)
- The structure: no, why, instead, door
- Example 1: A feature you won't build
- The weak version
- The better version
- Example 2: A refund outside your policy
- The weak version
- The better version
- When to bend instead
- Example 3: A custom contract term
- The weak version
- The better version
- Mistakes that make a no worse
- A checklist before you send
- Key takeaways
Customers rarely leave because you said no. They leave because the no was vague, came three emails too late, or felt like a door slammed rather than a decision explained.
Saying no well is a writing skill, and like most writing skills it gets easier with a structure. This post gives you one, then works through three common situations with a weak draft, a better draft, and notes on what changed.
The structure: no, why, instead, door
A good no has four parts, in this order:
- The no, early. In the first or second sentence. Not in paragraph four.
- The why, briefly. One or two honest sentences. Not a policy manual.
- The instead. What you can do, even if it's small.
- The door. How the conversation can continue, or what would change the answer.
The order matters. If the no comes last, the reader spends the whole email hoping for a yes, and the disappointment lands harder. If the no comes first, everything after it reads as help.
Example 1: A feature you won't build
A customer asks for a deep integration with a niche tool that only a handful of your users have ever mentioned.
The weak version
Hi Morgan, thanks so much for reaching out and for the detailed suggestion! We really love hearing from customers like you. Our product team is always looking at ways to improve, and we'll definitely pass this along. We have a lot on our roadmap right now, but we're always evaluating new integrations, so stay tuned!
What's wrong: there's no actual answer. "Stay tuned" implies it might happen. Morgan will either wait for something that won't come or email again in three months, more frustrated.
The better version
Hi Morgan,
Thanks for spelling out how you'd use this. I want to be straight with you: we're not planning to build a native integration with that tool. It's a small part of what our customers use, and we're putting our integration work into the webhook and API side so people can connect tools like it themselves.
If it helps, a couple of customers have connected it through our webhooks with a small script. I'm happy to share the event format and walk you through it.
If a lot more customers start asking, we'll revisit, and I've logged your request with your use case so it counts.
What changed: the no is in the second sentence, the reason is real, there's a concrete alternative, and the door is honest rather than vague.
Example 2: A refund outside your policy
A customer on an annual plan asks for a full refund eight months in, saying they haven't used the product much.
The weak version
Unfortunately, per our Terms of Service section 7.2, annual subscriptions are non-refundable after 30 days. We are unable to process your request.
What's wrong: technically accurate and completely cold. Quoting the terms section number reads as "we're hiding behind the lawyers." No alternative, no acknowledgment of the person.
The better version
Hi Alex,
I looked into this, and I can't offer a refund for the remaining months. Annual plans are priced lower than monthly precisely because they're a commitment, and refunding partway through isn't something we do.
What I can do: switch off auto-renewal now so you won't be charged again, and if your team's usage picks up before renewal, I'd be glad to help you get more out of it. If there's something specific that made it less useful than you expected, I'd genuinely like to hear it.
What changed: same decision, very different feeling. The reason explains the logic instead of citing a clause. There's a real action. And the last line invites feedback that might actually help your product.
When to bend instead
Not every out-of-policy request deserves a no. Before writing one, check:
- Did something on your side contribute (an outage, a confusing billing page, a missed cancellation)?
- Is the amount trivial compared to the goodwill at stake?
- Is this a long-time customer with a genuine change in circumstances?
If yes to any of these, consider an exception, and say clearly that it's an exception so it doesn't become an expectation.
Example 3: A custom contract term
A mid-sized customer asks to add unlimited liability and a custom SLA with financial penalties to your standard agreement.
The weak version
We'll need to check with legal and get back to you.
Then nothing for two weeks.
What's wrong: it delays the no instead of delivering it, and the silence does more damage than the answer would have.
The better version
Hi Priya,
Thanks for sending over your redlines. I'll be direct about the two biggest ones: we can't accept unlimited liability or financially-backed SLA penalties. As a small company, those terms would expose us to risk far beyond what the contract is worth, and we hold every customer to the same standard terms here.
Several of your other changes look workable, and I've marked those up. On uptime, I can share our status history and our incident communication process, which is usually what teams want the SLA to guarantee in practice.
If it would help, I'm happy to get on a short call with you and your legal contact this week.
What changed: a fast, clear answer on the deal-breakers, real movement on what's negotiable, and an offer that addresses the underlying worry.
Mistakes that make a no worse
| Mistake | Why it hurts | Fix |
|---|---|---|
| Burying the no | Builds false hope, then disappoints | First or second sentence |
| Over-apologizing | Sounds like you're unsure of the decision | One "sorry" at most, or none |
| Vague futures ("maybe someday") | Creates expectations you'll break | Say what would change the answer |
| Hiding behind policy | Feels impersonal | Explain the reasoning in plain words |
| Slow replies | Silence reads as disrespect | A quick no beats a slow maybe |
| No alternative | Feels like a dead end | Offer something, even small |
A checklist before you send
- Is the no in the first two sentences?
- Is the reason honest and understandable without context?
- Is there at least one concrete thing you can do?
- Have you avoided implying a future yes you don't intend?
- Would you be fine with this email being forwarded to the customer's boss?
Key takeaways
- Lead with the no, then explain, then offer an alternative, then leave an honest door open.
- Explain decisions in plain language rather than citing policy clauses.
- A fast, clear no is kinder than a slow, vague maybe.
- Check whether an exception is warranted before refusing, and label exceptions as exceptions.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
