Outsourced Philippines guide
Set a Written Refund Authority for Philippines Support Agents
Define refund tiers, evidence requirements, payment separation, exception handling, and a sampling routine that keeps support decisions consistent.
Refund authority is one of the first boundaries a growing support team gets wrong. A new agent wants to help a frustrated customer, a supervisor is offline, and the quickest path looks like a refund issued from the same screen used to read the order. A written authority schedule gives the agent a clear answer before the customer is waiting, and it gives the business a record of who could approve what. The written schedule should answer the common case before the customer asks.
On this page
Define the refund decision, not just the amount
A refund decision includes the reason, the evidence, the amount, the payment method, and the person who accepts the loss. Two requests for the same amount can carry very different risk: a duplicate charge with a bank statement is not the same as a goodwill credit after a delayed delivery. Write the categories first, then attach a dollar limit to each one. Write those categories into the schedule so the agent does not have to infer the risk from the amount alone.
Separate a full refund, a partial refund, a store credit, a replacement, and a chargeback response. Each has its own evidence and its own accounting effect. If the team treats them as one generic “refund” button, reporting will mix customer recovery with payment reversals and nobody will know which lever is working. Labeling the categories also keeps the monthly report readable when a customer receives more than one remedy.
Publish tiers with evidence requirements
Use a small number of tiers that map to real decisions. An agent might approve a replacement or a credit below a stated value when the order record and the customer statement agree. A team lead might approve a larger amount when a photo or carrier record supports the claim. The owner or finance lead handles anything above that line, plus every request that touches a legal threat or a regulated product.
For each tier, list the evidence the approver must see and the fields the agent must record. The evidence should be something a second person can inspect, such as an order line, a payment reference, a delivery scan, or a written customer statement. A note that says “customer is upset” is context, not evidence, and it should not be enough to release money. A screenshot without a date and a source link is weak evidence because nobody can tell what changed afterward.
Separate approval from payment execution
The person who decides a refund should not also be the only person who can send it. Where the platform allows, route the approved refund to a second queue for payment release. This is not distrust of the agent; it is a control that catches a mistyped amount, a duplicate request, or a compromised account before money leaves the business. The extra step is short, and it catches the errors that are most expensive to reverse.
If the team is too small for a separate payment role, use a documented review on the next business day and a daily reconciliation of refunds against approvals. The reviewer checks the amount, the order, the reason, and the payment destination. A solo owner can perform that review, but the check must be recorded rather than assumed from memory. The reviewer should sign the reconciliation, not just glance at a total.
Handle the exceptions that exceed the limit
Write what an agent should do when a request sits just above the limit or when the evidence is incomplete. The safe answer is to acknowledge the customer, explain that a review is underway, and set a realistic update time. The agent should not split one refund into two smaller refunds to stay under the limit, and the policy should say that explicitly. The customer message should say that the request is being reviewed, not that it will be approved.
Escalations need a named owner and a response window. If the owner is unavailable, a deputy with the same written authority should be listed before the absence begins. An escalation that sits in a shared inbox over the weekend is not a control; it is a queue with no owner, and the customer will usually escalate again through a public channel. A deputy should have the same written limits so the queue does not slow down when the owner steps away.
Sample decisions after the fact
Each week, pull a sample of refunds across the tiers and check the evidence, the approval, and the payment record. Include at least one denied request and one escalation so the review covers judgment as well as compliance. Record whether the decision matched the written rule, whether the customer communication was accurate, and whether the payment landed where the record said it would. Keep the sample small enough to review properly and rotate the reviewer so the check does not become one person’s habit.
When a sample finds a gap, correct the rule or the form rather than only coaching the agent. If three agents missed the same evidence field, the field is probably buried in the tool. If one agent approved outside the tier, inspect the access rights and the escalation path. The sample should produce a change to the system, not just a note in a file.
Update the authority when the business changes
Refund limits age quickly when prices rise, a new payment provider arrives, or a marketplace changes its dispute rules. Put an expiry date on the authority schedule and review it at least twice a year. When a limit changes, update the written schedule, the support macro, the approval routing, and the training sample on the same day. The review should include the support lead, the finance owner, and the person who handles disputes.
Keep the old versions so a later reviewer can see what rule applied to an earlier transaction. The version should show the effective date, the approver, and the reason for the change. That record protects the team during an audit and helps a new supervisor understand why the current line is where it is. Store the schedule where the support team works, not only in a legal folder nobody opens during a shift.
Sources and next steps
Use the operations support work lane as a practical starting point, then review the onboarding checklist before expanding the role.
