A customer asking for a refund, waiver, or exception needs a clear response, but a quick acknowledgment is not the same as approval. The safest approach is to separate what the customer has requested from what your organization has decided. Record the relevant facts, identify who can make the decision, and explain what is being reviewed in plain language. This gives the customer a useful next step without suggesting that the answer will be favorable or that a decision will arrive by a date you cannot confirm.
The useful bits
- Record the request and the facts needed to assess it, without labeling it approved.
- Confirm the decision-maker and any required review before describing the request as under consideration.
- Tell the customer what is known, what remains open, and when you can next provide an update only if that timing is confirmed.
Acknowledge the request without deciding it
Start by recognizing what the customer is asking for. A neutral acknowledgment reduces ambiguity: you have received a request for a refund, an exception to a policy, or another remedy. Avoid words such as “approved,” “eligible,” or “we can make that happen” until an authorized decision-maker has confirmed the outcome.
If the request is unclear, ask a focused question rather than guessing. For example, confirm which charge or order the customer means, what exception they are seeking, or whether they want a refund or a different resolution. Do not ask for information your team does not need.
Create a factual record
Capture the customer’s request in their own terms where useful, along with the date received, relevant account or transaction reference, and facts they provided. Separate those facts from your interpretation. “Customer says the service was unavailable on [date]” is different from “service failure confirmed.” Mark anything that still needs checking.
Keep the record in the place your organization uses for customer cases or decisions, and limit sensitive information to what the review requires. If the request arrived by email, keep the message available to the people handling the case, but do not treat an email thread alone as proof that an exception has been authorized.
Find the person with authority
Before describing a request as being reviewed, establish who can decide it. Check the applicable internal policy and escalation route, and confirm whether the decision belongs to a particular role, team, or account owner. A person who can discuss a request may not have authority to approve it.
If authority is unclear, ask internally before making a commitment. Share only the relevant facts, the requested outcome, and any unresolved questions. Do not imply that a manager, finance team, or other group has accepted the request simply because it has been forwarded to them.
Explain the review in bounded language
Tell the customer what you are doing, not what you hope the decision will be. A useful update names the item being checked and identifies any information still needed. Be explicit that no outcome has been confirmed. This is more helpful than a vague “we’ll take care of it,” which can sound like a promise.
Only provide a response date or next-update time if the responsible team has confirmed it and you can meet it. If there is no reliable timing, say that you cannot confirm one yet. You can still explain how the customer will receive an update, provided that channel is known and appropriate.
Subject: Update on your refund request Hello [Customer name], I’ve recorded your request for a refund related to [order or reference]. We’re checking [specific item] and confirming who is authorized to decide it. No refund or exception has been approved at this point. I don’t have a confirmed decision date to share yet. If we need more information, I’ll contact you at [email address]. Regards, [Name or team]
Keep the case moving without overstating progress
Set an internal next action: for example, verify the transaction, request a missing detail, or ask the designated decision-maker to review the case. Record who owns that action and what remains unresolved. This makes it easier to distinguish a request that has been received from one that is actively being assessed.
If an internal target date exists, treat it as a planning aid rather than a customer promise unless your organization has approved communicating it. If that date changes, update the case and give the customer a factual update when appropriate. Silence can create uncertainty, but an invented deadline creates a different problem.
Close the loop with the confirmed decision
Once an authorized person has decided, communicate the outcome directly and accurately. State what was decided, any relevant conditions or next steps, and what the customer should expect from your team. If the request is declined, explain the reason you are permitted to share and any available review route; do not invent an appeal process.
Before sending, check that the message matches the recorded decision and does not add an unapproved concession or timing commitment. A simple final check is: Is the decision confirmed? Is the sender authorized to communicate it? Does the message distinguish confirmed facts from anything still pending?
- Request recorded with the relevant reference and open questions.
- Decision-maker or escalation route confirmed.
- Customer told what is under review, with no unconfirmed outcome or deadline.
- Next action has an owner, and the eventual decision is communicated accurately.
About this guide
Prepared with AI assistance for the BITTU Mail editorial library. Check important details against your original messages and current account settings. Product access depends on your role, plan and provisioning state. Provider interfaces and requirements can change.
View current plans · Security information · Suggest a correction