mcpField
R
refund-and-support-flow-review

refund-and-support-flow-review

github.com/sylphxaiその他166 回インストール今日更新
リポジトリ

refund-and-support-flow-review について

有料エンタイトルメントを持つ製品の返金・サポートプロセスを設計するスキルです。決済事業者ごとの権限、アカウントの時系列記録、アクセス制限前の不正利用対策と異議申し立てを重視します。

主な機能

  1. 01決済事業者と権限の整理
  2. 02返金・解約状態の設計
  3. 03アカウント証拠の時系列化
  4. 04不正利用スコアと誤判定対策
  5. 05サポート運用とエスカレーション設計
  6. 06事業者ポリシーの出典確認

活用シーン

  1. 01複数のストアや決済事業者の返金設計
  2. 02返金・チャージバック後のアクセス変更の確認
  3. 03不正利用審査と異議申し立て手順の策定

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/sylphxai/skills --skill refund-and-support-flow-review

インストール後、Claude Code で/refund-and-support-flow-reviewを入力して読み込まれたか確認します。

同梱ファイルagents/openai.yamlreferences/refund-support-flow-patterns.md

詳細

返金およびサポートフローのレビュー

信頼を損なったり、不正利用によって製品が破綻したりすることなく返金に対応するには、このスキルを使用します。

ワークフロー

  1. 購入の種類、プロバイダー/ストア、権利の種類、返金の決定権者、サポートの担当を特定します。
  2. references/refund-support-flow-patterns.md を読みます。
  3. プロバイダー固有のシグナル、返金の検出、キャンセル、購入の復元、権利の信頼できる唯一の情報源、権利の調整、ユーザーへのメッセージ、サポートのトリアージ、異議申し立て、不正利用の審査を整理します。
  4. キャンセル、通常の返金、善意による返金、不正行為、チャージバック、紛争、消費型アイテムの取り消し、非消費型アイテムの権利剥奪、繰り返される不正利用を区別します。
  5. 対応を行う前に、アカウントごとに購入、付与、利用/消費、キャンセル、返金リクエスト、プロバイダーによる確認、権利の移行、サポートメッセージ、チャージバック/紛争、異議申し立て、再購入を含むタイムラインを作成します。
  6. アカウント制限を行う前に、不正利用のスコアリング、誤検知への対策、サポートダッシュボード、指標、承認しきい値を定義します。
  7. サポートの運用モデルを定義します。キューの担当者、SLA、エスカレーションの担当者、エージェントのオーバーライド権限、QA のサンプリング、承認しきい値、異議申し立ての期限を含めます。
  8. プロバイダーテーブル、返金/キャンセル/復元の状態マシン、判断テーブル、サポート用定型文、必須プロパティを含むイベントスキーマ、証拠のタイムライン、サポート運用モデル、リスク段階を作成します。

使用しない場合

  • 主な成果物が返金の決定権ではなく、チャネル全体、キュー、トリアージ、人員配置、QA、エスカレーションの運用モデルである場合は、customer-support-operations を使用します。
  • チェックアウト、台帳の取り込み、決済、会計締め、権利の投影をまとめて設計する必要がある場合は、payment-platform-readiness を使用します。
  • 適用される返金と権利の状態がすでに明らかな場合、顧客への返信を 1 件作成するために、この完全な状態マシンのワークフローを使用しないでください。

情報源の確認

  • 使用時点での、プロバイダー/ストアの返金、キャンセル、チャージバック、復元、権利、異議申し立てに関する決定権を、公式情報源で確認します。
  • 金銭またはアクセスに影響する外部ルールごとに、プロバイダー、製品の種類、地域、ポリシー/API のバージョン、アクセス日、URL を記録します。
  • 内部で暫定的に設定したしきい値、記憶に基づくストアのルール、サポート上の慣例を、プロバイダーのポリシーとして扱わないでください。

ガードレール

  • 通常の返金後に自動的にアカウントを禁止しないでください。
  • 脅しを使って再購入を強要しないでください。
  • サポートと監査のために、改変不能な台帳の証拠を保持します。
  • Apple、Google、Stripe、チャージバック、社内の善意による対応を 1 つのポリシーにまとめないでください。
  • キャンセルと返金を混同しないでください。ユーザーは返金を受けずに更新をキャンセルし、有料アクセスを期間終了まで維持できる場合があります。
  • サーバー側に権利の信頼できる唯一の情報源がなく、監査証跡を元に戻せない状態で、永続的なアクセス権を剥奪しないでください。
  • 返金、チャージバックの敗訴、または手動での剥奪が確定した後に、台帳との照合を行わずに購入の復元やクライアントの状態によってアクセス権を再付与しないでください。
  • 消費済みの消費型アイテムについて、明示的なポリシー、警告、審査、異議申し立ての手段なしに、予期しないマイナス残高を標準の対応として発生させないでください。
  • 製品の品質問題、障害、請求に関する表示、誤購入を罰するために返金フローを利用しないでください。こうした問題の理由コードを、製品やサポートの改善に反映します。
  • 脅しを使ってユーザーに再購入を求めないでください。再購入によって価値が復元されるのは、権利、紛争、不正利用の状態を照合した後だけです。
  • 理由コードの分類体系を省略しないでください。製品の品質とサポートに関する分析では、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.

コメント