B2B2C

누구에게 파느냐는 질문에 오랫동안 답은 둘뿐이었습니다. 기업을 고객으로 삼는 B2B이거나, 개인 소비자를 고객으로 삼는 B2C이거나. 그런데 이 두 칸에 넣으면 설명이 막히는 회사들이 있었습니다. 계약서에 도장을 찍는 쪽은 기업인데 그 제품을 매일 여는 사람은 그 기업의 직원이 아니라 손님인 경우입니다.

쇼핑몰에 결제창을 넣어 주는 회사가 그렇습니다. 계약은 쇼핑몰과 맺고 돈도 쇼핑몰이 냅니다. 그런데 결제 화면을 보는 사람은 물건을 사는 개인이고, 카드 번호를 세 번 다시 입력하게 만들면 화를 내는 쪽도 그 개인입니다. 이런 회사에서는 회의 때마다 "고객"이 사람마다 다른 대상을 가리켰습니다. 영업은 쇼핑몰을 떠올리고 고객센터는 구매자를 떠올리니, 같은 단어로 다른 이야기를 했습니다.

B2B2C는 그 빈칸을 메우려고 붙인 이름입니다. 가운데에 B를 한 칸 더 적는 것만으로 돈이 흐르는 경로와 제품이 쓰이는 경로가 갈라져 있다는 사실이 드러납니다.

세 자리가 한 줄로 이어집니다. 제품을 만드는 우리, 그 제품을 자기 서비스에 얹어 손님에게 내놓는 기업, 그 기업의 서비스를 쓰는 개인입니다. 가운데 기업을 보통 파트너사라고 부릅니다.

자리마다 하는 일이 다릅니다.

1. 우리는 제품을 만들고 파트너사와 계약합니다. 돈이 들어오는 자리입니다. 매달 정액을 받기도 하고, 파트너사가 최종 사용자에게서 번 금액의 일부를 나눠 받기도 합니다. 뒤쪽 방식이면 파트너사의 장사가 잘돼야 우리 매출도 오릅니다.
2. 파트너사는 우리 제품을 자기 서비스 안에 끼워 넣고 자기 손님에게 내놓습니다. 대개 자기 브랜드를 앞세웁니다. 우리 이름을 지우고 고객사 로고를 달아 내보내는 방식을 화이트라벨이라고 합니다.
3. 최종 사용자는 우리와 아무 계약도 맺지 않은 채 우리 제품을 씁니다. 우리 회사 이름을 모르는 경우도 많아, 불편하면 파트너사 고객센터에 연락합니다.

두 흐름이 갈라져 있다는 점이 이 구조의 전부입니다. 돈은 파트너사에서 오고 사용은 최종 사용자에게서 일어납니다. 그래서 요구사항이 정면으로 부딪칩니다. 파트너사는 자기 브랜드를 크게 보이고 싶어 하고 최종 사용자는 결제 단계가 하나라도 적기를 바랍니다. 파트너사는 가입 화면에서 더 많은 항목을 묻자고 하는데, 항목이 늘수록 최종 사용자는 중간에 떠납니다.

책임이 어디까지인지도 계약에서 미리 정합니다. 화면이 30분 멈췄을 때 사과문을 쓰는 쪽은 파트너사인데 원인을 고칠 수 있는 쪽은 우리입니다. 장애가 나면 몇 분 안에 알려 줄지, 문의를 파트너사가 어디까지 받고 어디부터 우리에게 넘길지를 적어 두지 않으면 사고가 난 날에 서로를 찾느라 시간을 씁니다.

무엇을 먼저 만들지 정하는 자리에서 자주 나옵니다. 파트너사 한 곳이 붙으면 그 아래 사용자가 한꺼번에 수만 명 들어오기 때문에 준비할 것이 달라집니다.

만들 순서에서는 세 가지가 앞으로 옵니다. 고객사별로 화면 색과 로고를 바꿔 끼우는 설정 기능, 여러 고객사가 한 시스템을 나눠 쓰되 서로의 자료는 절대 보이지 않게 막는 멀티테넌시 구조, 그리고 파트너사 개발자가 자기 서비스에 우리 기능을 끼워 넣을 때 쓰는 SDK입니다. 개인에게 직접 파는 제품이라면 한참 뒤에나 만들 것들입니다.

