SaaS 매출 위험 분석 워크플로를 만들었습니다 — 실제 데이터로 시험할 창업자 2명을 찾습니다

AI 요약

인도에서 컴퓨터과학을 공부하는 Suraj Rajput은 SaaS 고객 이탈이 해지로 드러나기 전에 위험 신호를 찾는 분석 워크플로를 만들었습니다. 통제된 B2B SaaS 데이터에는 계정 2,000개, 기능 사용 이벤트 235만 건, 지원 티켓, 구독 기록이 포함됩니다. 작성자는 분석 결과를 보여주는 데 그치지 않고, 계정별 위험을 검토하는 CS 팀의 업무 흐름까지 구성했습니다.

분석에서 찾은 매출 위험

2024년 1월 신규 MRR(New MRR)은 55,990달러였지만, 이탈 MRR(Churned MRR)이 71,840달러로 더 컸습니다. 그 결과 순신규 MRR(Net New MRR)은 852달러에 그쳤습니다. 총 MRR만 보면 성장세가 유지되는 것처럼 보여도, 신규 매출을 이탈이 거의 상쇄할 수 있다는 사례입니다.

관찰된 로고 이탈률은 Enterprise 계정 13.88%, Basic 계정 10.58%였습니다. 작성자는 사용량 감소를 엄격한 기준으로 선별해 현재 활성 상태인 계정 78개를 표시했습니다. 이 계정들의 현재 MRR 노출액은 411,801달러이며, 그중 Enterprise 계정 22개의 비중은 315,767달러입니다. 이 수치는 미래 이탈을 확정적으로 예측한 결과가 아니라, 현재 검토할 계정 목록으로 제시됐습니다.

SSO와 Webhook을 도입한 계정에서는 관찰된 이탈률이 낮았습니다. 작성자는 이를 기능이 고객 유지율을 높인다는 증거로 보지 않고, 추가 검증이 필요한 가설로 한정했습니다. 댓글에서도 기능 도입과 낮은 이탈률이 함께 나타나는 이유가 고객의 도입 의지, 예산 승인, 계약 규모 같은 제3의 요인일 수 있다는 지적이 나왔습니다.

규칙 기반 목록과 이탈 모델

워크플로에는 현재 사용량 감소 계정을 표시하는 규칙 기반 목록과, 미래 이탈 위험을 추정하는 모델이 따로 있습니다. 댓글에서 작성자는 모델 입력으로 최근 활성 일수와 사용 이벤트, 지원 티켓 수, CSAT, 해결 시간, 계정 연령, 요금제, 업종, 유입 경로, 초기 SSO·Webhook 도입 여부를 언급했습니다. 시간 정보가 미래 데이터를 새어 들어오게 하지 않도록 과거 90일 지원 기록과 과거 30일 사용량을 특징으로 삼고, 이후 60일 이탈을 예측 대상으로 설정했다고 설명했습니다.

분석과 모델링에는 SQL과 DuckDB, Python과 scikit-learn을 사용했습니다. Streamlit 앱에서는 계정 하나를 점수화하거나 CSV에 담긴 여러 계정을 순위화합니다. 작성자는 파일 기반 데이터를 빠르게 분석하고 결과를 노트북 없이 작은 팀에 전달하기 위해 가벼운 구성을 택했다고 밝혔습니다.

실제 팀에서 검증할 기준

작성자는 초기 B2B SaaS 팀 두 곳을 대상으로 파일럿을 찾습니다. 첫 팀은 솔직한 피드백을 조건으로 무료이며, 두 번째 팀에는 3일짜리 Revenue Leak Diagnostic을 99달러에 제공합니다. 진단에는 데이터 품질과 지표 정의 점검, MRR 변동과 이탈 관찰, 집중 분석 1~2건, 사용 데이터가 있을 때의 사용량 감소 검토, 우선순위를 담은 짧은 실행 메모가 포함됩니다. 데이터가 뒷받침되면 계정별 검토 목록도 제공합니다. 실제 분석 전에는 각 회사와 ‘활성’, ‘이탈’, ‘위험’의 정의부터 합의하겠다고 밝혔습니다.

댓글에서는 모델 정확도만 평가하지 말고, 경고가 실제 CS 대응을 바꾸는지 확인하라는 의견이 반복됐습니다. 계정별로 팀이 이미 알고 있던 내용, 워크플로가 새로 발견한 신호, 실제로 취한 조치, 신호가 충분히 일찍 도착했는지를 기록하자는 제안입니다. 단순 사용량 감소 규칙과 모델을 비교해 복잡성을 더할 가치가 있는지도 확인해야 합니다. 한 댓글은 모델 점수를 보여주기 전에 CS 팀이 계정을 ‘건강’, ‘관찰’, ‘위험’으로 분류하는 블라인드 검토를 제안했습니다.

