+ Loop 050
+The refund follow-up loop
+A persistent follow-up workflow that starts a refund claim, watches replies and deadlines, and keeps the case moving until the money arrives.
+ + +Ready-to-use prompt
+Copy the loop
+Get my refund for [company and charge info]. Start the claim now through an approved support channel, then keep following up on replies, promises, and deadlines until the refund arrives. Keep a short case note so each follow-up has context. Stop only when the refund is received or you are genuinely blocked and need me.
+Verify / stop
+The refund is received, or a genuine blocker requires the user.
+An open claim, promise, or pending refund is progress, not success; keep following up until the money arrives or no approved next step remains.
++ Context and guidance + When to use it, steps, safety notes, and related loops +
+ +Use this when
+Use this when someone owes you a refund and getting it may take more than one support conversation or follow-up.
+How to run it
+-
+
- Gather the charge, reason for the refund, useful evidence, current status, and any earlier conversation or promise. +
- Start or continue the claim through a support channel the user has approved, then note what happened and what should happen next. +
- Follow up whenever a reply, promise, or deadline creates a useful next step; keep the case moving instead of treating a pending status as done. +
- Stop when the refund arrives, or explain the genuine blocker when the next useful step needs the user. +
Why it works
+Refunds often stall because a promise or pending status gets treated as completion. This loop keeps ownership through delays and handoffs until the money actually arrives.
+Implementation note
+Use truthful information and the permissions already granted. If the next step needs a new permission or decision, bring that blocker to the user instead of stopping silently.
+