일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 |
- terraform
- 생성 패턴
- MAPF
- leetcode
- study
- 신혼 여행
- 실용주의 프로그래머
- Playwright
- amazon ecs
- PostgreSQL
- 디자인 패턴
- 청첩장 모임
- 티스토리챌린지
- 경로 계획 알고리즘
- Til
- 오블완
- AWS 비용 절감
- docker
- Go-lang
- Monthly Checklist
- github
- 논문 정리
- ssh
- 지표
- 구조 패턴
- 도커 주의사항
- Rust
- DevOps
- AWS
- 14일 공부
- Today
- Total
밤 늦게까지 여는 카페
제품이 잘 개발/운영되고 있는지 어떻게 판단할까? #2 - 사업 활동에 비추어 지표 활용해보기 본문
안녕하세요. 어느덧 봄이 다가왔는지 최고 기온이 18도까지도 올라가네요 ㄷㄷㄷ
그래서 달력을 보니 3월 중순... 2024년도 벌써 1/4가 지나가고 있습니다.
지난 3개월을 되돌아보면 허투루 보낸 것은 아닌지 기억에 남는 일들이 많습니다.
기억에 남는 일들을 중심으로 3개월을 되돌아보니 그때의 추억과 감정들이 훨씬 깊게 느껴집니다.
이때 '서비스 지표도 큼지막한 이벤트와 주기적으로 반복되는 이벤트들을 평가하면 좋겠다'는 생각이 머리에 스쳤습니다.
이번에는 특정 상황들을 예시를 들고, 저번에 조사한 서비스 지표들을 사용하면서 이야기를 전개해보겠습니다!
1. 신규 고객 확보에 어려움을 겪는 상황
가상의 회사 "밤 늦게까지 여는 카페"가 신규 고객 확보에 어려움을 겪고 있습니다.
저희들은 분기 별로 지표를 검토하는데, 검토하면서 고객 확보 비용(CAC)이 너무 높은 것을 발견하게 되었습니다.
무엇이 CAC를 높게 만들었는지 살펴보니 전환율(CVR)이 낮았습니다.
- Bounce Rate가 높은 상황이라고 볼 수도 있는 것 같습니다.
고객들에게 제품 판매를 제안하면서 사용하는 영업비는 합리적인 금액이었습니다. 다만, CVR이 너무 낮아서 상대적으로 영업비가 많이 지출되고 있는 것이었습니다.
그러면 CVR이 왜 낮은 것인지 알아봐야겠죠?
제품 판매 제안서를 보니 숫자가 없습니다. Return On Investment(ROI), 제품의 리스크와 같은 비용과 관련된 자료가 부족한 것입니다.
ROI, 리스크 분석이 부족했던 이유는 이들을 계산할 수 있는 서비스 지표가 제대로 관리되지 않고 있기 때문이었습니다.
그래서 판매 제안이 있을 때마다 매번 수치를 계산하느라 시간은 많이 할애하지만 신뢰성 부족한 수치로 충분한 설득력을 갖추지 못했습니다.
- 현금 지출로 명시되지 않는 인적 비용도 발견했습니다 ㅜ
이번 분석을 바탕으로 서비스 지표가 CAC에 어떤 영향을 주었는지, 당장 필요한 서비스 지표가 무엇인지 알 수 있었습니다.
조금 더 멋진 "밤 늦게까지 여는 카페"를 만들어 보겠습니다!
2. 기존 고객이 이탈하는 상황
"밤 늦게까지 여는 카페"의 CAC는 낮아졌지만 또 다른 문제가 발생했습니다. 바로 이탈률(CR)이 높아진 것이죠...
바로 서비스 지표들을 살펴봤죠!
서비스의 신뢰성을 보여주는 평균 무장애 시간(MTBF), 가용성, 평균 장애 대응 시간(MTTR)들은 낮았습니다.
'제품의 안정성 문제는 아니군' 하면서 VoC를 너무 무시했나? 하고 봤는데 그렇지도 않더라고요.
도무지 모르겠어서 고객 만족도와 충성도를 보여주는 Net Promoter Score(NPS)를 측정했습니다.
다행히 0 이상이었지만 수동적 고객 비중이 너무 컸습니다.
- 언제든지 적대적 고객으로 돌아서거나 제품을 떠날 수 있는 고객 비중이 큰 상황입니다.
- 저희들은 수동적 고객들을 충성 고객으로 전환하여 안정적인 연간 반복 매출(ARR)을 만들어야 합니다.
한달 동안 수동적 고객들의 제품 사용을 집중적으로 분석했더니 놀라운 점을 발견했습니다.
제품 사용 중에 문제가 발생하더라도 저희들에게 알리지 않고 적당히 넘어가는 것이었죠.
문제가 공유되는 것은 극히 일부분이었기에 MTBF, MTTR에 문제가 없었던 것이었습니다 ㅜㅠ
저희들은 제품의 문제 발생을 보다 빨리 식별할 수 있도록 모니터링 시스템을 개선했고, 문제가 발생한 것을 고객들보다 빠르게 인지하고 조치할 수 있게 되었습니다.
적극적인 모니터링에 감동 받은 일부 수동적 고객들이 충성 고객으로 돌아서게 되었습니다!
지표들을 사용해서 나름의 스토리를 만들어 봤는데 머리에 쏙쏙 박히는지 모르겠네요 ㅋㅋㅋ...
P.S.
이번 글을 작성하는데 풀스택 B2B 세일즈 플랫폼을 제공하는 relate의 SaaS 영업에 관한 아티클이 정말 큰 도움이 되었습니다.
SaaS 영업에 관심 있으시면 읽어보는 것을 추천드려요!
'DevOps' 카테고리의 다른 글
제품이 잘 개발/운영되고 있는지 어떻게 판단할까? #4 - 서버 성능 모니터링을 위한 RED 방법론 (0) | 2024.03.27 |
---|---|
제품이 잘 개발/운영되고 있는지 어떻게 판단할까? #3 - 서버 성능 모니터링을 위한 USE 방법론 (0) | 2024.03.25 |
제품이 잘 개발/운영되고 있는지 어떻게 판단할까? #1 - 무작정 지표 조사하기 (0) | 2024.03.14 |
시맨틱 버저닝 pre-release & build metadata - "-", "+"에 의미가 있는 줄은 몰랐네요 ㄷㄷ (0) | 2023.08.13 |
terraform 리뷰 - terraform 진짜 쓸만한가...? (0) | 2022.11.20 |