들어가며
저는 팀스파르타 제품실에서, 교육 상품 탐색 및 결제까지, 고객의 전체적인 전환 여정을 담당하는 PM으로 일하고 있습니다.
우리 서비스의 주요 비즈니스 중 하나는 K-디지털 기초역량훈련(KDC) 인데요,
즉, 정부가 지원하는 국비 교육 강의를 판매하는 것인데요. 고객은 이 강의를 '내일배움카드'로 결제해야 합니다.
이처럼 국가 정책이 깊게 관여하는 사업이다 보니 고객에게도 정책에 대한 높은 이해도가 요구되는데요. 이러한 특수성은 전환 퍼널을 그로스하는데 굉장한 고민과 복잡성을 불러오는 요소 중 하나로 작용했습니다.
그래서, 오늘은 이 복잡한 조건 속에서 ‘고객의 불편’에 집중하여 문제를 해결하고, 나아가 비즈니스 임팩트를 내고자 했던 프로젝트에 대해 이야기 해보려고 합니다.
배경 — 특수한 상황에서 요구되는 것들
내일배움카드는 일종의 정부 바우처입니다. 카드 안에 지원금이 적립되어 있고, 국비 강의를 신청할 때 해당 카드로 결제를 진행하는 방식인데요. 나름 단순한 사용 방식으로 느껴질 수 있겠지만, 실제 데이터를 들여다보면 결제 과정에서 이탈하는 유저가 가장 많았어요.
다만, 결제 퍼널이 길고 복잡하다 보니 단편적인 데이터만으로는 핵심 문제를 정의하기 어렵다는 문제가 있었습니다.
- 내일배움카드로 결제해야 한다는 것을 몰랐던 것인지
- 내일배움카드가 없어서 이탈한 것인지
- 내일배움카드에 잔액이 부족했던 것인지
명확하게 문제를 정의하기 위해, 직접 고객을 만나 인터뷰와 UT를 진행했습니다. CX 팀으로 들어오는 문의 내용도 함께 분석했을 때, 아래와 같은 어려움을 겪는 고객이 특히 많았어요.
"내일배움카드로 결제했는데, 잔액이 없다고 떠요." "신청은 완료했는데, 아직 카드 수령 전이에요." "결제할 때 내일배움카드로 결제해야 하는지 몰랐어요."
즉, 결제 의지가 낮아 이탈하는 고객의 수는 적었고, 본인에게 요구되는 결제 조건과 방법을 모르는 것이 문제였습니다. 실제로 고객이 카드 정보를 직접 확인하려면 아래 과정을 거쳐야 합니다.
고용24 접속 → 개인 인증 → 마이페이지 → 국비지원현황 탭 → ...
여러 창구를 거쳐야 하고 인증까지 요구되는 과정이라, 강의를 듣기 위해 유입된 고객이 이 과정을 모두 주체적으로 완료하고 돌아올 것이라 기대하기는 어려웠어요.
솔루션 — 저희가 대신 조회해드릴게요
아이디어는 단순했습니다. "우리가 대신 고객의 카드 정보를 알려줄 수 없을까?"
단순해 보이는 하나의 아이디어는, 크게 두가지 질문으로 이어졌습니다.
- 기술적으로 가능한가?
- 고객이 실제로 필요로 하는가?
고객의 정보를 대신 알려주기 위해, 어떤 방식을 선택할 수 있는지부터 파악해야 했습니다. 유사한 서비스들의 구현 방식을 찾아보고, 여러 차례 PoC를 시도하면서 기술적 가능성을 먼저 확인했습니다.
이 때 의미있었던 부분은, 아이디어를 개발자 분께서 먼저 제안해 주시고, 기술적인 검토와 제안 과정에 매우 적극적으로 참여해 주셨다는 점인데요. 해당 과정에서, 동일한 이해도로 문제를 이해하고 바라보는 것이 얼마나 중요한 일인지 다시 한 번 느낄 수 있었습니다.
더불어, 개인 정보를 입력해서 카드 정보를 조회하는 경험을 고객이 신뢰하고 사용할지도 불확실했습니다. 고객이 해당 단계를 허들로 느끼지 않고, 도움이 되는 단계로 인지할 수 있도록 구성하고자 했습니다. 처음으로 고객이 해당 기능을 마주했을 때, 허들로 느끼지 않도록 세부적인 카피도 수차례 수정했어요.
이 프로젝트에서 가장 어려웠던 것은 바로 2가지, 이해관계자를 설득하는 것과 스콥을 적절히 정의하는 것이었어요.
설득 — 가능성을 함께 탐색하기
이 기능은 고객이 직접 정보를 입력하고, 조회 결과를 기다려야 하는 구조였습니다.
리드 타임이 길어지는 만큼, 오히려 결제 과정에서 이탈을 유발하는 것 아니냐는 우려가 있었는데요. 이는 마케팅팀과 CX팀에게 특히 민감하게 느껴질 수 있는 지점이었습니다.
이를 설득하기 위해,
- 유관 부서의 우려 사항을 함께 확인하고,
- 해당 경험이 고객에게 허들이 아닌 도움으로 인식되려면 어떤 조건이 필요한지,
실제 고객 문의 데이터와 인터뷰 내용을 함께 들여다 보며 논의했습니다. 그 과정에서 각 팀이 가진 사업과 고객에 대한 맥락을 수렴해 기획에 반영될 수 있었고, 실험 방향에 대한 공감대도 함께 만들어 갈 수 있었어요.
이 때, 고객 경험에 직접적으로 영향을 미치는 기능일수록, 유관 부서와의 소통은 초반부에 진행하자는 점을 배웠습니다. 일방적으로 설득하는 구조보다, 방향성을 함께 논의하는 방식이 결과적으로 더욱 빠르고 깊이 있는 솔루션으로 이어진다고 느꼈기 때문이에요.
스콥 정의 — 어디서 선을 그을 것인가
- 카드 상태와 유저 상태가 조합되면 굉장히 많은 케이스가 생겨납니다. 카드가 없는 사람, 있지만 잔액이 부족한 사람, 유효기간이 지난 사람, 발급 신청 중인 사람. 각 상태마다 보여줘야 할 정보와 안내가 상이해요.
- 모든 케이스를 커버하면 완성도는 높아지겠지만, 실험 속도는 늦어지고 개발 리소스도 커집니다. 결국 지금 해결해야 하는 문제에 집중하여 우선순위를 설정했습니다.
- 스콥을 좁히는 건 항상 아쉽습니다. 그래도 MVP의 목적은 "모든 케이스를 커버하는 것"이 아니라 "핵심 가설을 빠르게 검증하는 것"임을 다시 한 번 느낄 수 있었어요.
결과
서비스의 퍼널은, 자부담금 결제 - 수강 신청 - 최종 수강생 등록으로 구성되어 있습니다. 이 때, 지원금 사용에 요구되는 조건을 모두 충족해야만 최종 수강생 등록이 가능해요.
조회 기능 도입 이후, 자부담금 결제 완료율은 크게 변하지 않았으나, 최종 수강생 등록까지의 전환율과 같은 결제 이후 지표들이 유의미하게 개선된 것을 확인할 수 있었습니다.
이는, 필수 요건을 만족하지 못하고 결제를 완료했던 유저들이 감소했음을 의미하는데요. 이를 통해 조회 기능이 결제를 유도하는 게 아니라, 즉 준비된 고객이 결제하도록 도왔음을 알 수 있었습니다. 정성적으로도, CX팀으로 들어오던 내일배움카드 사용과 관련한 문의가 눈에 띄게 줄어든 것을 확인할 수 있었어요.
물론, 기능 배포 이후 서비스를 운영하면서 기획단계에서 예상하지 못했던 유저 케이스도 발견됐습니다.
하지만 프로젝트에 대한 팀의 높은 이해도 덕분에 발 빠르게 대응할 수 있었습니다. MVP를 빠르게 냈던 것이, 결국 더 좋은 제품을 만드는 데도 유효한 결정임을 느낄 수 있었습니다.
마치며
좋은 기능과 좋은 문제 정의는 고객의 목소리에서 온다는 것을 실감할 수 있었던 경험이었습니다.
Share article