숫자도 두 층으로 세야 합니다. 파트너사 수만 세면 제품이 실제로 쓰이는지 알 수 없고, 최종 사용자 수만 세면 어느 파트너사가 매출을 떠받치는지 보이지 않습니다. 그래서 파트너사 하나가 데려온 최종 사용자 수와 그 파트너사에서 나오는 매출을 짝으로 봅니다. 고객 한 단위에서 얼마가 남는지를 따지는 유닛 이코노믹스도 파트너사 단위로 계산합니다.

영업과 마케팅의 대상도 갈립니다. 파트너사 한 곳을 뚫는 데는 몇 달이 걸리는데, 그 아래 최종 사용자에게는 연락처가 없어 광고조차 집행할 수 없습니다. 성장은 파트너사를 늘리거나 기존 파트너사의 사용자를 더 쓰게 만드는 두 갈래뿐입니다.

"이건 B2B2C라서요, 고객사 요구대로 넣으면 최종 사용자 가입 전환이 떨어집니다."

파트너사가 요청한 입력 항목이 그 아래 사용자를 떠나게 만든다는 반대 의견입니다.

"그 지표 파트너사별로 쪼개서 볼 수 있을까요? 합쳐 놓으면 어디가 문제인지 안 보여요."

전체 평균이 특정 파트너사의 부진을 가리고 있다는 뜻입니다.

"최종 사용자 데이터는 고객사 자산이라 우리가 직접 메일 못 보냅니다."

마케팅 제안을 계약 조건으로 막는 말입니다.

페이지덱은 교육 플랫폼 한 곳과 계약하면서 이 구조를 처음 겪었습니다. 그 플랫폼은 수강생이 과제를 제출하는 화면에 페이지덱 문서 편집기를 넣었고, 계약도 정산도 플랫폼과만 이뤄졌습니다. 편집기를 여는 사람은 수강생 4만 명이었습니다.

지현은 그때부터 요구사항을 두 줄로 나눠 적었습니다. 플랫폼 담당자가 요청한 것과 수강생에게서 올라온 것을 한 표에 섞어 두면 언제나 앞쪽이 먼저 처리됐기 때문입니다. 수아가 가져온 플랫폼 요청은 로고 위치와 관리자 통계였고, 수강생 쪽 불만은 저장 버튼을 누르고 3초를 기다린다는 것이었습니다. 규원은 계약을 쥔 쪽을 먼저 보자고 했고, 지현은 수강생이 편집기를 쓰지 않으면 다음 해 갱신이 없다고 맞섰습니다.

B2B와 B2C를 합쳤으니 양쪽 장점을 다 가진다고 읽는 경우가 가장 많습니다. 기업 계약의 안정적인 매출과 개인 시장의 규모를 한 번에 얻는 그림이 그려지기 때문입니다. 실제로는 관문이 둘이 됩니다. 파트너사를 설득하는 몇 달짜리 영업을 먼저 통과하고, 그다음 그 아래 사용자가 실제로 쓰게 만드는 일을 또 해내야 합니다. 어느 한쪽만 되면 아무것도 되지 않습니다. 계약은 맺었는데 사용자가 안 쓰면 다음 해에 갱신되지 않고, 사용자가 좋아해도 파트너사가 우리를 떼어 내면 그 사용자들은 한 번에 사라집니다.

최종 사용자를 우리 고객이라고 여기는 것도 흔한 오해입니다. 우리 제품을 쓰고 있으니 우리 사용자처럼 보이지만, 계약상 그들의 정보는 대개 파트너사 자산입니다. 광고를 보내거나 설문을 돌리려면 파트너사 허락이 필요하고, 거절당하기도 합니다. 사용자 수를 우리 자산으로 계산해 두면, 파트너사 한 곳이 떠날 때 그 밑의 수만 명이 함께 빠져나가면서 계획이 한꺼번에 어긋납니다.