Dunning Follow-Up

Read failed-payment accounts via API and email dunning follow-ups to at-risk customers to recover revenue before involuntary churn.

When to use

• A billing/payment provider reports new failed or past-due invoices.
• A recurring revenue-operations sweep for accounts stuck in a dunning (payment-retry) cycle.
• A customer's card has expired or been declined and no follow-up has been sent yet.
• Finance or a human teammate asks for an updated list of at-risk accounts.

Tools

• http-get: reads failed-payment and past-due account data from the billing provider's API.
• write-file: drafts the dunning follow-up email copy and the at-risk account summary before sending.
• send-email: delivers the dunning follow-up message to the affected customer.

Playbook

1. Call the billing provider REST API with http-get (e.g. GET https://api.stripe.com/v1/invoices?status=past_due). Authentication is injected by the org's Integration row for this host — never ask for, echo, or hardcode credentials. If the call returns 401/403 or no Integration row exists, stop and message a human via send-message asking them to create the Integration, naming the service and required scopes.
2. Parse the response and build a list of at-risk accounts: customer name, email, amount owed, failure reason, and retry date.
3. For each account, check whether a follow-up was already sent recently; skip accounts already contacted within the cooldown window.
4. Draft the dunning email copy for each remaining account, including the outstanding amount and a clear payment-update call to action.
5. Save the draft copy and the at-risk account summary to a file with write-file for record-keeping and audit.
6. Send each dunning follow-up email to the customer with send-email, personalizing the amount owed and due date.
7. If the API response is empty, re-verify the endpoint URL and status filter before concluding there are no at-risk accounts.
8. Note any accounts that require a payment plan change, refund, or record update — this requires PATCH/PUT/DELETE on the billing system, which is NOT POSSIBLE with the declared tools. Compile the change list to a file with write-file and hand off to a human via send-message; never imply the update was made.
9. Summarize the outcome — accounts identified, emails sent, and any handed-off items — via complete-task.

Failure modes

• 401/403 response -> missing Integration for the billing host; stop and escalate via send-message naming the service and required scopes.
• Empty result set -> verify the endpoint URL, status filter, and pagination parameters before assuming no at-risk accounts exist.
• Rate limit (429) response -> back off and retry later; note the limit in memory via update-memory so future runs pace requests.
• Record needs an update the API can't perform read-only -> stop, write the change list to a file, and hand off to a human via send-message.

Done when

• The at-risk account summary file exists via write-file and lists every account pulled from the billing API.
• Every eligible at-risk customer has received a dunning follow-up email via send-email.
• Any accounts requiring a write-side update are documented and handed off to a human, and the task is closed via complete-task.