refund-and-support-flow-review

退款与支持流程审查

使用此技能处理退款，既不损害信任，也不让滥用行为破坏产品。

工作流

1. 确认购买类型、提供方／商店、权益类型、退款权限和支持归属。
2. 阅读 references/refund-support-flow-patterns.md。
3. 梳理提供方特定信号、退款检测、取消、恢复购买、权益事实来源、权益调整、用户消息、支持分流、申诉和滥用审查。
4. 区分取消、普通退款、善意退款、欺诈、拒付、争议、消耗品撤销、非消耗品撤销和屡次滥用。
5. 采取行动前，为每个账户建立一条时间线：购买、授予、使用／消费、取消、退款请求、提供方确认、权益状态转换、支持消息、拒付／争议、申诉和再次购买。
6. 在限制账户前，定义滥用评分、误判控制、支持仪表板、指标和审批门槛。
7. 定义支持运营模式：队列负责人、SLA、升级负责人、客服代理覆盖权限、QA 抽样、审批门槛和申诉时限。
8. 产出提供方表格、退款／取消／恢复状态机、决策表、支持话术、包含必需属性的事件架构、证据时间线、支持运营模式和风险阶梯。

不适用场景

• 如果主要产出是整个渠道、队列、分流、人员配置、QA 或升级运营模式，而非退款权限，请使用 customer-support-operations。
• 如果需要同时设计结账、账本数据导入、结算、财务结账和权益投影，请使用 payment-platform-readiness。
• 如果适用的退款和权益状态已经明确，不要调用这套完整的状态机工作流来起草一条客户回复。

来源核实

• 使用时，应通过官方来源核实当前提供方／商店有关退款、取消、拒付、恢复、权益和申诉的权限规则。
• 对每条会影响资金或访问权限的外部规则，记录提供方、产品类型、地理区域、政策／API 版本、访问日期和 URL。
• 绝不要将内部起始门槛、记忆中的商店规则或支持惯例说成提供方政策。

防护措施

• 正常退款后不要自动封禁。
• 不要以威胁胁迫用户再次购买。
• 为支持和审计保留不可变的账本证据。
• 不要将 Apple、Google、Stripe、拒付和内部善意处理合并为一套政策。
• 不要将取消等同于退款。用户可以取消续订并保留付费访问权限直至周期结束，而无需获得退款。
• 没有服务端权益事实来源和可逆的审计轨迹时，不要撤销持久访问权限。
• 在账本完成对账前，不要让恢复购买或客户端状态在已确认退款、拒付败诉或手动撤销后重新授予访问权限。
• 默认不要让已消费的消耗品产生意外负余额；应设置明确的政策、警告、审核和申诉流程。
• 不要利用退款流程惩罚产品质量问题、服务中断、计费文案问题或意外购买；应将这些原因代码反馈到产品／支持改进中。
• 不要以威胁要求用户再次购买。只有在权益、争议和滥用状态完成核对后，再次购买才会恢复价值。
• 不要省略原因代码分类法。产品质量和支持改进必须明确区分 outage_or_bug、unclear_pricing_or_copy、duplicate_charge、accidental_purchase、minor_purchase、policy_mismatch、store_policy_redirect、support_exception 和 refund_abuse_suspected。
• 不要将拒付建模为单一退款事件；应包含 dispute_opened、evidence_due、evidence_submitted、dispute_won、dispute_lost、appeal_opened 和 repurchase_requested 状态。

输出格式

Purchase/refund context:
Authority:

Provider table:
- <provider/channel> -> signal, authority, dedupe key, refund state, entitlement action

Evidence timeline:
| Time | Source | Purchase/refund/dispute event | Entitlement state | Usage/spend | Support message | Actor | Evidence |
| --- | --- | --- | --- | --- | --- | --- | --- |

Support operating model:
| Queue | Owner | SLA | Agent permission | Approval threshold | QA/evidence |
| --- | --- | --- | --- | --- | --- |

Reason-code taxonomy:
| Reason code | Meaning | Entitlement/support action | Product/finance owner |
| --- | --- | --- | --- |

Entitlement state machine:
- <from_state> -> <event> -> <to_state>, grace/hold timing, audit evidence
- Include cancellation, restore purchase, refund, chargeback, goodwill, appeal, and repurchase paths separately.

Decision table:
- <scenario> -> entitlement action, account action, support action

Restore/repurchase/reconciliation:
- <path> -> provider truth check, entitlement ledger check, abuse/dispute check, support/audit action

Consumable ledger policy:
- Fields: granted_amount, spent_amount, remaining_amount, refundable_unused_amount, consumed_value_amount, reversal_amount, event_reward_impact, negative_balance_policy_decision.
- Formula/decision: <how balance or commerce limit is calculated without surprise debt>

Chargeback/dispute evidence packet:
- <state> -> deadline, evidence, commerce/data access, support message, owner

Abuse and trust ladder:
- <score/tier> -> evidence, action, approval, appeal path, false-positive guard

Support macros/events:
- <macro or event> with provider, purchase id, refund id, entitlement id, state transition, actor, reason code, support case id

Metrics/dashboard:
- <metric/event> -> owner, decision it supports
- Include refund detection lag, restore failures, entitlement revocation lag, support load, support QA variance, goodwill variance, false-positive/appeal reversal rate, dispute win/loss, repurchase after fix, churn, and product-quality reason trends.