Set refund and discount boundaries for a support assistant

Write the authority table

An authority table lists the refund and discount decisions an assistant may make without asking, the amount or percentage that triggers a review, and the person who owns the next level. Keep the table short enough to use during a live chat. State the currency, the tax treatment, and whether the limit is per customer or per order. A vague instruction such as use good judgment is not an authority limit.

Include the routine cases that consume most of the queue, such as a duplicate charge, a missing item, or a service delay. For each case, give the assistant a default action and the evidence required before acting. Add a stop rule for anything that looks like fraud, a legal threat, or a pattern of repeated refunds. The table should let the assistant resolve the common case and recognize the rare one.

Define the evidence required

Require the order number, the payment record, the customer's stated issue, and the policy clause that applies. Ask the assistant to link the evidence in the ticket rather than describe it from memory. A refund without a source record is difficult to audit and easy to duplicate. The evidence standard should match the size of the decision.

For a discount, require the approved campaign, the customer segment, and the expiry date. For a refund, require the original charge and any prior adjustment on the same order. If the evidence is incomplete, the assistant should request the missing item instead of guessing. A short checklist beside the authority table keeps the standard visible.

Separate policy from exception

Policy covers the published rule the customer can read, while an exception is a decision to depart from it. Write both paths, because an assistant who knows only the policy will escalate every edge case. Name who may approve an exception and how the approval is recorded. The customer should receive the same answer whether the assistant or the manager handles the case.

Give the assistant language for explaining a policy without sounding rigid. The explanation should name the rule, the evidence, and the next option. If the customer disagrees, the assistant should offer the exception path rather than argue. Clear language lowers the temperature before a manager becomes involved.

Draft the customer language

Write short templates for an approved refund, a declined request, and a request that needs more evidence. Use plain language and avoid promises about timing that the finance team has not confirmed. State the amount, the method, and the expected posting window only when those facts are known. The template should make the next step obvious without oversharing internal process.

Test the templates against real messages from the last month and remove any phrase that caused a follow-up question. Keep one version for chat and one for email if the channels need different pacing. Update the templates when the policy changes, not after a complaint. A template is only useful if it matches the current authority table.

Review the first exceptions

Read the first ten exceptions with the assistant and the owner who approved them. Mark whether the evidence was complete, the approval was recorded, and the customer received a clear answer. Look for exceptions that should become policy because they recur. A recurring exception is a sign that the published rule no longer fits the work.

Check the cases the assistant handled without escalation as well. A fast approval can hide a missing document or a discount applied outside the campaign. Sample both the routine and the exception cases in the same review. The comparison shows whether the authority table is being used or quietly ignored.

Update the brief

Revise the authority table when a product, price, or policy changes. Tell the assistant which line changed and give one example of the new decision. Remove limits that no longer match the finance team's actual practice. A table that lags behind the business teaches the assistant to distrust the written rule.

Keep the version date and the approver beside the table so the next reviewer knows what is current. Add a short note about any exception that became policy. Share the update in the same channel where the assistant receives work. The update is complete when the assistant can state the new limit without looking it up.

Set a monthly check

Once a month, compare the refund and discount decisions with the authority table. Count the cases that needed an approval and the cases that should have but did not. Read two examples to understand the reason. The count is a prompt for a conversation, not a performance score.

Ask the assistant which rule caused the most hesitation during the month. Their answer often reveals a conflict between the policy and the customer's expectation. Fix the rule or the template before adding more training. A monthly check that produces one concrete change is more useful than a long report.

Keep the review notes with the authority table so the next reviewer can see the cases behind a change. Remove old limits that are no longer used and mark the date they stopped applying. A table that accumulates rules without retiring any becomes harder to follow. The monthly check should leave the written rule shorter or clearer than it was.

Check one customer-facing template against the table before the next busy period. A template that asks for the right evidence but promises a decision the assistant cannot make will create rework. Read the template as if you were the customer and mark every sentence that implies a commitment. Update the sentence or the limit before the first case arrives.