양사간 이종 시스템이 만나는 서비스 제휴는 양사 모두에게 시너지를 줄 수 있는 좋은 선택이 될 수 있다. 다만, 서비스 제휴는 상호 호혜적인 경우에만 의미가 있다고 할 수 있다. 한쪽만 이득을 취할 수 있는 서비스 제휴는 두 회사 간의 관계가 모회사-자회사가 아닌 이상은 성사가 될 가능성이 희박하다고 볼 수 있다.
여기 두 스타트업 회사가 있다. 먼저, 한쪽에서 다른 한쪽과 함께 했을 때의 새롭게 펼쳐지는 기회를 발견하면서 이야기는 시작된다.
1. 기회의 발견
기회는 내가 진입하고자 하는 시장에서 발견된다. 내가 진입하려고 하는 시장, 즉, 우리 회사 서비스를 수평적 혹은 수직적으로 확장하려는 시도를 하는 가운데 해당 산업군에 존재하는 플레이어를 물색하는 과정에서 연결고리가 발생하기 시작한다. 우리 회사의 A 서비스와 저 회사의 B 서비스를 연결한다면? 연결해서 사람들에게 이런 서비스를 제공하고 비즈니스 모델은 이렇게 세운다면? 머릿속으로 대략적으로 그림을 그려보고 그림의 아귀가 맞아떨어질 때 우리는 가능성을 느끼게 된다.
2. 미팅
전혀 모르는 사이에서 일단 연락을 해보든, 소개를 받든 일단 접촉이 되면 미팅을 진행할 수 있다. 처음 미팅은 당연히 실무자가 아닌 의사결정권자들끼리 만나서 의견 조율을 하게 된다. 당연히 제휴를 원하는 쪽이 제휴하고자 하는 회사에 제안을 해야 한다. 제안은 보통 PPT로 준비해 가게 되는데, 자사 소개 및 서비스의 소개, 그리고 가능하다면 시연, 제휴사 서비스와 연동, 연동되었을 때의 양사간 이익(이게 가장 중요하다.), 비즈니스 모델 정도가 제안서에 담기게 될 내용이라고 할 수 있다.
3. 실무자 접촉
여기서 좋은 피드백을 얻었다면 다음부터는 실무자들끼리 해결해야 될 사안들이 있다. 각자 제휴사의 서비스를 이용해 보고 어떤 식으로 붙이는 것이 좋을지 시나리오 작업이 필요하다. 고객이 서비스에 접근해서 목적을 달성하기까지의 과정에서 양사의 서비스가 어떻게 어우러지는지, 그리고 이러한 목적을 달성하기 위해서 서로의 서비스가 어떻게 수정되어야 하는지 등 전체적인 내용에 대해서 서로 여러 번의 미팅을 통해 조율을 한다. 물론, 최종 승인은 의사결정권자가 하게 된다.
4. 기획서 완성
제휴를 원하는 측에서 기획서를 작성한다. 서비스 시나리오 및 와이어프레임을 그려 제휴사에 전달하고 최종 컨펌을 진행한다. 구축, QA, 현장 테스트 등 전반적인 절차에 대한 계획도 서로간 공감대가 형성되어 있어야 한다.
5. 개발 구축
기획서를 기반으로 개발 실무진들끼리 개발 문서 교환을 시작으로 구축을 시작한다. 이 부분은 내가 개발자가 아니라 정확히 모르지만, 서로간 데이터가 잘 주고받아지는지 확인하는 절차 등이 있다.
6. QA 테스트
구축이 완료되면 양사에서 모두 테스트를 진행한다. 인하우스 개발과 다른 점은 이종의 시스템이 만나기 때문에 테스트 환경을 맞추는데 약간의 애로사항이 있다는 점이다. 제휴사에서 테스트 계정을 생성해주어야 하며, 타사 서비스에 대한 완전한 이해는 불가하기 때문에 예외적 상황에 바로 대응이 힘든 점 등 문제가 있을 수 있으나 이 역시 커뮤니케이션을 통해 해결이 가능하다.
7. 현장 테스트
필트 테스트는 반드시 진행되어야 한다. 현장에서 직접 사용하는 유저가 제휴된 서비스를 어떻게 받아들이고 우리가 제안한 기능들을 어떻게 소화하고 있는지 점검하고 피드백을 개발에 빠르게 반영하는 것이 무엇보다 중요하다. 첫 10명의 고객의 불만을 흡수하면 1,000명의 고객의 불만을 미리 없앨 수 있다.
하지만, 무엇보다도 스타트업 의사결정권자가 (보통은 CEO) 제휴를 본격적으로 시작하기 전에 구성원들을 잘 설득하는 과정이 선행되어야 한다. 우리는 왜 이 회사와 제휴해야 하는지, 제휴를 했을 때 어떤 그림이 그려지는지, 어떤 매출(이윤)이 창출되는지, 들어가는 공수 대비 산출물은 어떠할지 본인이 그려놓은 대략적인 그림을 구성원들에게 가감 없이 보여주고 팀 구성원들이 이를 ‘자기 일’로 느끼게 한 후 제휴를 진행하는 것이 성공적인 제휴 구축 및 운영에 매우 큰 도움이 될 것이다.