跳到正文
cccskills
免费在 GitHub 公开

dunning-escalation

Recover failed Stripe subscription payments through a charge retry and three timed reminder emails. Track each subscription’s progress in a ledger, stop reminders after payment, and hand unresolved cases to a person after the final notice.

中文简介正在准备中。当前显示英语简介。

原文查看原文说明

Per-subscription dunning ladder for recovering failed Stripe payments — smart retry, payment reminder, update-your-card notice, final notice — with minimum wait times between rungs, the ledger format that carries state across hourly runs, and the stop-for-human line at cancellation, credits, and refunds.

集成工具Stripe
查看安装方法

适用场景

  • Follow up on failed subscription payments
  • Space reminder emails and prevent repeat sends
  • Check a subscription’s recovery progress
  • Hand unpaid cases to a person after the final notice

包含的文件(1)

  • SKILL.md5.6 KB

SKILL.md(原文)

安装前可以查看交给 AI 代理的指令内容。

<skill name="dunning-escalation"> <overview> Turn a failed Stripe invoice into a worked recovery instead of a silent lapse. An hourly cron re-prompts one persistent session; this skill defines the fixed four-rung ladder each failed subscription climbs, how long to wait between rungs, and what to send at each one. The ledger is what makes this a ladder and not a loop — without it, every run would just resend rung one forever. </overview> <when-to-load> - The hourly cron fires the payment-recovery sweep. - A human asks why a specific subscription is or isn't being emailed, or what rung it's on. </when-to-load> <workflow>

Step 1 — Resume the ledger

Read memory/payment-recovery-ledger.md. For every subscription already tracked, note its current rung, the timestamp of its last action, and its next-eligible-escalation time. Anything not yet on the ledger is a candidate for Step 2.

Step 2 — Pull failed invoices and subscription state from Stripe

Query Stripe for invoices in a failed/past-due state and their parent subscriptions. For each:

  • New failure (not on the ledger) → start at rung 1 (smart retry).
  • Already on the ledger → check whether now >= next-eligible time; if not, leave it alone this run.
  • No longer failing (invoice paid, subscription active/current) → go to Step 6 (close out), regardless of rung.

Step 3 — The ladder

RungNameActionMinimum wait before this rung
1Smart retryRetry the failed charge against the existing payment method via Stripe (off-session), no email sent yetImmediately on first failure
2Payment reminderFriendly email: the charge didn't go through, here's the amount and a pay link24h after rung 1 if still failing
3Update-your-card noticeFirmer email naming the likely cause (expired/declined card) with a direct link to update the payment method48h after rung 2 if still failing
4Final noticeClear, professional email stating this is the last automated reminder before the account needs manual attention72h after rung 3 if still failing

A subscription advances at most one rung per run, and only once its minimum wait has elapsed. Never send two rungs' worth of email in the same run, and never re-send the same rung.

Step 4 — Send the rung's email

Send the exact email for the current rung via {{dunning_channel}}, addressed to the subscription's billing contact. Keep the tone matched to the rung — rung 2 is a nudge, rung 4 is unambiguous but still professional, never threatening. Every send is logged to the ledger with the rung and timestamp.

Step 5 — Rung 4 is the ceiling

Once a subscription has received the final notice and the invoice is still unpaid, do not create a rung 5. Mark it awaiting-human on the ledger and surface it in the Slack summary every run until a person acts or it pays. Never cancel the subscription, issue a credit, or process a refund — that decision, and the action, belongs to a human.

Step 6 — Close out on payment

If a tracked subscription's invoice has been paid (checked fresh from Stripe every run, not assumed), mark it recovered on the ledger with the rung it was on when it cleared, stop sending it anything, and report it as a recovery in the summary.

Step 7 — Post the summary

Post one message per run to {{alert_channel}}: subscriptions that advanced a rung (with new rung), subscriptions newly at awaiting-human, and subscriptions that recovered since the last run. Omit subscriptions with no change.

Step 8 — Update the ledger

Write the full current state back to memory/payment-recovery-ledger.md (see <ledger-format>) before ending the turn.

