Transactional
AuraScore 85/100

Subscription Billing Failure Recovery Sequence Architecture

Create a technical copy and event logic specification for automated SaaS failed payment dunning email workflows.

Use this prompt when designing multi-stage dunning email flows to recover involuntary churn. It generates comprehensive technical trigger rules, dynamic variables, and high-converting transactional copy blocks.

Template

Role: Principal Customer Lifecycle Copywriter and Billing UX Specialist

Context

  • Brand identity and sender context: {{company_name}}
  • Impacted subscription level: {{subscription_tier}}
  • Involuntary churn policy window: {{grace_period_days}}
  • Automated payment processing schedule: {{billing_retry_cadence}}
  • Source webhook triggers: {{payment_gateway_events}}
  • Customer escalation endpoint: {{support_channel}}

Task

Architect an end-to-end transactional dunning email specification that provides engineering trigger logic, dynamic data contracts, and complete transactional copy variants to maximize failed payment recovery while minimizing customer frustration.

Method

  1. Map incoming {{payment_gateway_events}} into distinct decline categories (soft decline vs. hard decline).
  2. Establish a 3-touch notification schedule spanning {{grace_period_days}} synchronized with {{billing_retry_cadence}}.
  3. Formulate transactional subject line pairs with zero deceptive clickbait to preserve inbox deliverability.
  4. Define strict data dictionary requirements showing dynamic token bindings for {{company_name}} and {{subscription_tier}}.
  5. Design single-click authenticated billing update CTA flow requirements without requiring complex login loops.
  6. Draft modular email body copy for Touch 1 (Gentle notice), Touch 2 (Imminent interruption), and Touch 3 (Final grace period notice).
  7. Formulate escalation fail-safes and fallback routing to {{support_channel}}.

Constraints

  • MUST adhere strictly to CAN-SPAM and GDPR transactional message exemptions (zero promotional cross-sells).
  • MUST explicitly declare token formatting for every variable string.
  • MUST NOT use aggressive or punitive collection language.
  • MUST include explicit fallback text for missing dynamic attributes.

Output format

Provide the specification organized in these exact sections:

  1. Trigger & Event Logic Matrix
  2. Dynamic Data Dictionary
  3. Complete Email Copy Specs (Touch 1, Touch 2, Touch 3: Subject, Preheader, Body, CTA label, Deep link structure)
  4. Edge Case Handling and Fallback Architecture

Self-review

  • Confirm all 6 variables from the context are logically integrated.
  • Verify transactional compliance by checking that marketing footers and opt-outs are omitted in favor of transactional terms.
  • Ensure each email touchpoint has an explicit, measurable objective.
AuraScore breakdown
85/100Provisional
Instruction clarity15/15 · Strong

Explicit role, a named task, and discrete steps the model can follow.

Context architecture12/12 · Strong

Background, inputs and variables the model needs before it starts.

Constraint engineering12/12 · Strong

Hard boundaries — what the model must and must not do.

Output specification6/14 · Thin

A named, field-level shape for the response.

Reasoning structure10/10 · Strong

Ordered work items that force analysis before an answer.

Model compatibility10/10 · Strong

Length and structure that travel across frontier models.

Token efficiency7/10 · Adequate

Signal density — instruction weight without padding.

Reusability7/7 · Strong

Documented variables so the scaffold adapts to new inputs.

Robustness5/5 · Strong

Quality bar, assumptions and behaviour when inputs are thin.

Observed performance1/5 · Thin

How much real usage the template has behind it.

emails
emails-transactional
business-strategy-marketing-sales
transactional
dunning
saas-retention