작성자는 파일럿에서 기존 판단과 조치를 기록하고, 간단한 규칙과 모델을 비교하며, 결과가 실제 유지 조치로 이어졌는지 확인하겠다고 답했습니다. 기업 고객을 대상으로 한 검증은 아직 없으며, 첫 파일럿을 통해 지표 정의와 데이터 처리, 현업에서의 활용성을 확인하려는 단계입니다.

Indie Hackers 반응

• @wproch — 두 명의 창업자를 대상으로 파일럿을 제안한 방식이 좋습니다. 워크플로의 각 단계에 신호, 기준값, 조치, 결과를 간단히 기록하세요. 그러면 유용한 조기 경보와 잡음이 많은 점수를 구분하기 쉽습니다. 지금까지 어떤 입력값이 가장 예측력이 높았나요?
• @ersan — 위험 점수가 이탈을 얼마나 정확히 예측하는지보다, 그 점수가 의사결정을 얼마나 바꾸는지 시험하는 부분이 가장 궁금합니다. SSO와 Webhook 결과를 인과관계의 증거가 아니라 유지율 가설이라고 조심스럽게 표현한 점도 좋습니다. 사용량 감소의 정의나 관찰 기간을 조금 바꿨을 때 위험 계정 78개 목록이 얼마나 안정적인지도 궁금합니다. 가정이 조금만 달라져도 목록이 크게 바뀐다면 운영에 쓰기 어렵습니다.
• @justinbobby718 — SSO와 Webhook 도입을 유지율의 증거가 아니라 가설로 다룬 판단이 맞습니다. 1월 순신규 MRR 하락은 신규 매출을 이탈 MRR이 상쇄한 결과가 대부분입니다. 두 번째 데이터셋에서 사용량 감소 기준이 표시한 78개 계정을 시험하는 부분이 가장 가치 있어 보입니다.
  • @Suraj Rajput — 동의합니다. SSO와 Webhook은 가설로 다루고, 주요 결론으로 내세우지 않겠습니다. 첫 파일럿에서는 사용량 감소 목록이 두 번째 데이터셋에서도 검토할 계정을 찾아내는지, CS의 대응을 바꾸는지 보겠습니다. 데이터 하나로 모델을 증명하려 하기보다 그쪽이 더 유용한 검증이라고 생각합니다.
• @mehdizare — 첫 파일럿은 모델 정확도 시험이 아니라 의사결정 시험으로 설계하겠습니다. 표시된 계정마다 팀이 어떤 조치를 취할지, 신호가 충분히 일찍 왔는지, 어떤 추가 데이터가 판단을 바꿨을지 기록하세요. 복잡한 모델을 도입하기 전에 간단한 규칙과 비교할 기준도 생깁니다.
  • @Suraj Rajput — 동의합니다. 파일럿에서는 CS 팀이 이미 알고 있던 내용, 취할 조치, 신호가 충분히 일찍 왔는지, 워크플로가 무엇을 더했는지 기록하겠습니다. 간단한 사용량 감소 규칙과도 비교하겠습니다. 모델이 판단을 바꾸지 않는다면 더 단순한 워크플로를 유지하고 싶습니다.
• @AmandaBrown — SSO와 Webhook 관찰은 흥미롭지만, 기능 도입과 유지율은 보통 고객이 제품을 얼마나 진지하게 다루는지를 함께 반영합니다. SSO 도입에는 IT 부서의 판단과 예산 승인이 따르므로, 해당 고객은 SSO를 쓰지 않았더라도 이탈률이 낮았을 수 있습니다. 초기 창업자에게 더 실행 가능한 분석은 오래 남고 많이 사용한 고객 10%와 이탈 고객이 첫 30일 동안 어떻게 달랐는지 비교하는 것입니다. 사용량 감소 목록은 이탈이 발생하기 전에 연락할 계정을 찾는 데 유용합니다. 50개 이상의 유료 계정과 사용 데이터를 갖춘 팀을 파일럿 대상으로 삼는 편이 좋겠습니다.
  • @Suraj Rajput — 맞습니다. SSO와 Webhook 결과를 유지율을 높이는 요인으로 과하게 해석했습니다. 이제 유지율 가설로 다루겠습니다. 최고 고객과 이탈 고객의 첫 30일을 비교하는 방식도 초기 팀에 더 간단하고 실행 가능해 보입니다. 첫 파일럿은 유료 계정이 대략 50개 이상이고 제품 사용 데이터가 있는 회사를 대상으로 찾겠습니다. Enterprise 22개 계정과 315,767달러는 예측치가 아니라 현재 검토 목록입니다.
