오프라인 고객 경험 향상을 위한 전자계약 서비스
고가의 제품을 사는 만큼 그에 걸맞은 체계적인 전자계약 시스템 구축
고가의 브랜드는 프리미엄이란 타이틀을 달고 그에 상응하는 가격으로 제품과 서비스를 판매하곤 한다.
브랜드의 가치, 제품의 퀄리티, 오프라인 매장에서의 경험, 온라인 구매에서의 경험, 광고 등 소비자와 맞닿는 접점에서 본인들이 조작적으로 정의한 프리미엄을 나타내곤 한다.
프리미엄의 사전적 정의
(중략) 고급이라는 뜻이 있긴 하지만, 럭셔리와는 엄연히 다른 단어이다. (중략) 프리미엄은 시민 혁명 이후 귀족을 몰아내고 세력을 잡게 된 부르주아들이 귀족의 럭셔리를 동경해서 이를 모방한 끝에 나온 사치스러운 포스트 럭셔리를 프리미엄이라고 한다.
과연 영유아 영어 교육시장에서 프리미엄 브랜드란 어떤 것일까? 그리고 왜 영유아 영어 교육시장에서, 어떤 고객에게, 어떻게, 프리미엄 이미지를 전달해야 할까?
01. 고객과 브랜드의 접점 (When,
Where)
우선 우리는 고객이 우리 영유아 영어교육 브랜드와 만나는 접점을 체크해보았다.
접점은 크게 대면/ 비대면으로 나눌 수 있다.
온라인, 오프라인 마케팅 광고를 통한 비대면 접점, 박람회 & 센터와 같은 대면 접점이 있고 고객은 대면해서 제품을 구매할 수 있다. 즉, 고객이 브랜드가 다른 브랜드들과 차별화된 프리미엄을 체감할 수 있는 부분은 박람회와 센터이다.
센터와 박람회라는 오프라인 경험을 모두 변경하면 좋겠지만 한 가지 특수한 상황이 있다.
센터는 센터장들이 개인사업자로 각자 사업으로 센터를 운영하고 있고 박람회는 본사 주최로 센터를 초대해 진행하고 있었다. 그래서 새로운 서비스를 론칭하고 고객 및 파트너들의 의중을 살피기 위해선 박람회가 적합한 장소라고 판단했다.
02. 어떤 서비스 접점에서 프리미엄을 전달할 것인가?
What : 영유아 영어 전집
영어가 자유로운 베리굿 키즈가 되기 위해선 약 360만 원의 영유아 전집을 구매해야 한다.
그렇다면 박람회장에서 어떤 프리미엄 브랜딩을 전달할 수 있을까?
바로 360만 원의 교재를 사는 과정의 경험을 개선해야 한다고 생각했다.
먼저 고객은 박람회장에 줄을 서서 고객정보를 입력하고 상담을 받으러 간다. 상담 후 구매의사가 있다면 종이로 된 계약서에 기본정보를 기입하고 이를 파트너와 고객이 나눠 가지고 고객은 본사 카운터로 이동해 결제 후 선물을 받고 박람회 부스 경험을 종료하곤 했다.
고객은 360만 원을 주고 구매한 제품을 그다음 주 화요일쯤 집으로 받아보게 된다.
구매계약서정신없는 박람회 현장에서 이 종이에 개인정보를
기입하고 화요일에 받아보는 것이 고객에게 신뢰를 주고 본사 관리자도 관리가 편하다면 좋겠지만 현실은 그렇지 않다.
실제로 고객은 믿고 기입하고 가겠지만 고객 필기체 오류 혹은 고객 주소가 신도시라 주소 정보가 기입된 것과 다른 경우 등 전산화시키는 과정에서 오류가 왕왕 발생한다. 정보 누락과 오류를 없애고 고객정보 입력 중복제거를 통한 프리미엄 제품을 구매한다는 경험을 하게 하려면 과연 어떤 방법이 좋을까?
(생각만 해도 끔찍하다. 이 문서를 사람 바글바글한 곳에서 써야 하고 심지어 많은 짐과 아이가 타고 있는 유모차까지 있다면! 물론 앉아서 쓰긴 한다.)
How
만약 내가 구매한 제품이 내 악필로, 혹은 전산 입력자의 실수로 배송이 늦어진다면 얼마나 화가 날까?
그래서 고객과 상담원이 함께 고객정보를 전자기기를 통해 정보를 입력하는 즉시 전산에 올라가는 방법을 고민해보기로 했다. 단, 조건이 있다.
적은 비용, 효과적인 UI 설계
어느 회사나 그렇겠지만 무조건 적은 비용이다.
결국 우리는 부트스트랩 프레임워크 기반의 반응형 웹사이트를 구축하고 고객 싸인은 직접 인쇄해서 고객과 본사가 나누는 방향으로 개발을 진행했다.
당시 솔루션을 모색하던 중 흥미로운 전자계약서 사례가 있어 따로 공유한다.
휴대전화 매장에서 사용하는 패드 계약서, 은행에서 사용하는 패드 계약서, 보험가입 패드 계약서 등 이미 개인 정확한 개인정보가 필요하고 고가 혹은 돈과 직결된 곳에서는 패드로 직접 정보를 입력하게 한다. 외부업체를 통하면 어떤 전자계약서를 구축할 수 있을까?
(1) LG U+ 전자문서 솔루션
당시 이와 같은 서비스를 경험한 적이 있어 전자계약 솔루션 업체인 LG U+ 전자문서 솔루션에 문의를 했다. 만나서 미팅을 해보니 구축하는 데 금액이 많이 들었고 특히 전자서명 솔루션이 전자문서에서 가장 핵심기능이라고 한다. 사용 비용은 건당 사용비용으로 무리한 금액은 아니었으나 구축비용의 벽이 높았다.
또 LG U+의 경우 강조했던 기능은 서명의 좌표값을 모두 저장해 LG U+서버와 저장해놨다가 우리 쪽으로 전달해주는 방식이었다. 하지만 고려대상에서 제외된 이유는 우리의 고객 정보가 다른 회사 서버에 저장되었다가 우리가 원하면 정보를 주기 때문에, 또 높은 비용으로 진행하지 않기로 했다.
https://www.uplus.co.kr/biz/sme/smsup/InitBzSmSupTax.hpi(2) 모두 싸인 솔루션
리서치하던 중 모두 싸인이라는 솔루션을 알게 되었고 살펴보니 우리가 사용하기 적절하다고 생각했다. 하지만 위에서 말했다시피 전자문서는 싸인의 효력이 가장 중요한 부분이라 최대한 계약서 실제 모습을 구현해 정보를 입력하는 형태이고 서명에 초점이 맞춰져 있었다. 문의해보니 전체 계약서 구축 말고도 싸인 모듈만 따로 개발 중에 있어 우리가 만든 시스템에 탑재를 할 수 있다고 했는데 아마도 아직 안된 것 같다.
하지만 전자계약에 대해 좋은 UI를 발견해서 추후 업무에 큰 도움이 됐다. (아래 사이트 참고)
https://www.modusign.co.kr(3) 오렌지 라이프 보험가입 계약 솔루션
오렌지 라이프 보험을 갱신할 때 전자계약서를 써봤는데 UI가 상당히 잘 구축되어있고 사용하기 편해서 감탄했던 기억이 있다. 설계사분께 물어보니 회사에서 직접 구축한 솔루션이라고 한다. 역시 돈이 많아야 좋은 서비스를 만들 수 있구나 라고 생각했다.
03. 전자계약 솔루션을 구축하자.
아주 적은 비용으로, 목표를 달성할 수 있는, 전자계약서를 구축해보기로 했다.
당시 요청부서와 실제 리서치 방향성이 많이 달라서(비용 문제) 빠른 의사결정을 위해 오븐을 이용해 목업을 만들어봤다. 해당 문서를 제작한 이유는 요청부서와 실무와 커뮤니케이션이 잘 되지 않아 이를 해결하기 위한 도구로써 목업을 사용했다.
당시 패드에서 입력하는 상황을 전제로 기획하다 보니 패드 세로 형태에 맞게 목업을 제작했다.
입력하는 부분이 많지 않아 한 페이지로 기획한 목업을 보고 나니 논의가 활발해졌다. (목업 활용 좋은 예) 해당 문서를 가지고 논의한 내용은 크게 두 가지이다.
(1) 세로 최적화 VS 가로 최적화
화면을 세로에 맞춰 최적화할지 가로에 맞춰 최적화할지 논의했다.
위의 목업과 같이 본인은 세로 최적화를 주장했다. 그 이유는 해당 서비스가 부트스트랩 프레임워크로 패드뿐 아니라 모바일에서도 사용할 가능성을 염두에 두었고 또 정보의 흐름을 한 페이지로 놓다 보니 최대한 많은 정보를 볼 수 있는 세로형을 제안했다. 반면 요청부서에선 패드를 사용할 때 가로로 놓고 거치대에서 사용하니 가로로 요청을 했고 스크롤을 최소화하길 원했다.
https://support.apple.com/ko-kr/HT207521(2) 다중 페이지 VS 한 페이지
위에서 살짝 언급했는데 입력하는 정보가 크게 약관/ 회원정보/ 학부모 정보/ 선물 정보로 되어있다.
막상 얹히고 보니 입력하는 칸이 많지 않아 버튼 입력을 최소화하는 원페이지로 제안했고 현업부서에서는 가로로 봤을 때 마치 애플리케이션처럼 보일 수 있는 화면을 요청했다.
결국 사용성을 근거로 요청부서를 설득하지 못해 요청부서의 의견을 최대한 반영한 화면을 기획했다.
(3) 기획 가이드
위의 논의는 설득하는데 실패했지만 화면을 설계할 때 사용자 시선 흐름이 오른쪽과 왼쪽을 번갈아 가며 확인해야 하는 구조가 되지 않게 설계했다. 즉, 표 형식의 정보 나열은 지양하려고 노력했다.
구글 아이트래킹 검색04. 서비스 설계
(1) 프로젝트 헌장 작성
해당 프로젝트 시작 전, 유관부서와 협의 후 개발범위를 상세히 작성한 프로젝트 헌장은 반드시 작성하고 시작하는 게 좋다. 그 이유는 서비스 오픈을 몇 번 경험하다 보니 헌장에 기입되지 않은 정보, 혹은 모호하게 기입된 정보로 발생되는 문제가 많았기 때문이다. 이 과정을 생략한 적도 종종 있었는데 결과는 후회뿐이었다.
문제 발생의 여지를 없애고자 목업을 가지고 논의한 후, 프로젝트 헌장을 작성하였다.
4.1 프로젝트 헌장 수립
프로젝트 헌장 수립은 프로젝트의 채택을 공식적으로 승인하고 프로젝트 관리자에게 조직의 자원을 프로젝트 활동에 투입할 수 있는 권한을 부여하는 내용의 문서를 개발하는 프로세스이다.
프로젝트 헌장은 공식적인 문서이다. 그렇기에 최대한 문서작성을 자세히, 정확하게 기입해야 하고 역할분담도 사전에 합의를 통해 논의한 내용만 작성한다. 작성한 문서는 프로젝트에 관련된 해당 부서장 및 임원진까지 보고하면 프로젝트에 정식 착수하게 된다. ('위 스펙으로 시작할 테니 나중에 다른 말하지 마세요.' 차원에서 보낸다.)
(2) 개발 개요
개발 개요 작성을 1년 차 때는 기획 시간 10 중에 1 정도만 썼다면 연차가 쌓여갈수록 앞단 상위 기획에 8할의 시간을 쏟게 된다. 개발 개요에 포함하는 내용은 배경/ 시스템 환경/ 개발범위/ 하드웨어 스펙/ 최적대응 기기/ 일정이 있다. 들어가는 내용을 보면 알겠지만 프로젝트 전체 청사진이 어느 정도 잡혀야 작성할 수 있다. 그렇기에 가장 앞단에 들어가지만 상당히 많은 부분을 고민해야 작성할 수 있는 부분이기도 하다.
개발 개요정리를 통해 본사관리자 사이트와 계약을 체결하는 파트너용 사이트 두개를 개발하기로 했다.
(3) 파트너용 서비스 Flow
목업을 바탕으로 서비스의 흐름이 잡혔고 실제로 운영되는 전체 서비스의 Flow를 작성했다.
특히 해당 서비스는 센터장/ 교사 계정 차이로 접근 정보 권한이 다르기에 Flow작성에서 고민할 내용이 많았다. 이 부분은 추후 기능 추가 건으로 지속적으로 업데이트 한 Flow이며 처음엔 훨씬 단순하게 나왔다. 왜냐면 신규 시스템 기획이기에 복잡한 프로세스를 지양하고 단순하게 설계했기 때문이다.
본사관리자 사이트도 Flow가 따로 있다. 하지만 파트너용에 비해 단순한 프로세스라 첨부하진 않았다.(4) 화면 설계
가끔, 서비스 기획 자일을 하다 보면 단순히 화면 설계만 진행하는 줄 아는 경우도 있다.
하지만 아래의 화면 설계가 나오기까지 앞단에 정말 많은 리서치와 고민이 있어야 화면 설계도 모순이 적고 실제 구현될 수 있는 화면으로 나올 수 있다고 생각한다.
그래서 화면 설계 작업의 경우 덩어리 단위의 날짜를 잡고 (예 이번 주 5일) 화면 설계만 진행한다.
화면을 빠르게 그려가고 Description을 놓친 것 없이 꼼꼼히 작성한다. 하지만 아무리 꼼꼼히 한다 해도 다음날 보면 잘못된 부분, 미숙한 부분이 보이기에 해당 과정에서는 내가 만든 문서를 낯설게 바라보는 역량도 중요하다고 생각한다. 나도 아직도 잘 못하지만 꾸준히 노력하고 있는 부분이다.
그리고 Description의 경우 '서비스 글쓰기의 모든 것'을 보며 중의적 표현을 제거하고 말이 어렵지 않고 바로 이해될 수 있게 검수하는 과정을 거친다. 개인적으로 문서로 커뮤니케이션하는 것이 가장 중요한 부분이라 생각하기에 작업을 하면서도 종종 찾아보곤 한다.
화면 설계 문서05. 디자인
이 프로젝트의 경우 개발자와 서비스 기획자만 작업에 투입되어 진행을 해서 디자인은 서비스 기획에서 직접 가이드를 제작했다. 물론 부트스트랩 템플릿을 유료로 구매해 진행해 가이드의 내용은 GNB색상, 로고 위치, 로고 크기, 버튼 활성화/비활성화 색상값 지정, 텍스트 컬러 지정 등이 있었고 필요한 로고 및 이미지들을 재 가공해서 전달하는 역할을 수행했다. 부트스트랩 템플릿을 사용했을 때 장점은 빠른 시간 내에 그럴싸한 사이트를 어느 정도 만들 수 있다는 점을 들 수 있고, 백엔드 개발자도 디자이너가 없더라도 어느 정도 사이트를 구현하기 좋다. 그런데 우리 회사에서 이 프로젝트를 구축한 후 치명적인 단점은 내부 디자이너가 퍼블리싱 역량이 있음에도 부트스트랩 템플릿으로 제작한 사이트는 직접 유지 보수하기가 어렵다.
물론 시작 전부터 예상했던 문제이고 그럼에도 불구하고 일정을 당기기 위해 선택한 방법이라 해당 서비스 유지보수는 백엔드부터 프런트엔드까지 개발자가 진행하고 있다.
06. QA
개발이 끝나면 구글 스프레드시트를 만들어 수정이 필요한 부분과 중요성을 기입해 전체적으로 공유한다. 중요도 및 처리 기간에 따라 종종 일정 협의도 진행하기도 한다.
구글 스프레드 시트로 검수 문서를 만들곤 하는데 내부에 QA팀이 따로 없다 보니 서비스 기획, UI 디자인, IT 개발에서 동시에 검수하고 처리하다 보니 모두가 바로 수정해 볼 수 있는 문서가 업무 효율성을 높여주어서 현재 5번째 프로젝트 진행 동안 구글 문서를 사용했다.
05. 오픈 그 후,
입력하면 오른쪽과 같이 인쇄되어 나온다.(1) 서비스 설명
실제로 서비스를 사용해 계약을 진행해야 할 파트너와 본사 담당자들에게 서비스를 설명하는 자리를 마련했고 사용방법을 자세히 기입한 가이드 문서를 전달했다. 그리고 처음 시작이 박람회였기에 해당 박람회에 개발자와 서비스 기획자가 참여해서 이슈 대응을 했다. 막상 박람회 현장에서 사용하다 보니 인터넷 환경문제, 기기별 최적대응 이슈, 사용법 학습 등 변수가 많았다. (우리는 진짜 편할 것이라 생각하고 만들었지만 타깃은 40~50대 분들이 대부분이었고 서비스 숙달까지 어느 정도 시간이 필요했다.)
noun project 아이콘(2) 사용 데이터 비교분석
처음 오픈했을 때는 사용량 집계가 안되었기에 비교군이 없었지만 2018년 7월 서비스 오픈을 시작으로 11월 박람회, 2019년 2월 박람회, 2019년 4월 박람회에서 서비스 사용량을 비교했을 때 유의미한 결과를 발견했다.
2018년도 11월 과 2019년도 2월 사용량 분석 결과(3) 투입 비용
해당 프로젝트 구축 비용은 부트스트랩 템플릿 비용 32,000원과 개발자 간접비용(1/3) , 서비스 기획자 간접비용(1/2)이 투입되었고 그 외 운영 비용은 계약서 인쇄를 위한 A4용지, 잉크토너, 프린터기 등이 들었다.
전자계약 솔루션으로 진행했을 경우 5,000만 원에 달하는 비용이 투입되어야 하지만 내부 인력의 갈림으로 아주 적은 비용으로 운영할 수 있는 프로젝트를 만들었다. (개발자분이 정말 정말 많이 힘들어하다가... 퇴사하셨다.)
마무리하며,
미루고 미루던 전자계약 시스템 구축 내용을 작성했다. 참 많은 난항이 있었고 프로젝트 주도권에 대해서도 이야기가 많았던 프로젝트였다. 당시 2년 차 서비스 기획자로써는 참 당황스러운 부분도 많았고 힘들기도 했다.
그래서 만약 이 글을 프로젝트 의뢰자, 혹은 상위 직급자, 정책결정권자가 보게 된다면, 혹은 CEO가 보게 된다면 적은 비용으로 서비스를 구축하는 것도 분명 의미 있는 일이지만 원하는 서비스의 유사 사례들을 함께 살펴보고 투입비용을 산정하고 투자해야 한다고 생각한다.
왜냐면 나는 이 프로젝트가 끝나고 함께 동고동락하던 개발자 분이 이직을 하게 되었고(물론 좋은 일이지만) 이직의 사유로는 해당 프로젝트도 어느 정도 지분이 있다고 생각하기 때문이다. 당시 PM으로써 실무자의 힘듦을 덜어주기엔 힘도 없고 디자인과 기획업무를 모두 수행하다 보니 나도 지친 상태였다. 그래서 해당 프로젝트의 경험을 바탕으로 실무에서 혹사하며 일하지 않도록 업무를 분배하려고 노력하고 있다.
사람을 갈고 가다 보면 결국 지치게 되고 인재를 잃게 되는 결과는 피할 수 없다.
어쩌다 보니 프로젝트 리뷰 마무리 멘트가 협박 아닌 협박(?)이 되었지만 나에겐 아픈 프로젝트였고
그럼에도 일을 해나가야 하기에 경험 공유 차원에서 이 글을 공유한다.