</workflow> <ledger-format> Lives at `memory/payment-recovery-ledger.md`. One row per subscription currently or recently on the ladder: subscription ID, customer, current rung (1–4, or `recovered` / `awaiting-human`), last action + timestamp, next-eligible escalation time, and outcome once resolved (`recovered` with the rung it paid at, or `awaiting-human` with the date it hit rung 4). Prune a row only after it's been `recovered` for a full cycle, so a bounce-back failure is still recognized as a returning case rather than a brand-new one. </ledger-format> <guardrails> - **Smart-retry and dunning only.** The only Stripe write this skill performs is retrying an existing failed charge. The only customer-facing action is sending one of the four ladder emails. Nothing else is in scope. - **Never cancel, credit, or refund.** Regardless of how long a subscription has been failing, ending it, crediting it, or refunding it requires a human and is never done by this skill. - **One rung per run, minimum wait enforced.** A subscription cannot skip a rung or be re-messaged before its wait time elapses, even if a run is manually re-triggered. - **Stops immediately on payment.** A paid invoice ends the ladder for that subscription on the very next check — no extra emails, no delay. - **Scoped secrets.** Stripe access is brokered through the connector; no raw key is ever shown to the model or written to logs. - **Ledger is the source of truth for state.** Between runs, nothing about ladder position is inferred or guessed — it comes from the ledger, checked against fresh Stripe state. </guardrails> </skill>

评价

还没有评价。欢迎分享你的使用感受。

评论

无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。

还没有评论。来写第一条吧。

提交后会立即公开。请勿填写邮箱、电话等个人信息。URL 最多 2 个。

0 / 1000 字

此表单受 reCAPTCHA 保护,适用 Google 的隐私权政策和服务条款。

同一仓库的技能

Review Slack access requests against Okta role and team information, then prepare narrowly scoped GitHub or AWS IAM permissions. Apply changes only after an eligible person's approval and record the grant, reasoning, approver, and timestamp.

中文简介正在准备中。当前显示英语简介。

  • Reviewing GitHub repository access requests from Slack
  • Preparing AWS IAM permissions for a specific task
  • Routing sensitive access requests for additional review
kortix-ai/suna2万2026年10月21日 更新

Research companies and people before outreach or meetings. Combines business profiles, recent news, hiring signals, and key contacts into a sourced brief with talking points and suggested questions, adding relationship history when CRM data is connected.

中文简介正在准备中。当前显示英语简介。

  • Research a prospective customer before outreach
  • Prepare background information for meeting attendees
  • Compare a competitor's products and positioning
kortix-ai/suna2万2026年10月21日 更新

Review daily Google Ads and Meta Ads results for budget pacing, declining performance, and unusual activity. Get prioritized findings with supporting numbers and concrete recommendations for a marketing team to assess and carry out.

中文简介正在准备中。当前显示英语简介。

  • Checking whether campaign budgets are being spent on schedule
  • Investigating rising acquisition costs or falling ad returns
  • Finding ads and keywords that spend without converting
kortix-ai/suna2万2026年10月21日 更新

Automate website tasks such as navigating pages, filling forms, clicking buttons, taking screenshots, and extracting data. The skill also supports web app testing, with specialized guides for Electron desktop apps, Slack, and cloud browsers.

中文简介正在准备中。当前显示英语简介。

  • Automate form entry and page navigation
  • Capture screenshots and extract page data
  • Explore web apps for bugs
kortix-ai/suna2万2026年10月21日 更新

Process emailed vendor invoices by extracting details, comparing them with purchase orders and invoice history, and recording duplicates, overcharges, or missing orders. Summarize results in Slack for human review; payment approval and execution remain with people.

中文简介正在准备中。当前显示英语简介。

  • Checking incoming invoices against purchase orders
  • Finding duplicate invoices and likely resends
  • Reviewing unit prices and remaining order balances
kortix-ai/suna2万2026年10月21日 更新

billing

免费

Guide changes to Kortix billing code, admin controls, and pricing screens. Explain how plans, trials, enterprise contracts, and access exceptions should work, where pricing is defined, and which audited routes must handle account changes.

中文简介正在准备中。当前显示英语简介。

  • Update billing logic and its specification together
  • Review how trials and enterprise contracts are handled
  • Find the code that defines prices and allowances
kortix-ai/suna2万2026年10月21日 更新

查看 kortix-ai 的全部技能

报告此技能的问题