서비스 제휴 기획, 타사와 우리 서비스를 묶기
서비스 기획을 하다 보면 타사 서비스와 우리 서비스를 연동해야 되는 경우가 생깁니다. 오늘은 우리 서비스와 타사 서비스를 어떻게 연동시켜나가는지에 대해서 함께 살펴보도록 하겠습니다. 독자의 이해를 돕기 위해 우리 회사는 음식점용 POS 프로그램을 서비스하는 회사고 제휴 회사는 음식 배달대행 솔루션 서비스를 제공하는 회사라고 가정하고 사고를 전개시켜 보도록 하겠습니다.
우리 회사 – 음식점용 POS 프로그램 제공 업체 (음식점 내의 주문 접수, 계산 등을 간단히 처리할 수 있도록 도와주는 프로그램, 편의점 등에서 점원이 계산할 때 쓰는 그것)
제휴 회사 – 배달대행 솔루션 제공 업체 (음식점에서 배달전문업체에 배달을 요청하고 기사가 음식을 픽업하여 고객에게 배달하는 일련의 과정에 대한 솔루션을 공급하는 업체)
(아래 설명드리는 내용은 약식 설명입니다. 실제 비즈니스 의사 결정과는 다소 거리가 있을 수 있습니다.)
1. 사업적인 판단
우리 회사는 음식점에 POS 솔루션을 공급하는 회사입니다. 하지만 이 시장은 완전히 레드오션이나 다름이 없어 경쟁도 너무 치열하고 솔루션간 기능적인 차이점도 적어 어떤 업체도 시장 점유율을 확 끌어올릴 수 없는 동인이 없는 상태입니다. 그래서 POS 솔루션 업체 사장 김포스씨는 다음과 같은 생각을 하게 됩니다. ‘현재 홀 전문 음식점에서도 점점 배달 쪽으로 사업영역을 확장하는 추세고, 만약 POS 프로그램과 배달 호출 프로그램을 일원화하여 고객에게 서비스한다면 우리 솔루션이 타사 솔루션에 비해 경쟁력을 갖지 않을까?’라는 생각을 하게 되고, 김기획씨에게 자신의 생각을 설명합니다. 김기획씨는 사장님의 설명을 듣고 제휴 기획을 준비하게 됩니다.
여기서 한 가지 짚고 넘어가야 할 점은, 제휴 기획이라는 것은 우리만 도움이 되어서는 결코 성사될 수 없다는 점입니다. 우리와 서비스 연동 개발을 하는 제휴사에게도 이익이 되어야 합니다. 즉, 쌍방 편익이 없다면 이 제휴는 결코 성사될 수 없습니다. 따라서 위의 의사결정 과정에서는 생략되었지만 반드시 쌍방 편익에 대한 부분이 고려된 후 기획을 시작해야 합니다.
2. 리서치 및 제휴사 컨택
이제 김기획씨는 사장으로부터 대략적인 설명을 들은 후 관련 솔루션을 제공하는 업체를 리서치하기 시작합니다. 업체를 3군데 정도 발굴한 후 전화를 합니다. 전화를 해서 다음과 같이 설명합니다. 우리 회사는 어떤 회사고 어떤 서비스를 제공하고 있는지, 그쪽 회사에서 어떤 서비스를 제공하고 있는지 확인했으며 우리 서비스와 어떤 식으로 연결을 하고 싶은지, 그렇게 연결했을 때 상호 간 시너지는 어떻게 날 수 있는지 등을 설명합니다. 해당 담당자가 긍정적인 반응을 보이면 첫 미팅을 잡게 됩니다.
3. 미팅 전 준비
미팅 전에 제휴사와 어떤 식으로 연동을 하고자 하는지에 대한 자료를 준비해야 합니다. 우리 서비스와 제휴사의 서버 간 어떤 정보를 주고받을 지에 대한 자료를 대략적으로 만들어둡니다. 문자보단 도식도 등을 간략하게 만들어서 준비해두는 것이 좋습니다. 또한 가능하다면 타사에 서비스 시연이 가능한지 여부를 확인해둡니다. 우리가 원하는 서비스를 제대로 제공할 수 있는지 확인하기 위함입니다. 미팅 중에 구두로만 가능 여부를 확인받은 후 추후 구축 도중 우리가 원하는 것을 수행할 수 없다는 것이 밝혀지면 매우 곤란한 상황이 발생하기 때문입니다.
4. 미팅 진행
회의 목적을 간략하게 설명하고 먼저 자사 서비스에 대한 시연을 먼저 합니다. 우리 서비스가 제공하고 있는 기능들, 그리고 그 기능들과 융합하여 제휴사와 어떤 식으로 연동하고 싶은지에 대해서 간단하게 설명합니다. 후에 준비했던 도식도 등을 보여주어 구체적으로 어떤 식으로 정보를 교환하고 싶은지, 그리고 가능한지 여부에 대해서 확인합니다.
우리 쪽 설명이 끝나면 제휴사 서비스 시연을 요청합니다. 시연 시 가능하다면 양해를 구하고 녹화를 해두도록 합니다. 설명을 한 번에 듣고 온전히 이해하는 것은 좀처럼 쉬운 일이 아니기 때문입니다.
미팅이 끝나고 양쪽 다 긍정적인 반응이 나오면 일정 등을 협의하게 됩니다. 또한 추가로 제휴사 솔루션을 이용할 수 있는 접근 권한을 요청하는 것이 좋습니다. 우리 쪽에서도 직접 써봐야 계획을 제대로 세울 수 있으니까요. 그리고 가능하다면 API 연동 문서가 있는지 확인하고 해당 문서도 전달받는 것이 좋습니다. 개발자, 기획자 모두 해당 문서를 확인해서 어떤 정보를 어떤 형식으로 주고받을 수 있는지 확인할 수 있기 때문입니다.
5. 기획서 작성
지금까지 확인한 내용, 파악한 내용을 바탕으로 전체 서비스 플로우, 주고받은 정보의 목록 및 형식, 와이어프레임 등에 대한 초안을 작성한 후 내부 리뷰를 진행하게 됩니다. 내부 리뷰가 통과되면 제휴사에 기획서를 전달하여 가능 여부를 타진합니다. 제휴사와 피드백을 주고받으며 기획서를 확정합니다.
기획서는 대략 이런 내용들을 담고 있을 것입니다.
서비스 흐름
가. 고객으로부터 전화, 혹은 주문 앱으로부터 주문 접수
나. 접수받은 내용을 POS에 입력 후 POS에서 배달대행 솔루션으로 정보 전송
다. 배달대행 솔루션에서 콜 접수 후 기사 배차
라. POS에서 배차 정보 확인
마. 기사가 음식점에 도착해서 음식 픽업
바. 기사가 고객 방문 후 배달 및 결제 완료
사. 결제 완료 시 POS와 배달대행 솔루션에 모두 배달 완료 정보 전달 완료
필요 정보
가. POS -> 배달대행 솔루션
- 음식점 주소, 도착지 주소, 도착지 전화번호, 결제 금액, 결제 수단, 픽업 요청 시간
나. 배달대행 솔루션 -> POS
- 배달 가능 여부, 배차 기사, 음식점-도착지간 거리에 따른 배달 금액, 배달 상태 변경 (배차, 픽업, 완료)
와이어프레임
가. 주문 접수 후 배달대행 요청 창
나. 배달비 정산 페이지
다. 배달 이용 현황 페이지
6. 구축 개발 시작
지금까지 확정된 내용을 바탕으로 양사 개발자가 연동개발을 진행합니다. 중간에 의사결정이 필요한 경우 기획자가 조율합니다. 예를 들어 이런 문제가 발생할 수 있습니다. POS에서 제공하는 주소 형식과 배달대행 솔루션에서 제공하는 주소 형식이 다른 경우, 그런 경우 어떤 식으로 통신할 것인지에 대해서 상호 협의해야 합니다. 기술적인 이슈에 대해 잘 모르겠으면 개발자의 도움을 받아가며 문제를 해결합니다.
7. QA
일반적인 QA와는 다르게 양쪽 모두에서 QA를 진행해야 합니다. 만약 제휴사에서 QA를 원활하게 하기 힘든 환경이라면 우리 회사에서 양쪽을 전부 테스트할 수 있는 테스트 환경을 구축 후 각종 시나리오에 대응하는 QA를 진행해야 합니다.
8. 배포
구축 개발 및 QA가 모두 종료되면 서비스 개편 시점에 맞추어 배포합니다.
제휴 기획도 자체 서비스 구축 기획과 크게 다르지는 않습니다. 양사가 제휴에 상호 합의했다는 가정 아래 어떤 데이터를 어떤 형식으로 주고받고, UI/UX 흐름을 어떻게 만들어갈지만 확정한다면 그 이후 기획자의 역할은 자사 서비스를 만들 때와 크게 다르지 않습니다. 다만, 처음에 타사와 제휴 기획을 한다고 하면, 어떻게 커뮤니케이션을 해야 할지, 어떤 식으로 정보를 주고받아야 할지, 이슈가 생기면 어떤 식으로 조율해야 할지 막막한 부분들이 있을 것입니다. 저는 오늘 그 부분에 대해서 약간의 팁을 드린 것이라고 생각해주시면 감사드리겠습니다.
다음 시간에는 기획자와 데이터 분석에 대해서 살펴보도록 하겠습니다.
읽어주셔서 감사합니다.
