customer-billing-ops

name	customer-billing-ops
description	Stripe 같은 연결된 결제 도구를 사용해 구독, 환불, churn triage, billing-portal 복구, 요금제 분석 같은 고객 결제 워크플로를 운영합니다. 고객 지원, 구독 상태 점검, 매출에 영향을 주는 결제 운영이 필요할 때 사용합니다.
origin	ECC

Customer Billing Ops

이 스킬은 일반적인 결제 API 설계가 아니라 실제 고객 운영을 위한 스킬입니다.

목표는 운영자가 다음 질문에 답하게 돕는 것입니다. 이 고객은 누구인가, 무슨 일이 일어났는가, 가장 안전한 수정은 무엇인가, 어떤 후속 메시지를 보내야 하는가.

사용 시점

• 고객이 결제가 깨졌다고 하거나, 환불을 원하거나, 해지할 수 없다고 할 때
• 중복 구독, 실수 청구, 결제 실패, churn risk를 조사할 때
• 요금제 믹스, 활성 구독, 연간/월간 전환, 팀 좌석 혼동을 검토할 때
• billing portal 흐름을 만들거나 검증할 때
• 구독, 인보이스, 환불, 결제 수단과 관련된 지원 불만을 감사할 때

선호 도구 표면

• 먼저 Stripe 같은 연결된 결제 도구를 사용합니다
• 이메일, GitHub, 이슈 트래커는 보조 근거로만 사용합니다
• 플랫폼이 필요한 제어를 이미 제공하면 커스텀 관리 코드보다 hosted billing/customer portal을 우선합니다

가드레일

• 비밀 키, 전체 카드 정보, 불필요한 고객 PII를 노출하지 않습니다
• 무작정 환불하지 말고 먼저 이슈를 분류합니다
• 다음을 구분합니다
  • accidental duplicate purchase
  • deliberate multi-seat or team purchase
  • broken product / unmet value
  • failed or incomplete checkout
  • cancellation due to missing self-serve controls
• 연간 플랜, 팀 플랜, prorated 상태는 조치 전에 계약 형태를 확인합니다

워크플로

1. 고객 식별

가능한 가장 강한 식별자부터 시작합니다.

• customer email
• Stripe customer ID
• subscription ID
• invoice ID
• 결제와 매핑되는 GitHub username 또는 support email

다음을 간결히 요약해 반환합니다.

• customer
• active subscriptions
• canceled subscriptions
• invoices
• obvious anomalies

2. 이슈 분류

조치 전에 케이스를 한 버킷에 넣습니다.

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. 가장 안전하고 되돌릴 수 있는 조치부터

권장 순서:

1. self-serve 관리 복구
2. 중복 또는 깨진 billing 상태 수정
3. 영향을 받은 청구나 중복 청구만 환불
4. 이유 문서화
5. 짧은 고객 후속 메시지 발송

수정에 제품 작업이 필요하면 다음을 분리합니다.

• 지금 필요한 고객 remediation
• backlog에 넣을 product bug / workflow gap

4. 운영자 측 제품 격차 점검

고객 불편이 operator surface 부족에서 온 것이라면 명시적으로 지적합니다.

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

이것들은 단순 지원 이슈가 아니라 제품 후속 작업으로 취급합니다.

5. 운영자 handoff 생성

다음으로 마무리합니다.

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

출력 형식

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

좋은 권고 예시

• "정답은 커스텀 대시보드가 아니라 billing portal이다"
• "이건 실제 팀 좌석 구매가 아니라 개인용 중복 checkout으로 보인다"
• "중복 청구 하나만 환불하고, 활성 구독은 유지한 뒤, 나중에 org billing으로 전환한다"