Pillar article

아무도 말하지 않는 코셀 어트리뷰션 문제

2025년 10월 25일7 min read

아무도 말하지 않는 코셀 어트리뷰션 문제

얼라이언스 매니저에게 지난 분기 파트너가 얼마나 많은 수익에 영향을 미쳤는지 물어보십시오. 둘 중 하나의 답을 듣게 될 것입니다. 재무팀 누구도 믿지 않는 자신감 넘치는 숫자, 아니면 어깨를 으쓱하는 것. 둘 다 같은 곳에서 나옵니다. 코셀 어트리뷰션, 즉 거래에서 파트너가 맡은 역할에 대해 공정하게 크레딧을 부여하는 능력은 대부분의 B2B 수익 조직에서 망가져 있으며, 회의에서 이를 인정하고 싶어하는 사람은 거의 없습니다.

이것이 조용히 넘어가는 이유는 어트리뷰션이 정치적이기 때문입니다. 거래가 성사되면 AE는 커미션을 원합니다. 파트너는 자신이 생태계에 쏟은 시간을 정당화할 크레딧을 원합니다. 얼라이언스 팀은 이 기능이 인력을 받을 자격이 있음을 증명할 숫자를 원합니다. 모두가 그 거래를 자기 것이라 주장할 이유가 있지만, CRM은 애초에 심판 역할을 하도록 만들어지지 않았습니다. 그래서 이 문제는 스프레드시트, 어느 정도의 직감, 그리고 모두를 조금씩 짜증나게 만드는 분기별 협상으로 처리됩니다.

CRM은 파트너를 볼 수 없다

CRM은 한 명의 판매자, 한 명의 구매자, 하나의 기회를 중심으로 설계되었습니다. 이는 직접 영업에는 잘 작동합니다. 하지만 제3자가 계정을 소개하거나, 챔피언을 예열하거나, 경쟁사에 맞서 여러분을 옹호하거나, 최종 피칭에 함께 참여한 순간부터는 작동을 멈춥니다.

기회 객체 어딘가에는 보통 파트너 필드가 있습니다. 이것은 단일 선택 드롭다운이며, 담당자들은 기억날 때만 입력하는데 그런 경우는 흔치 않습니다. 두 파트너가 거래를 다뤘다거나, 한 명이 소싱하고 다른 한 명이 클로징을 도왔다거나, 파트너가 로그에 기록된 통화에 한 번도 등장하지 않고도 영향을 미쳤다는 것을 표현할 방법이 없습니다. 데이터 모델에는 공유 크레딧을 위한 어휘가 없어서 크레딧은 그냥 사라져버립니다. 저희는 이에 대해 대부분의 CRM에서 파트너 소싱 수익이 보이지 않는 이유에서 더 자세히 다뤘습니다.

그 결과는 하위 단계에서 값비싼 대가를 치릅니다. 파트너 영향을 받은 파이프라인이 시스템 오브 레코드에 없다면, 모든 대시보드, 이사회 자료, 예산 논의는 생태계가 실제로 하고 있는 일을 과소평가합니다. 프로그램은 효과가 없어서가 아니라 아무도 그것이 효과를 내는 것을 볼 수 없어서 잘리게 됩니다.

양쪽 방향 모두에서 실패한다

망가진 어트리뷰션은 한쪽으로만 기울지 않습니다. 보통 회사는 과대 크레딧과 과소 크레딧을 동시에 부여하고 있습니다.

과대 크레딧은 거래에 관여한 모두가 그것 전부를 자기 것이라 주장할 때 발생합니다. 얼라이언스 팀의 "파트너 소싱", AE의 "자체 소싱", 수요 창출팀의 "마케팅 영향"을 모두 더하면 총합이 실제 예약 수익을 훨씬 웃도는 경우가 많습니다. 재무팀은 이를 알아차립니다. 그러면 재무팀은 모든 숫자를 불신하기 시작하고 파트너 팀이 보고하는 것은 무엇이든 조용히 깎아서 받아들이기 시작합니다.

과소 크레딧은 더 나쁘고 발견하기도 더 어렵습니다. 파트너가 거래 성사 18개월 전에 따뜻한 소개를 해줍니다. 수익이 들어올 무렵이면 그 접점은 이미 로그에 기록된 50개의 다른 활동들 아래 묻혀 있고, 파트너는 아무런 크레딧도 받지 못합니다. 문을 열어준 그 관계는 서류상으로는 마치 아무 일도 하지 않은 것처럼 보입니다. 이런 일이 몇 번 반복되면 최고의 파트너들은 더 이상 거래를 가져다주지 않게 됩니다. 그들은 그 이유를 말해주지 않을 것입니다.

이런 혼란의 상당 부분은 거래를 소싱하는 것과 거래에 영향을 주는 것을 같은 지표로 취급하는 데서 비롯됩니다. 이 둘은 다르며, 하나의 숫자로 측정하면 둘 다 틀리게 됩니다. 영향받은 파트너 수익과 소싱된 파트너 수익을 측정하는 방법을 읽고 이 둘을 별개의, 각각 정당한 모션으로 운영해보시길 권합니다.

타이밍과 핸드오프가 흔적을 끊어놓는다

