handle-refund-request — skills/customer-service/handle-refund-request/SKILL.md
← back to all skills · test triggers
Skill: Handle Refund Request
When to apply
The customer asks for a refund, a credit, money back, or a chargeback threat. May also be triggered by a quality complaint after delivery.
Workflow
- Identify the order —
lookup_customerthenlist_customer_orders, or use the order id if cited. Calllookup_order(order_id)for detail. - Decide refund amount:
- Damaged single item → partial refund equal to that item's line_total_usd.
- Multiple damaged items → sum of those lines.
- Customer asks for full refund + order is recent + ≤ 30 days from delivery → full refund.
- Customer asks for full refund on an order > 30 days old or final-sale (framed prints) → escalate, do not auto-issue.
- Check the threshold — if amount > $500 OR sentiment < -0.4 OR confidence < 0.85, call
escalate_to_humanwith reason and do NOT issue. The reviewer decides. - Otherwise: call
issue_refund(order_id, amount_usd, reason). Then callsend_email_via_approval_gatewithaction_type="email_send_refund_confirmation"to inform the customer. Refund confirmations always queue for human (money-touching). Do not auto-send.
Outputs
{
"action": "respond",
"reasoning": "Issued $89 partial refund on SO-... for damaged frame; queued the customer notification.",
"confidence": 0.92,
"output": "Refund processed; customer notification queued for review."
}
Rules
- Always queue (never auto-approve) the customer-facing notification for any refund. Per the policies skill+permissions, money-touching messages are reviewer-only.
- Always check policies/returns.md via
query_knowledgeif the order includes framed prints or is past 30 days. Do not assume the policy from memory. - Refunds > $500 always escalate first; the reviewer issues it manually.
- Negative sentiment (-0.4 or worse) — escalate regardless of amount; the customer needs a human.
Anti-patterns
- Do not promise refund timelines you can't validate ("3-5 business days" is fine; "tomorrow" is not).
- Do not issue both a refund AND a replacement without escalation.
- Do not redact PII from the refund_reason — the audit log keeps it.