고객 청구 운영은(는) 무엇을 하나요?
이 스킬은 제네릭 결제 API 설계가 아닌 실제 고객 운영을 위해 사용하세요.
목표는 운영자가 다음 질문에 답변할 수 있도록 돕는 것입니다: 이 고객은 누구인가, 무슨 일이 있었는가, 가장 안전한 해결책은 무엇인가, 그리고 어떤 후속 조치를 보내야 하는가?
사용 시기
- 고객이 청구가 고장 났다고 말하거나, 환불을 원하거나, 취소할 수 없을 때
- 중복 구독, 우발적 요금 청구, 갱신 실패, 이탈 위험을 조사할 때
- 요금제 구성, 활성 구독, 연간/월간 전환, 팀 시트 혼란을 검토할 때
- 청구 포털 플로우를 만들거나 검증할 때
- 구독, 송장, 환불 또는 결제 방법에 관련된 지원 불만을 감사할 때
선호 도구 표면
- 먼저 Stripe와 같은 연결된 청구 도구를 사용하세요
- 이메일, GitHub 또는 이슈 트래커는 보조 증거로만 사용하세요
- 플랫폼이 필요한 컨트롤을 이미 제공하는 경우, 커스텀 계정 관리 코드보다 호스팅된 청구/고객 포털을 선호하세요
가드레일
- 응답에 비밀 키, 전체 카드 세부 정보 또는 불필요한 고객 PII를 절대 노출하지 마세요
- 맹목적으로 환불하지 말고 먼저 문제를 분류하세요
- 다음을 구분하세요:
- 실수로 인한 중복 구매
- 의도적인 멀티 시트 또는 팀 구매
- 제품 결함 / 충족되지 않은 가치
- 실패했거나 완료되지 않은 체크아웃
- 셀프 서비스 컨트롤 부족으로 인한 취소
- 연간 요금제, 팀 요금제 및 비례 배분 상태의 경우 계약 형태를 확인한 후 조치를 취하세요
워크플로
1. 고객을 명확히 식별하세요
가장 강력한 식별자부터 시작하세요:
- 고객 이메일
- Stripe 고객 ID
- 구독 ID
- 송장 ID
- 청구에 매핑되는 것으로 알려진 GitHub 사용자 이름 또는 지원 이메일
간결한 신원 요약을 반환하세요:
- 고객
- 활성 구독
- 취소된 구독
- 송장
- 중복 활성 구독과 같은 명백한 이상 징후
2. 문제를 분류하세요
조치를 취하기 전에 사례를 하나의 버킷에 넣으세요:
| 사례 | 일반적인 조치 |
|---|---|
| 개인 구독 중복 | 추가 구독 취소, 환불 고려 |
| 실제 멀티 시트/팀 의도 | 시트 유지, 청구 모델 명확화 |
| 결제 실패 / 완료되지 않은 체크아웃 | 포털을 통해 복구 또는 결제 방법 업데이트 |
| 셀프 서비스 컨트롤 부족 | 포털, 취소 경로 또는 송장 접근 제공 |
| 제품 결함 또는 신뢰 손상 | 환불, 사과, 제품 문제 기록 |
3. 가장 안전한 되돌릴 수 있는 조치를 먼저 취하세요
선호 순서:
- 셀프 서비스 관리 복원
- 중복되거나 깨진 청구 상태 수정
- 영향을 받은 요금 또는 중복에 대해서만 환불
- 이유 문서화
- 짧은 고객 후속 조치 전송
수정에 제품 작업이 필요한 경우 분리하세요:
- 지금 고객 문제 해결
- 백로그를 위한 제품 버그 / 워크플로 격차
4. 운영자 측 제품 격차 확인
고객 불편이 운영자 표면의 부재로 인해 발생한 경우 명시적으로 지적하세요. 일반적인 예:
- 청구 포털 없음
- 사용량/속도 제한 가시성 없음
- 요금제/시트 설명 없음
- 취소 플로우 없음
- 중복 구독 방지 없음
이러한 항목을 단순한 지원 인시던트가 아닌 ECC 또는 웹사이트 후속 항목으로 처리하세요.
5. 운영자 인수인계서 작성
다음과 같이 끝내세요:
- 고객 상태 요약
- 취한 조치
- 수익 영향
- 보낼 후속 텍스트
- 생성할 제품 또는 백로그 이슈
출력 형식
이 구조를 사용하세요:
고객
- 이름 / 이메일
- 관련 계정 식별자
청구 상태
- 활성 구독
- 송장 또는 갱신 상태
- 이상 징후
결정
- 문제 분류
- 이 조치가 올바른 이유
취한 조치
- 환불 / 취소 / 포털 / 무조치
후속 조치
- 짧은 고객 메시지
제품 격차
- 제품 또는 웹사이트에서 수정해야 할 사항
좋은 권장 사항 예시
- "올바른 수정 방법은 아직 커스텀 대시보드가 아닌 청구 포털입니다"
- "이것은 실제 팀 시트 구매가 아닌 개인 체크아웃 중복으로 보입니다"
- "중복 요금 하나를 환불하고 나머지 활성 구독은 유지한 후, 필요시 나중에 고객을 조직 청구로 전환하세요"