Declining a customer request should clearly identify what you cannot do and the real next action available. Do not soften the answer with unapproved development promises. Start by understanding the customer’s goal and checking the current capabilities.
Check whether you are declining a feature, exception or date
The customer wants an export in a particular format. The product offers another format, but not the requested one. That is a feature limitation rather than an operator’s permission problem. Check the current capability before refusing; your memory of the earlier version may be outdated.
A request for an unapproved delivery date or process exception differs. Someone may have authority to decide it. Do not present an unknown decision as a settled refusal, but do not promise approval either. Plain language in support helps explain these distinctions without vague formulas. A discount request is a common example of such an exception, so we collected rules and reply templates in our guide on what to do when a customer asks for a discount in chat.
Scroll the table sideways to see all columns.
| Request | What you can say |
|---|---|
| Unavailable export format | That format is not currently offered. |
| A new feature | Recording a suggestion does not commit to implementation. |
| Unconfirmed date | There is no approved date you can promise. |
| Exception requiring a decision | Identify review by the authorised person. |
This guide concerns communication about capabilities and operational decisions. It does not determine rights to refunds, complaints or other remedies. Use the appropriate route for legal assessment or binding decisions. A message template is not a basis for rejecting customer rights. A request to end a subscription is not one to decline; our guide to handling subscription cancellation requests explains how to process and confirm it. How to answer fault reports without sending the customer only to the manufacturer is covered in our guide to warranty vs statutory rights.
Understand the goal before offering a false alternative
Ask what the export needs to accomplish. The customer may want two fields for an internal worksheet or an exact file format required by another system. The available option may meet the first need. For the second, a different extension is not a solution merely because its name looks similar.
- Verify the current capability.Check the actual action or current documentation. Do not refuse a feature simply because you do not know where it appears in the interface.
- Establish the required outcome.Ask about required fields, file recipient and purpose without requesting confidential process history. You need a criterion for judging the alternative.
- Check the difference between options.Compare available and required formats. Name a missing field or import restriction rather than describing them as broadly similar.
- Establish the decision boundary.Separate what you can offer now from development suggestions or decisions belonging to another person. Do not combine those routes into one commitment.
If the alternative does not meet the goal, say so. “Use the current file for a manual worksheet” can be honest but does not mean automatic import. Explain the extra work and limitation. Support response templates cover the general wording; the comparison still needs facts from this particular request.
Put the refusal and available action in the same message
Unavailable format: “I understand you need this file format for import. We do not currently offer it and have no approved addition date. The available export includes fields A and B but does not support that import. If a manual worksheet is sufficient, we can show the current approach. If the exact format is essential, this option does not meet your need.”
Unknown date: “I cannot confirm that date because implementation has not been scheduled. I can forward the need and check for an approved development statement. Forwarding it does not reserve a delivery date. If timing is a condition of your choice, account for the lack of confirmation in your decision.”
Exception under review: “This action requires a decision by an authorised person. I will prepare the request and its scope, then share the decision. The exception is not yet approved. Until confirmation, the current process applies.” Use this only when that review stage actually exists in your company. One example is a request to refund a price difference that falls outside the shop's policy; our guide to price adjustments after a sale collects replies for it.
Avoid “we will try to do something” if you cannot identify the action. It may sound like a commitment to add the feature. A short limitation with a concrete possible check is better. “At the moment” should also not imply an imminent change that nobody has approved.
Distinguish recording a suggestion from committing to delivery
You can preserve the customer’s need as a suggestion. Record the goal and gap, not merely a feature name. Do not label it commissioned implementation. “We forwarded your suggestion” and “we scheduled development” are different facts the customer should not have to infer from polite wording.
If someone confirms a decision, check its scope before replying. Approval to investigate is not approval to implement; a prototype does not confirm availability. Share only the approved statement and identify remaining limitations. An approximate internal plan should not become a binding customer commitment through careless wording.
The customer may reject the refusal. Do not invent another promise just to end the tension. Repeat the boundary, verified alternative and any appropriate decision route. Team organisation is covered in customer support in a small business; a small team still needs clear decision authority.
When suggesting another method or tool, do not invent its capabilities. You can identify a criterion to look for instead of guaranteeing a particular integration.
An honest refusal gives the customer a decision basis even when your product will not be the appropriate choice. The alternative needs to serve their goal, not merely retain the conversation.
Keep the limitation and agreed alternative in the record
In Meetlead customer support, conversation and ticket history preserve the boundary communicated to the customer. Team work requires an account, website and appropriate permissions. The record neither changes product capability nor creates a development decision; it helps another operator reply consistently.
Record whether the customer accepted an alternative or still needs the unavailable outcome. Silence is not acceptance.
If a feature or decision later changes, name that change in the new reply rather than conceal the earlier limitation. Before contacting them, check that the new scope matches the recorded goal, not merely a similar catalogue name.
- The current capability or decision scope was checked.
- The customer’s goal enables judging the alternative.
- The limitation is stated without a hidden commitment.
- Differences between an option and a complete substitute are clear.
- Recording a suggestion is separate from development scheduling.
- The next operator knows the reply and conversation outcome.
If the available action requires customer material, define exactly what is needed. The next guide covers customer support attachments so that requests avoid unnecessary information collection.
What to explain after declining the request
Must every refusal include an apology? No. For an unavailable feature, a clear acknowledgment and boundary can be sufficient.
If the company previously gave incorrect information, apologise for that information rather than for the customer’s question. Do not add an apology simply as decoration.
Is asking about the goal avoiding the answer? Not when you immediately explain that the requested feature does not exist. The goal helps assess an alternative, not delay refusal. Stop requesting more process detail once you know no available option will meet the need.
Can I promise a future notification? Only with an actual process you can follow through. A saved suggestion does not ensure contact after implementation.
If there is no such route, do not add it as a polite template commitment. Identify what you can actually do now.
Zendesk examples include limitations and possible alternatives. This article’s original messages do not establish rules for rejecting legal remedies: guidance on difficult customer replies.
