| 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. 가장 안전하고 되돌릴 수 있는 조치부터
권장 순서:
- self-serve 관리 복구
- 중복 또는 깨진 billing 상태 수정
- 영향을 받은 청구나 중복 청구만 환불
- 이유 문서화
- 짧은 고객 후속 메시지 발송
수정에 제품 작업이 필요하면 다음을 분리합니다.
- 지금 필요한 고객 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으로 전환한다"
