똑똑한 고객 온보딩하기

초기 B2B 스타트업을 느리게 만드는 것 중 하나는 유형, 시기 등을 가리지 않고 모든 고객을 데려오는 일이다. 일단 매출부터 만들어야 하니까, 그리고 일단 뭐가 됐든 간에 사용할 사람이 필요하니까.

처음에는 우리도 ICP(Ideal Customer Profile)에 전혀 맞지 않더라도 고객으로 데려오기도 했었다. 고객 1명이 아쉬웠던 때였으니까. 하지만 정말 아무나 데려와서 우리 제품을 쓰게 하면 제품의 발전 속도가 그만큼 느려진다는 것을 깨달았다.

초기 스타트업의 제1의 목표는 무조건 '배움'에 있다. 초기에는 뭘 해도 배우는 것이 먼저다. 왜 고객들이 우리 제품을 고용하는 것인가? 우리 제품을 어떻게 알게 되었고, 우리 제품을 도입해서 사용하는 데 주로 쓰는 기능에는 무엇이 있고 아예 손도 대지 않은 기능은 없는가를 끊임없이 분석하고 고민해야 한다.

그런데 이때 우리가 serve 하려는 ICP가 아닌 고객사가 있으면, 그 고객사의 사용패턴이나 피드백은 우리에게 큰 도움이 되지 않는다. 되려 엄청난 Noise로부터 Signal을 구별해야만 하는 스타트업 팀에 더 많은 Noise를 주는 것밖에 되지 않는다.

그렇다면, 우리 ICP는 어떻게 정의해야 하는가? 초기에는 "똑똑한" 고객을 먼저 선별해서 온보딩하는 것이다.

똑똑한 고객은 (거의) 바로 우리 제품의 존재 목적과 가치 제안을 이해하고 공감한다. 그래서 곧바로 돈을 낼 의향도 있고, 물어보지도 않았는데 팀에 제품의 방향과 필요한 기능에 대해 알려주려고 한다.

똑똑한 고객은 기본적으로 도와주지 않아도 우리 제품을 잘 쓸 수 있고, 우리 제품을 통해 문제를 해결하려는 의지가 다분하다.

똑똑한 고객은:

1. 매일 우리 제품을 사용하거나 또는 가장 이상적인 주기로 제품을 사용한다 (제품에 따라서 매일 사용할 수 없기도 하니까).

2. 우리 제품을 도입할 때 현재 제품 상태로도 큰 어려움 / 추가 기능 개발/구현 없이도 잘 세팅해서 사용할 수 있다.

3. 우리 팀에 "진짜" 피드백을 줄 수 있고, 그럴 의지가 있다.

4. 충분한 돈을 낼 의향이 있다.

반대로, 똑똑하지 않은 고객은:

1. 구독 후에 사용을 안 하게 되면 바로 얘기해서 취소하거나 환불받지 않고 잊어버리거나 뒤늦게 요청한다. 똑똑한 고객은 돈 관리도 철저하게 하므로 제품이 가치를 주지 않으면, 바로 조처를 하기 마련이다.

2. 코어 기능이 아닌 기능에 딸린 버그나 부족한 UX/UI 이슈를 (필요 이상으로) 중요하게 생각한다.

특히 1번 포인트의 경우, 구독 취소는 (churn) SaaS 제품에 있어서는 치명적인 이벤트이다. 살아남으려는 스타트업을 도우려는 친절한 고객이라면 제품이 마음에 들지 않아도, 문제를 해결해 주지 않아도 계속 구독을 유지해 줄 수도 있겠다.

하지만 앞서서 말했듯 초기에는 지속 가능한 비즈니스 모델을 구현하는 것보다도 '배움'이 먼저다. 오히려 장기적으로 보면 구독을 유지해 주는 것보다 취소하고, 왜 취소하게 되었는지 자세하게 알려주는 것이 스타트업에 더 많은 도움이 된다.

알지 못하는 것을 인정할 때 비로소 해결책이 보인다. 문제를 인정하는 것은 개선의 첫걸음이다.

"현실을 인정하세요. 그때 비로소 무언가를 해볼 수 있는 겁니다. 문제를 인정하는 것은 개선의 첫걸음입니다."

"Admit reality. That's when you can start doing something about it. Acknowledgement is first step to improvement."

– Jack McDonald 스탠포드 GSB 교수. 알토스벤처스 한킴(Han Kim)의 멘토

고객이 취소 및 환불 요청을 할 때는 왜 우리 제품이 가치를 더하지 못했는지에 대해 자세하게 알 기회이다. 냉철하게 우리 제품이 고객의 문제를 해결하지 못한 이유에 대해 알면, 그 문제를 해결할 수 있게 되기 때문이다.

2번 포인트의 경우, 물론 제품 어디에 있던 버그와 UX/UI 이슈는 제품 전반적으로 중요하게 챙겨야 할 사안이다. 그러나 코어 기능에 대한 검증을 위해 빠르게 움직이는 스타트업에 있어서 프로필 이미지를 추가하는 것이 안 된다는 등의 버그는 나중에 고쳐도 되는 이슈다.