• @tristanlefler — 표시된 계정 중 20~30개를 뽑아 블라인드 검토를 해보세요. CS가 모델 점수를 보기 전에 계정을 ‘건강’, ‘관찰’, ‘위험’으로 분류한 뒤 세그먼트별 정밀도를 비교하면 신뢰를 쌓는 기준이 생깁니다. 실제 유지 조치가 바뀌는지도 확인할 수 있습니다.
  • @Suraj Rajput — 좋은 제안입니다. 점수를 보여주기 전에 CS가 계정 표본을 분류하는 단계를 추가하겠습니다. 기존 판단과 간단한 사용량 감소 규칙에 모델을 비교하고, 출력이 실제 유지 조치를 바꾸는지도 기록하겠습니다.
• @kimkklhjyuxbhkzhqyp — 이 작업에서 가장 맞추기 어려웠던 부분은 무엇이었나요?
  • @Suraj Rajput — 미래 정보가 모델 입력에 섞이지 않도록 시간 구간을 정의하는 일이 가장 어려웠습니다. 과거 분석과 예측을 분리해 과거 90일 지원 기록과 과거 30일 사용량을 특징으로 삼고, 이후 60일 이탈을 예측 대상으로 설정했습니다. 결과를 점수로만 보여주지 않고 CS 검토 목록으로 만드는 일도 과제였습니다.
• @aryan_sinh — 두 파일럿에서 어떤 결과가 나와야 사업성을 검증했다고 볼 수 있나요? 위험 계정을 정확히 찾는 것, 유지 결정을 바꾸는 것, 창업자가 비용을 내고 진단을 다시 받는 것 중 무엇인가요?
  • @Suraj Rajput — 세 가지를 모두 보되 순서를 두겠습니다. 먼저 지표 정의에 합의했는지, 다음으로 경고가 실제 유지 조치를 바꿨는지, 마지막으로 창업자가 진단을 반복하거나 비용을 낼 만큼 가치를 느꼈는지 확인하겠습니다. 모델 정확도만으로 사업성을 판단하지는 않겠습니다.
• @mattmag — 파일럿의 가치는 지표 정의를 합의한 뒤 경고가 실제 CS 조치를 바꾸는지 확인하는 데 있을 수 있습니다. 표시된 계정마다 팀이 이미 알고 있던 내용, 취한 조치, 계정의 이후 결과를 기록하세요. 간단한 규칙과 모델도 비교해 복잡성을 더할 가치가 있는지 확인하면 좋겠습니다.
  • @Suraj Rajput — 좋은 시험 방법입니다. 팀이 이미 위험하다고 보는 계정을 먼저 하나 고르게 한 뒤, 그 사례에 맞춰 조정하지 않고 워크플로를 실행해 보겠습니다. 팀이 알고 있던 내용과 워크플로가 더한 내용, 이후 조치를 기록하겠습니다. 그러면 유용한 신호와 사후 해석을 구분하는 데 도움이 됩니다.
• @loveoftheai — 두 번째 데이터셋으로 시험하는 데 참여할 수 있습니다. SaaS 로고는 아니지만 실제 매출과 전환 퍼널 데이터가 있습니다. 창업자에게 연락하기 전에 사용량 감소 기준이 2024년 데이터에서 해지 며칠 전에 작동했는지 답할 필요가 있습니다. 경고가 해지 30일 전에 오면 대응할 시간이 있지만, 3일 전에 오면 사후 분석에 가깝습니다. 제품 가치는 경고 시점에 달려 있습니다.
• @WorkForce2020 — 위험을 찾는 것과 팀의 대응을 바꾸는 것은 다릅니다. 계정에 연락하거나 온보딩을 바꾸고, 사용량을 조사하거나 신호가 약해 개입하지 않기로 하는 등 결과가 실제 판단을 바꿀 때 워크플로가 성공했다고 보는 편이 좋겠습니다. 단순 규칙과 모델이 같은 대응을 이끌어낸다면 작은 SaaS 팀에는 유지하기 쉬운 단순한 방식이 더 나을 수 있습니다.
  • @Suraj Rajput — 동의합니다. 팀이 이미 알던 내용과 워크플로가 더한 정보, 바뀐 조치, 단순 사용량 감소 규칙으로 충분했는지를 기록하겠습니다. 간단한 규칙이 같은 유용한 판단을 이끌어내면 작은 SaaS 팀에는 더 단순한 방식을 택하겠습니다. 복잡성은 쓸모를 증명해야 합니다.

원문: Indie Hackers / 번역·요약: Trawling