オプション
家家 Skill その他 customer-billing-ops

customer-billing-ops

affaan-m/ECC affaan-m/ECC

Stripeなどの連携済み課金ツールを活用し、定期購読、返金、解約の初期対応、課金ポータルの復旧、プラン分析といった顧客向け課金ワークフローを運用します。

...すべて拡張します
5
更新された時間 2026年10月12日

顧客請求業務

このスキルは、一般的な決済APIの設計ではなく、実際の顧客対応業務に活用してください。

このスキルの目的は、オペレーターが「この顧客は誰か」「何が起きたのか」「最も安全な対処法は何か」「どのようなフォローアップを行うべきか」といった疑問に答えられるよう支援することです。

使用すべき場面

  • 顧客から「請求に不具合がある」「返金を希望する」「解約できない」といった連絡があった場合
  • 重複したサブスクリプション、誤った課金、更新失敗、または解約リスクの調査
  • プラン構成、有効なサブスクリプション、年間プランと月額プランの転換率、またはチームシートに関する混乱の確認
  • 課金ポータルのフローの作成または検証
  • サブスクリプション、請求書、返金、または支払い方法に関連するサポートへの苦情の監査

推奨ツール一覧

  • まずはStripeなどの連携済み課金ツールを活用する
  • メール、GitHub、または課題管理ツールは、補助的な証拠としてのみ使用する
  • プラットフォームがすでに必要な制御機能を提供している場合は、カスタムアカウント管理コードよりも、ホスト型請求/顧客ポータルを優先する

ガードレール

  • レスポンスには、シークレットキー、カードの完全な詳細、または不要な顧客の個人識別情報(PII)を決して公開しない
  • 安易に返金を行わないでください。まず問題を分類してください
  • 以下を区別すること:
    • 誤って重複して購入してしまった場合
    • 意図的な複数ライセンスまたはチーム向け購入
    • 製品の不具合/期待通りの価値が得られなかった場合
    • 決済の失敗または未完了
    • セルフサービス機能の欠如によるキャンセル
  • 年間プラン、チームプラン、および日割り計算が適用される状態については、対応を行う前に契約形態を確認してください

ワークフロー

1. 顧客を明確に特定する

利用可能な最も確実な識別子から確認を開始してください:

  • 顧客のメールアドレス
  • Stripeの顧客ID
  • サブスクリプションID
  • 請求書ID
  • GitHubのユーザー名、または請求先と紐付けられることが分かっている場合はサポート用メールアドレス

簡潔な識別情報の要約を返す:

  • 顧客
  • 有効なサブスクリプション
  • 解約済みのサブスクリプション
  • 請求書
  • 重複している有効なサブスクリプションなど、明らかな異常

2. 問題の分類

対応する前に、ケースを以下のいずれかのカテゴリーに分類する:

ケース 典型的な対応
個人サブスクリプションの重複 追加オプションをキャンセルし、返金を検討する
真のマルチシート/チーム利用の意図 ライセンス数を維持し、課金モデルを明確化する
支払いの失敗/チェックアウトの未完了 ポータル経由での回復、または支払い方法の更新
セルフサービス機能の欠如 ポータル、キャンセル手順、または請求書へのアクセスを提供する
製品の不具合または信頼関係の崩壊 返金、お詫び、製品の問題を記録

3. 最も安全で元に戻せる措置を最初に講じる

推奨される順序:

  1. セルフサービス管理の復元
  2. 重複または不具合のある請求状態を修正する
  3. 影響を受けた請求または重複分のみを返金する
  4. 理由を記録する
  5. 顧客への簡単なフォローアップを送信する

修正に製品側の作業が必要な場合は、以下を分けて対応する:

  • 顧客への対応を直ちに実施
  • バックログとして製品バグ/ワークフローの不備を記録する

4. オペレーター側の製品上の課題を確認する

顧客の課題がオペレーター用インターフェースの欠如に起因する場合は、それを明確に指摘してください。一般的な例:

  • 請求ポータルがない
  • 利用状況/レートリミットの可視化がない
  • プラン/ライセンス数の説明がない
  • 解約フローがない
  • 重複サブスクリプション防止機能がない

これらを単なるサポートインシデントではなく、ECC(緊急修正)またはウェブサイトのフォローアップ項目として扱ってください。

5. オペレーターへの引き継ぎ手順を作成する

最後に以下を記載する:

  • 顧客ステータスの概要
  • 実施した対応
  • 収益への影響
  • 送信するフォローアップ文
  • 作成すべき製品またはバックログの課題

出力形式

以下の構成を使用してください:

顧客
- 氏名 / メールアドレス
- 関連するアカウント識別子

請求状況
- 有効なサブスクリプション
- 請求書または更新状況
- 異常

決定
- 課題の分類
- この対応が適切である理由

実施した対応
- 返金 / キャンセル / ポータル / 対応なし

フォローアップ
- 顧客への短いメッセージ

