Refund requests are the support interaction where a small mistake costs the most, and where a good process pays for itself immediately. The temptation is to treat each one as a fresh judgment call, but the decisions are more consistent than they feel. Every refund request benefits from the same sequence: verify the payment, check access and delivery, read the support history, then decide and record the outcome. Ziikly turns that sequence into a repeatable process by answering every step from one email search across your payment, store, course and help tools, with read-only keys.
Verify Payment Before Anything Else
The first question is not whether the refund is fair; it is whether a payment exists. Search the customer's email across Stripe, ThriveCart and any other payment tool before forming an opinion on the request. The facts come first, and the judgment follows them, never the other way around.
Confirm the charge actually succeeded. Look for the amount, the date and the status, and note whether the payment came from the same email the customer is using now. A payment under a different address changes the whole conversation, and so does a charge that was never completed.
If no payment exists, the reply writes itself: the refund is not a refund, it is a clarification. If payment exists but was already refunded, that is an answer too. Either way, the lookup turned an awkward moment into a simple, honest reply, and the customer is no worse off for asking.
Check Access And Delivery Status
A refund request is usually also a claim that something failed: access never arrived, the course did not unlock, the order never shipped. Check that claim before deciding, because it changes the outcome. A delivery problem is solved differently from a change of mind, and the two deserve different replies.
If the product was a course, check the enrollment in Teachable, Thinkific or Kajabi. Was access granted, and when? If it was physical or digital delivery, check the Shopify order status. The tool that holds the record depends on what was actually sold, and Ziikly queries them all in one search.
A customer who received full access and used it has a weaker case than one whose access genuinely failed. The delivery record is the evidence either way, and the fix that beats a refund is often visible in it. An enrollment restored in minutes beats a refund that takes days.
Read The Support History First
Before you decide, look at the conversation history. The customer's story in this request usually has a context in the past weeks: a previous complaint, a promised fix, a delay they were already told about. That context rarely appears in the payment record alone, so the history earns its place on the checklist.
Past messages from Missive or a previous ticket show whether this is a first request or the third attempt. The tone and the pattern are information. A loyal customer with one failed incident deserves different handling than a pattern of chargebacks. The history makes that difference visible.
History also protects consistency. If the team already promised something to this customer, the refund decision should respect that promise or explicitly revise it. A decision that contradicts an earlier promise erodes trust in the whole process, and customers remember promises better than they remember policies.
Deciding And Recording The Outcome
With payment, access and history in hand, the decision becomes almost mechanical. Refund if the payment exists and the product failed. Decline or offer an alternative if the product was delivered and used. Offer a partial refund or credit where the story is mixed. Say which part of the evidence tipped the call.
Whatever the decision, say it plainly and quickly. The refund itself should be processed in the payment tool, and the customer should get a short reply that states the outcome and what happens next. A clear answer the same day beats a vague maybe by Thursday.
Record the decision. Whether that is a note in the helpdesk, a ClickUp task or a line in the accounting tool, the record prevents the same request being re-decided differently next month. After a few months of records, the patterns become the basis for a better policy.
Frequently asked questions
Should Refund Rules Be Public?
Yes, within reason. A short public policy stating your refund window and conditions sets expectations and reduces disputes. Internally, keep the decision criteria flexible enough to handle edge cases that a written rule cannot fully capture. Record the exceptions you make so the policy learns from them.
How fast should a refund be processed?
Decide the same day you receive the request. The lookup takes seconds, and a fast, honest decision is appreciated whether the answer is yes or no. Delays turn a fair decision into a frustrating one. So decide before the customer has to ask twice.
Top comments (0)