어트리뷰션은 데이터 모델 문제이지만, 동시에 순서의 문제이기도 합니다. 파트너의 관여는 하나의 깔끔한 순간에 일어나는 경우가 드뭅니다. 추천이 들어오고, 대기열에 머물고, 담당자에게 라우팅되고, 식어버리고, 다른 파트너에 의해 다시 활성화되고, 결국 전환됩니다. 이러한 전환 하나하나가 흔적이 끊길 수 있는 지점입니다.

핸드오프는 가장 자주 흔적이 끊기는 곳입니다. 파트너가 리드를 여러분의 영업팀에 넘길 때, 그 맥락(챔피언이 누구인지, 어떤 어려움이 대화를 시작했는지, 파트너가 이미 무엇을 약속했는지)은 보통 CRM에는 결코 도달하지 않는 이메일이나 슬랙 스레드에 남아 있습니다. 기회는 원점 정보 없이 새로 생성되고, 거래가 움직이기 시작하기도 전에 파트너의 흔적은 사라집니다. 이런 일은 충분히 자주 일어나서 저희는 이를 위한 별도의 글을 작성했습니다. 파트너십이 핸드오프에서 멈추는 이유와 그 해결책입니다.

다자간 거래는 이 모든 것을 더 악화시킵니다. 하이퍼스케일러 마켓플레이스 거래, SI 구현 파트너, ISV 통합이 모두 같은 기회를 건드릴 때, 드롭다운 하나로는 답이 없습니다. 아무도 승인하지 않은 첫 터치 우선 기본값이 아니라, 사전에 합의된 실제 다자간 거래를 위한 어트리뷰션 모델이 필요합니다.

진짜 해결책은 어떤 모습인가

더 큰 대시보드로는 해결되지 않습니다. 대부분의 조직에는 세 가지가 빠져 있습니다.

첫째는 거래당 두 명 이상의 당사자를 허용하는 데이터 모델입니다. 크레딧은 단일 소유자 필드가 아니라 타임스탬프가 있는 역할(소싱됨, 영향받음, 코셀됨, 이행됨)로 표현될 수 있어야 합니다. 그 아래 모델이 공유 크레딧을 지원하지 않는 한, 그 위의 어떤 리포팅 계층도 실제 일어난 일을 재구성할 수 없습니다.

둘째는 신호가 발생하는 순간 그것을 포착하는 것입니다. 파트너 접점은 소개가 이루어지거나 코셀 통화가 진행될 때 기록되어야지, 몇 달 후 누군가의 기억으로부터 재구성되어서는 안 됩니다. 이는 담당자들이 분기 말에 필드를 채워 넣기를 바라는 대신, 파트너 관여의 실제 순간을 계측한다는 의미입니다. 그들은 채우지 않을 것입니다.

셋째는 사전에 결정된 어트리뷰션 정책입니다. 얼라이언스 리더가 할 수 있는 가장 유용한 일은 아마도 모두가 침착하고 어떤 커미션도 답에 걸려 있지 않을 때, 분기가 시작되기 전에 크레딧 규칙을 협상하는 것일 겁니다. 첫 터치, 멀티 터치, 가중치 부여 중 구체적인 모델이 무엇인지는, 모두가 사전에 그것에 동의했다는 사실보다 덜 중요합니다.

이 세 가지 모두는 결국 CRM, 파트너 포털, 마켓플레이스, 그리고 대화가 일어나는 도구들 전반에 걸쳐 신호를 연결하는 것에 관한 것입니다. 그래야 크레딧이 실제로 일어난 일을 반영합니다. 수익 오케스트레이션을 위해 구축된 플랫폼은 어트리뷰션을 클로징 시점에 채워 넣는 필드가 아니라 지속적이고 다자간에 걸친 데이터 문제로 다룹니다. 저희 경험상 그것만이 숫자가 실제로 정합되기 시작하는 유일한 방법입니다.

핵심 요약

  • CRM의 한 판매자-한 거래 모델은 파트너가 영향을 준 수익을 표현할 수 없어서, 크레딧이 조용히 사라집니다.
  • 대부분의 회사는 과대 크레딧과 과소 크레딧을 동시에 부여하고 있습니다. 하나는 재무의 신뢰를 잃게 하고, 다른 하나는 최고의 파트너를 잃게 합니다.
  • 핸드오프와 긴 시간 지연이 보통 흔적이 끊기는 지점이며, 다자간 거래는 이를 더 악화시킵니다.
  • 소싱과 영향은 서로 다른 모션입니다. 따로 측정하십시오.
  • 해결책은 다자간 데이터 모델, 발생 순간의 신호 캡처, 그리고 분기 시작 전에 합의된 크레딧 규칙입니다. 낡은 모델 위에 더 나은 대시보드를 올려서는 해결되지 않습니다.

어트리뷰션을 고치면 내부 크레딧 다툼은 대체로 사라지지만, 더 큰 성과는 수익이 실제로 어디서 오는지를 명확하게 보고 그곳에 투자할 수 있게 되는 것입니다. 파트너 신호가 수익 엔진을 통해 흐르는 방식을 다시 생각하고 있다면, Revnewo의 접근 방식은 그 접점들을 재무 앞에서 방어할 수 있는 하나의 그림으로 연결해줍니다.

See revenue orchestration in action

Unify your revenue data, signals, and plays on one AI-native platform.