TL;DR:
Write the policy and the allowed exceptions down once, so two people answer the same request the same way.
Decide using dates and facts, say the decision plainly, and record the reason every time.
An exception is a rule you wrote in advance, not a favor decided in the moment.
A customer writes asking for their money back. Your colleague refunded a similar request last week, and you are not sure whether you should. If the answer depends on who picks up the ticket, customers notice, and so do you. Consistency comes from writing the rule down and following the same short routine every time.
When you need a routine
You need it as soon as more than one person answers refund requests, or when you notice yourself deciding case by case from memory. It also protects you: a decision you can point to in a written policy is easier to explain than one that felt right.
Note: This article is about working consistently, not about the law. Refund rights differ by place and by what was sold. Check the rules that apply to your business and ask whoever owns your policy if you are unsure.
What to have in place
A written refund policy, in plain words, that you can link to. It states the window, what is covered and what is not.
A short exceptions list, agreed in advance, with who can approve each one.
A place to log decisions: a spreadsheet works fine. Columns for date, ticket, amount, decision, reason and who decided.
Two or three saved replies for approve, decline and exception, so wording stays consistent.
Step by step
Find the facts: Get the purchase date, the amount, what was bought and the date of the request. Do not decide from memory.
Check the policy window: Count days from purchase to request. Compare with the written window.
If inside the window, approve: Follow the policy, reply, and log it. Do not ask for reasons the policy does not require.
If outside, check the exceptions list: Look for a listed reason that applies, such as a service fault on your side or a first request within a short grace period.
Decide and say it plainly: Write the decision in the first sentence, then the reason, then what happens next.
Log the decision with its reason: This is what keeps the next decision the same.
Escalate only what the policy cannot decide: If a case fits no rule, pass it on to the owner of the policy with the facts. Afterwards, consider whether the policy needs a new line.
Worked example: a refund request outside the policy window
The policy and the people here are invented. Say the written policy gives 30 days from purchase for a full refund, and has one listed exception: a first-time request up to 14 days after the window may be approved by any team member.
A customer bought an annual plan on October 1 for $60 and writes on November 8 asking for a refund because they have not used it. You work out the days. October has 31 days, so October 1 to November 1 is 31 days, and November 1 to November 8 is 7 more. That makes 31 + 7 = 38 days.
A2: 2026-10-01 (purchase date)
B2: 2026-11-08 (request date)
C2: =B2-A2 (days since purchase, returns 38)
D2: =C2-30 (days past the window, returns 8)The request is 38 − 30 = 8 days outside the window. Now check the exception: 8 days is within the 14-day grace period, and your log shows no earlier refund for this customer. The exception applies, so you approve.
Step | Fact | Result |
|---|---|---|
Window | 30 days | Request on day 38 |
Past the window | 38 − 30 | 8 days |
Exception: within 14 days past, first request | 8 ≤ 14, no earlier refund | Applies |
Decision | Refund $60 | Approved by exception, logged |
The reply states the decision first: "I've refunded the $60 for your annual plan. It was a little past our 30-day window, but we allow a first request within two weeks after it, so this qualifies." That tells the customer what happened and why, without implying that the next request will be treated differently.
Suppose the same request had arrived on day 60. 60 − 30 = 30 days past, which is more than 14, so no listed exception applies. You would decline kindly, say what the policy is, and offer anything the policy allows, such as cancelling renewal. The decision follows the rule rather than the mood of the conversation.
Mistakes to avoid
Deciding from memory. Look up the dates and compute the days every time.
Unwritten exceptions. If you make one twice, add it to the list so it is a rule rather than a pattern of favors.
Burying the answer. Customers should find the decision in the first sentence.
Not logging. Without a log you cannot see patterns or check consistency.
Arguing with the customer. State the policy once, kindly, and move to what you can do.
Doing it faster
Keep the three saved replies and the log in one place and the routine takes a couple of minutes. A date-difference formula such as =B2-A2 saves counting on a calendar. When you are checking wording for a tricky decline, DuckyHelper can talk it through with you out loud while you stay in the ticket, though sending is always up to you.
Frequently asked questions
Should I ever bend the policy?
Only through a listed exception or with the policy owner's approval. If you find yourself bending it often, the policy needs revising.
What should the log contain?
Date, ticket, amount, decision, which rule applied and who decided. It lets someone else reproduce your decision.
Get started
