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.
Source: Forward Future ↗graded C · 55/100 — how grades work →
More maintenance loops
Upgrade to current Node LTS
Move the project to the current Node LTS across .nvmrc, CI config, Dockerfiles, and engines, fixing deprecations until everything is green on the new runtime.
Upgrade dependencies one at a time
Walk through outdated dependencies one package per turn, upgrading, running the full check suite, and pinning back anything that breaks.
Triage untriaged issues to zero
Pick the oldest untriaged issue, validate it against the current build, then label it, close if obsolete, or document repro steps—one per turn until the queue empties or 12 iterations pass.