How often do refund requests exceed a support assistant's written authority?

Question and scope

This review asks how often refund and discount requests exceed a support assistant's written authority. The unit is a customer request that asks for money back, a price change, or a waived fee. The scope covers requests handled through email, chat, and the task board. The review measures the written limit, not whether the customer deserved the outcome.

A request can exceed authority in amount, in type, or in evidence. An assistant may be allowed to approve a small refund but not a discount, or a refund with a receipt but not one without a record. The review codes each dimension separately so the result shows which limit failed. A single count would hide the difference between a missing rule and a missing document.

The review also separates a request that was escalated from one that should have been escalated. An assistant may escalate a routine case out of caution, while another may approve an exception without realizing a limit exists. Both patterns matter, but they lead to different fixes. The report should show both the overreach and the unnecessary escalation.

The review should state whether it covers one client or several. A shared authority table may not fit every client's policy, especially when the client sells through more than one channel. Record the client and the channel for every request. A pooled rate across clients can hide a rule that works for one and fails for another.

Definitions and unit

Written authority means the limit stated in a current document that the assistant can access during the task. A verbal permission from a manager is not written authority unless it is recorded in the same system. A limit that exists only in a training slide is not usable during a live chat. The review records the document, the version, and the date.

A refund is a return of money already paid, while a discount is a reduction applied before or after payment. A credit may be either, depending on how the client records it. The review codes the financial action rather than the label the customer uses. Two requests with the same label can follow different approval paths.

The unit is one request and one decision. A request that receives a partial refund and a separate discount is two decisions, not one. Record the amount, the currency, the evidence attached, and the person who approved the final action. The unit keeps the count from doubling when a request is split across messages.

Evidence collection

Select requests from at least two weeks and several agents, including one busy period. Use the ticket export, the payment record, and the authority document together. Where the records disagree, keep both and mark the case as disputed. The sample should be small enough to read each request in full.

Record the request date, the amount, the customer's stated reason, and the evidence the assistant had at the time. Do not judge the case with information that arrived after the decision. The review is about the authority available then, not the wisdom of the outcome now. A later document can explain a gap but cannot change the coding.

Ask the assistant which limit caused the most hesitation during the sample period. Their answer may reveal a rule that is technically clear but difficult to apply. Add the example to the evidence set and read the actual message. A rule that nobody can apply during a live chat is a rule that needs rewriting.

Patterns to measure

Measure the share of requests that exceeded the written amount, the written type, or the evidence requirement. Keep the three counts separate and show the overlap. A request can exceed more than one limit, and the overlap often points to the simplest fix. The distribution is more useful than a single total.

Measure the time between the request and the approval for cases that were escalated. A limit that is clear but slow to approve creates a different problem from a limit that is missing. Compare the delay with the customer's expectation and the published response window. A fast decision path can be as important as a generous limit.

Measure the share of decisions that were reversed later by a manager or a finance review. A reversed decision is evidence that the authority table and the actual policy disagree. Read a sample of reversals and code the cause. Reversals are expensive because they combine a customer conversation with a financial correction.

Comparing authority models

Compare a small fixed limit with a tiered limit that depends on the request type or the customer's history. Hold the product and the customer segment as constant as the data allow. Count both the overreach and the escalation rate. A model that stops overreach by escalating everything has moved the cost rather than removed it.

A tiered model can fit a business with several products, but it needs a clear table and a named owner for each tier. A fixed limit is easier to remember but may be too small for routine cases. The review should state which model the evidence supports for the actual request mix. The goal is a decision the assistant can make at the moment of contact.

Record the approval path for an exception, including the person, the channel, and the expected response time. A model without a named exception owner will fail on the first unusual case. The comparison should include the cost of waiting as well as the cost of the refund. A generous limit that takes two days to approve may still lose the customer.

Limits and confounders

A retrospective sample cannot show what would have happened if the assistant had a different limit. It can show whether the recorded decision matched the written rule. A policy change during the sample can make an old decision look wrong. Record the version and the date of the authority document for every case.

The sample may miss requests that were resolved in a chat and never entered the ticket system. Those cases may be legitimate, but they are outside the evidence. State the boundary and the number of unrecorded cases if the team can estimate them. Do not treat a missing record as proof of a good or bad decision.

Finance and support may define the same refund differently. A finance credit and a support refund can appear in different reports with different amounts. Reconcile the definitions before comparing counts across teams. A comparison built on two definitions will produce a precise but misleading result.

Reporting the finding

Report the overreach rate, the escalation rate, the reversal rate, and the main cause for each. Show two anonymized examples that illustrate the most common pattern. Recommend one change, such as a clearer amount table or a required evidence field. Name the owner and the measure that will show whether the change worked.

Separate a missing rule from a rule that the assistant could not find. The first needs a policy decision, while the second needs a workspace or training fix. A report that merges them will produce a training program for a documentation problem. The distinction keeps the remedy small enough to finish.

Recheck a small sample after the change and compare the same measures. If overreach falls but escalation rises, the new limit may be too tight or the approval path too slow. Adjust the limit or the path before adding another rule. The finding is complete when the assistant can resolve the routine case and recognize the exception.

Practical checklist

Write the amount, the request type, the evidence, and the approval owner in one table. Put the table where the assistant works, not in a separate policy folder. Give one example of an approved case and one example of an exception. Test the table with the next ten live requests.

Review the first month of decisions with the assistant and a finance owner. Mark the cases that should become policy and the cases that should stay exceptions. Remove limits that no longer match the business. Keep the version date beside the table.

Set a monthly review and sample both routine and exception cases. Ask the assistant which rule caused the most hesitation. Fix that rule before adding more training. The authority table should get shorter and clearer as the team learns.