Leftbank Art — Dust Dashboard

SIM RUNNING · 7 actions today

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

  1. Identify the order — lookup_customer then list_customer_orders, or use the order id if cited. Call lookup_order(order_id) for detail.
  2. Decide refund amount:
  3. Damaged single item → partial refund equal to that item's line_total_usd.
  4. Multiple damaged items → sum of those lines.
  5. Customer asks for full refund + order is recent + ≤ 30 days from delivery → full refund.
  6. Customer asks for full refund on an order > 30 days old or final-sale (framed prints) → escalate, do not auto-issue.
  7. Check the threshold — if amount > $500 OR sentiment < -0.4 OR confidence < 0.85, call escalate_to_human with reason and do NOT issue. The reviewer decides.
  8. Otherwise: call issue_refund(order_id, amount_usd, reason). Then call send_email_via_approval_gate with action_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_knowledge if 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.