customer-billing-ops
affaan-m/ECC
Stripe와 같은 연동된 청구 도구를 활용하여 구독, 환불, 이탈 고객 선별, 청구 포털 복구, 요금제 분석 등의 고객 청구 워크플로를 운영합니다.
...모든 것을 확장하십시오고객 청구 운영
이 기술은 일반적인 결제 API 설계가 아닌, 실제 고객 운영 업무에 활용하십시오.
이 스킬의 목표는 운영자가 ‘이 고객은 누구인가, 무슨 일이 발생했는가, 가장 안전한 해결책은 무엇인가, 어떤 후속 조치를 취해야 하는가’라는 질문에 답할 수 있도록 돕는 것입니다.
사용 시점
- 고객이 청구 오류가 발생했다고 말하거나, 환불을 요청하거나, 구독을 해지할 수 없다고 할 때
- 중복 구독, 실수로 발생한 청구, 갱신 실패 또는 이탈 위험 조사 시
- 요금제 구성, 활성 구독, 연간 대비 월간 전환율, 팀 라이선스 관련 혼란을 검토할 때
- 청구 포털 절차 수립 또는 검증 시
- 구독, 청구서, 환불 또는 결제 수단과 관련된 지원 불만 사항 감사
권장 도구: Surface
- Stripe와 같은 연동된 청구 도구를 우선적으로 사용하십시오
- 이메일, GitHub 또는 이슈 트래커는 보조 증거로만 활용하십시오
- 플랫폼에서 필요한 제어 기능을 이미 제공하는 경우, 맞춤형 계정 관리 코드보다 호스팅형 청구/고객 포털을 우선적으로 사용하십시오
안전 장치
- 응답에 비밀 키, 전체 카드 정보 또는 불필요한 고객 개인 식별 정보(PII)를 절대 노출하지 마십시오
- 무분별하게 환불하지 말고, 먼저 문제를 분류하십시오
- 다음 사항을 구분하십시오:
- 실수로 인한 중복 구매
- 의도적인 다중 라이선스 또는 팀 구매
- 제품 결함 / 기대 가치 미달
- 결제 실패 또는 미완료
- 셀프 서비스 제어 기능 미비로 인한 취소
- 연간 요금제, 팀 요금제 및 일할 계산 상태의 경우, 조치를 취하기 전에 계약 형태를 확인하십시오
워크플로우
1. 고객을 명확하게 식별하십시오
사용 가능한 가장 확실한 식별자부터 시작하십시오:
- 고객 이메일
- Stripe 고객 ID
- 구독 ID
- 청구서 ID
- GitHub 사용자 이름 또는 청구 정보와 연결되는 것으로 확인된 지원 이메일
간결한 신원 정보를 요약하여 반환합니다:
- 고객
- 활성 구독
- 해지된 구독
- 청구서
- 중복된 활성 구독과 같은 명백한 이상 현상
2. 문제 분류
조치를 취하기 전에 해당 사례를 다음 중 하나의 범주에 분류하십시오:
| 사례 | 일반적인 조치 |
|---|---|
| 개인 구독 중복 | 추가 항목 취소, 환불 검토 |
| 실제 다중 사용자/팀 이용 의도 | 좌석 유지, 청구 모델 명확히 설명 |
| 결제 실패 / 결제 절차 미완료 | 포털을 통해 복구하거나 결제 수단 업데이트 |
| 셀프 서비스 제어 기능 미비 | 포털, 취소 절차 또는 청구서 조회 기능 제공 |
| 제품 오류 또는 신뢰 훼손 | 환불, 사과, 제품 문제 기록 |
3. 가장 안전하고 되돌릴 수 있는 조치를 먼저 취하십시오
권장 순서:
- 셀프 서비스 관리 기능 복원
- 중복되거나 오류가 발생한 청구 상태 수정
- 영향을 받은 청구 내역 또는 중복 청구분에 대해서만 환불
- 사유를 기록하십시오
- 고객에게 간단한 후속 조치 알림 발송
해결을 위해 제품 관련 작업이 필요한 경우, 다음을 별도로 처리하십시오:
- 즉시 고객 문제 해결
- 백로그에 포함할 제품 버그/워크플로우 결함
4. 운영자 측 제품상의 미비 사항 확인
고객의 불편이 운영자 인터페이스 미비에서 비롯된 경우, 이를 명확히 지적하십시오. 일반적인 예시:
- 청구 포털 미비
- 사용량/속도 제한 현황 확인 불가
- 요금제/사용권 설명 부재
- 해지 절차 미비
- 중복 구독 방지 기능 부재
이러한 사항들을 단순한 지원 사례가 아닌 ECC 또는 웹사이트 후속 조치 항목으로 처리하십시오.
5. 운영자 인계 절차 수립
다음 내용으로 마무리하십시오:
- 고객 상태 요약
- 취해진 조치
- 매출에 미치는 영향
- 전달할 후속 조치 내용
- 생성할 제품 또는 백로그 이슈
출력 형식
다음 구조를 사용하십시오:
고객
- 이름 / 이메일
- 관련 계정 식별자
청구 상태
- 활성 구독
- 청구서 또는 갱신 상태
- 이상 징후
결정
- 문제 분류
- 해당 조치가 올바른 이유
취해진 조치
- 환불 / 취소 / 포털 / 조치 없음
후속 조치
- 고객에게 보내는 간단한 메시지
제품 개선 사항
- 제품 또는 웹사이트에서 수정해야 할 사항
좋은 권장 사항의 예
- "올바른 해결책은 아직 맞춤형 대시보드가 아닌 청구 포털입니다"
- "이는 실제 팀 라이선스 구매가 아닌, 개인 결제 중복으로 보입니다"
- "중복 청구된 금액 중 하나는 환불하고, 나머지 구독은 활성 상태로 유지한 뒤, 필요 시 나중에 고객을 조직 청구 방식으로 전환하세요"
---
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
복사





집
