Chase a refund until it lands
Open the claim, watch replies and deadlines, and keep the case moving until the money actually arrives.
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 it runs
- 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.
Done when
✓ 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.
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.
More maintenance loops
Keep memory pins under control
Audit and prune pinned memory contexts to stay under 7, replacing competing invariants atomically and checking load count before each pin.
Prove your backups actually restore
Restore random real recovery points, verify integrity and RPO/RTO, and keep every failure as a regression drill.
Weekly tech debt report
Every Friday, compile a trend report of debt signals — TODO count, lint suppressions, type coverage, largest files — so the team sees drift before it compounds.