製品の不備
- 製品またはウェブサイトで修正すべき点

適切な推奨事項の例

  • 「現時点では、適切な解決策はカスタムダッシュボードではなく、請求ポータルです」
  • 「これは実際のチームライセンスの購入ではなく、個人用チェックアウトの重複のように見えます」
  • 「重複した請求のうち1件を返金し、残りの有効なサブスクリプションは維持した上で、必要に応じて後日、顧客を組織単位の請求に切り替えてください」
GitHubで見る
---
name: customer-billing-ops
description: Operate customer billing workflows such as subscriptions, refunds, churn triage, billing-portal recovery, and plan analysis using connected billing tools like Stripe.
---

# Customer Billing Ops

Use this skill for real customer operations, not generic payment API design.

The goal is to help the operator answer: who is this customer, what happened, what is the safest fix, and what follow-up should we send?

## When to Use

- Customer says billing is broken, they want a refund, or they cannot cancel
- Investigating duplicate subscriptions, accidental charges, failed renewals, or churn risk
- Reviewing plan mix, active subscriptions, yearly vs monthly conversion, or team-seat confusion
- Creating or validating a billing portal flow
- Auditing support complaints that touch subscriptions, invoices, refunds, or payment methods

## Preferred Tool Surface

- Use connected billing tools such as Stripe first
- Use email, GitHub, or issue trackers only as supporting evidence
- Prefer hosted billing/customer portals over custom account-management code when the platform already provides the needed controls

## Guardrails

- Never expose secret keys, full card details, or unnecessary customer PII in the response
- Do not refund blindly; first classify the issue
- Distinguish among:
  - accidental duplicate purchase
  - deliberate multi-seat or team purchase
  - broken product / unmet value
  - failed or incomplete checkout
  - cancellation due to missing self-serve controls
- For annual plans, team plans, and prorated states, verify the contract shape before taking action

## Workflow

### 1. Identify the customer cleanly

Start from the strongest identifier available:

- customer email
- Stripe customer ID
- subscription ID
- invoice ID
- GitHub username or support email if it is known to map back to billing

Return a concise identity summary:

- customer
- active subscriptions
- canceled subscriptions
- invoices
- obvious anomalies such as duplicate active subscriptions

### 2. Classify the issue

Put the case into one bucket before acting:

| Case | Typical action |
|------|----------------|
| Duplicate personal subscription | cancel extras, consider refund |
| Real multi-seat/team intent | preserve seats, clarify billing model |
| Failed payment / incomplete checkout | recover via portal or update payment method |
| Missing self-serve controls | provide portal, cancellation path, or invoice access |
| Product failure or trust break | refund, apologize, log product issue |

### 3. Take the safest reversible action first

Preferred order:

1. restore self-serve management
2. fix duplicate or broken billing state
3. refund only the affected charge or duplicate
4. document the reason
5. send a short customer follow-up

If the fix requires product work, separate:

- customer remediation now
- product bug / workflow gap for backlog

### 4. Check operator-side product gaps

If the customer pain comes from a missing operator surface, call it out explicitly. Common examples:

- no billing portal
- no usage/rate-limit visibility
- no plan/seat explanation
- no cancellation flow
- no duplicate-subscription guard

Treat those as ECC or website follow-up items, not just support incidents.

### 5. Produce the operator handoff

End with:

- customer state summary
- action taken
- revenue impact
- follow-up text to send
- product or backlog issue to create

## Output Format

Use this structure:

```text
CUSTOMER
- name / email
- relevant account identifiers

BILLING STATE
- active subscriptions
- invoice or renewal state
- anomalies

DECISION
- issue classification
- why this action is correct

ACTION TAKEN
- refund / cancel / portal / no-op

FOLLOW-UP
- short customer message

PRODUCT GAP
- what should be fixed in the product or website
```

## Examples of Good Recommendations

- "The right fix is a billing portal, not a custom dashboard yet"
- "This looks like duplicate personal checkout, not a real team-seat purchase"
- "Refund one duplicate charge, keep the remaining active subscription, then convert the customer to org billing later if needed"

すべてのファイル

1件のファイル

customer-billing-opsをインストール

スキルファイルをダウンロードし、.claude/skills/ ディレクトリに解凍してください。

ZIPをダウンロード

リポジトリをクローンし、スキルファイルをプロジェクトにコピーしてください。

git clone https://github.com/affaan-m/ECC/tree/main/skills/customer-billing-ops # Copy SKILL.md to your .claude/skills/ directory

コピー コピー
クイックセットアップ: スキルフォルダを .claude/skills/ にコピーしてください。 Claude が自動的にそのスキルを検出して使用します。
リポジトリ affaan-m/ECC

関連スキル

v4-new-features
更新された時間 2026年8月4日
multica-creating-agents
更新された時間 2026年8月12日
pixijs-application
更新された時間 2026年8月4日
tilemaps
更新された時間 2026年8月4日
OR