마켓플레이스 코셀: 혼돈 없이 하이퍼스케일러와 함께 판매하기

AWS, Azure, Google Cloud 마켓플레이스를 통한 판매는 대부분의 B2B 소프트웨어 기업에게 있으면 좋은 것에서 이사회 수준의 우선순위로 격상되었으며, 그 이유는 타당합니다. 구매자는 이미 약정된 클라우드 지출에 대해 구매할 수 있습니다. 조달 과정이 극적으로 빨라집니다. 하이퍼스케일러의 필드 영업사원은 여러분의 팀이 몇 분기를 들여도 도달하기 힘든 자리로 여러분을 데려갈 수 있습니다. 마켓플레이스 코셀, 즉 여러분의 담당자와 클라우드 제공업체의 계정팀이 함께 딜을 진행하는 방식은 현재 B2B에서 가장 강력한 모션 중 하나입니다.

동시에 가장 혼란스러운 모션 중 하나이기도 합니다. 코셀 프로그램은 방대하고 관료적입니다. 딜 등록, 코셀 요청, 마켓플레이스 거래는 각각 자체 규칙을 가진 다른 콘솔에 존재합니다. 여러분의 담당자는 그 프로세스를 이해하지 못하고, 클라우드 영업사원의 인센티브는 불투명하며, 이 모든 것이 여러분의 CRM과 결코 맞아떨어지지 않는 데이터를 쏟아냅니다. 얼라이언스와 RevOps 리더에게 질문은 마켓플레이스 코셀을 할지 말지가 아닙니다. 운영 오버헤드가 이익을 갉아먹지 않게 하면서 어떻게 운영할 것인가입니다.

그럴 만한 가치가 있는 이유

혼란을 다루기 전에, 왜 이 모션이 그 노력을 감수할 가치가 있는지 분명히 해둘 필요가 있습니다.

약정된 지출은 예산을 풀어줍니다. 엔터프라이즈는 클라우드 제공업체에 수백만 달러를 사전 약정하며, 마켓플레이스 구매는 그 약정을 소진시킵니다. 구매자는 이미 배정된 돈을 쓰는 것이므로, 이는 다른 어떤 것도 하지 못하는 방식으로 조달 마찰을 무너뜨리고 사이클을 단축시킵니다.

클라우드 필드팀은 여러분에게 없는 도달 범위를 가지고 있습니다. 하이퍼스케일러 계정팀은 지구상 가장 큰 엔터프라이즈 내부에 상시적인 경영진 관계를 가지고 자리 잡고 있습니다. 그들의 영업사원이 여러분의 제품을 코셀할 때, 여러분은 여러분의 담당자가 콜드로 구축하는 데 1년이 걸릴 접근권을 물려받게 됩니다.

프라이빗 오퍼는 거래를 깔끔하게 정리합니다. 맞춤 가격, 협상된 조건, 표준화된 서류. 실제 클로징은 전통적인 엔터프라이즈 계약보다 단순합니다.

그 가치는 실질적이고 구조적입니다. 여러분이 방치할 경우 그것을 갉아먹는 것은 운영상의 저항입니다.

혼돈이 발생하는 지점

네 가지 원천이 반복적으로 나타납니다.

프로세스 불투명성. 이 프로그램들은 정말로 복잡합니다. 등록 기준, 코셀 자격 규칙, 인센티브 등급, 리스팅 요건 같은 것들이죠. 대부분의 담당자는 이를 결코 배우지 못하므로, 딜은 등록되지 않거나 잘못 등록되고, 코셀 혜택은 조용히 증발해버립니다.

데이터 파편화. 등록 정보는 파트너 포털에 있습니다. 코셀 상태는 여러분이 볼 수 없는 하이퍼스케일러의 CRM에 있습니다. 거래는 마켓플레이스 콘솔에 있습니다. 이 중 어느 것도 자동으로 여러분의 CRM으로 흘러들지 않으므로, 얼라이언스 팀의 누군가가 매주 손으로 전체 그림을 짜맞춰야 합니다. 이는 대부분의 CRM에서 파트너 소싱 매출이 사라지는 이유의 심각한 사례입니다. 마켓플레이스는 여러분의 시스템 오브 레코드가 원천적으로 볼 수 없는 하나의 완전한 수익 채널입니다.

인센티브 불일치. 클라우드 영업사원은 자신만의 쿼터, 자신만의 우선순위, 그리고 이번 분기에 어떤 벤더를 지원할지에 대한 자신만의 의견을 가지고 있습니다. 여러분의 담당자는 클라우드 팀이 딜을 주도할 것이라고 가정합니다. 클라우드 팀은 여러분의 담당자가 그렇게 할 것이라고 가정합니다. 둘 다 기다립니다. 딜은 정체됩니다.

어트리뷰션 혼란. 클라우드 영업사원이 관여한 딜이 마켓플레이스를 통해 성사되면, 누가 그것을 소싱했습니까? 여러분의 담당자, 클라우드 팀, 아니면 마켓플레이스 자체입니까? 이는 단일 CRM 필드가 답할 수 없는 다자간 질문이며, 코셀 어트리뷰션 문제의 직접적인 사례입니다.

효과가 있는 운영 모델

여러분은 하이퍼스케일러의 관료주의를 고칠 수 없습니다. 여러분이 할 수 있는 것은 그들의 시스템과 여러분의 시스템 사이에 얇은 운영 계층을 구축하는 것입니다. 네 가지 관행이 대부분의 일을 해결합니다.

일찍, 체계적으로 등록하십시오. 등록은 마켓플레이스 혜택이 얻어지거나 상실되는 지점이며, 마지막에 허둥지둥하기보다는 딜의 초기에 이루어져야 합니다. 이를 영업 프로세스에서 트리거되는 단계로 만드십시오. 딜이 적절한 단계에 도달하면, 담당자는 기회 정보에서 미리 채워진 필드와 함께 등록하라는 알림을 받습니다. 담당자의 기억력은 프로세스가 아닙니다.

마켓플레이스 상태를 CRM에 동기화하십시오. 이것이 목록의 다른 무엇보다 중요합니다. 코셀 상태와 마켓플레이스 거래 데이터가 여러분의 시스템 오브 레코드로 다시 흘러들게 하여, 담당자가 자신의 기회 건에서 클라우드 측 상태를 직접 볼 수 있게 하십시오. 그것이 가능해지면 조율 간극의 대부분이 자연스럽게 해소됩니다.

딜별로 소유권을 합의하십시오. 각 코셀 건마다, 여러분의 담당자와 클라우드 영업사원 중 누가 무엇을 주도하는지 명확히 하십시오. 모호함은 다른 어떤 파트너 모션에서든 핸드오프 시점에 그러하듯, 이런 딜을 중간에서 죽입니다. 파트너십이 핸드오프에서 정체되는 이유에 나오는 모든 것이 담당자와 클라우드 영업사원 관계에도 적용됩니다.

어트리뷰션을 미리 결정하십시오. 마켓플레이스와 클라우드 영업사원의 관여가 어떻게 공로를 인정받을지를 딜 이전에 확정하고, 접점이 발생하는 대로 포착하십시오. 마켓플레이스 딜이 성사되었을 때 여러분이 원하는 것은 논쟁이 아니라 기록입니다.

확장 가능하게 만들기

하나의 마켓플레이스 딜은 초인적인 노력으로 관리할 수 있습니다. 세 개의 하이퍼스케일러에 걸친 포트폴리오는 그럴 수 없습니다. 물량이 늘어남에 따라, 수작업 오버헤드(포털 확인, 등록 추적, 거래 조정, 공로에 대한 논쟁)는 여러분이 실제로 포착할 수 있는 마켓플레이스 매출의 한계가 됩니다.

이것이 마켓플레이스 코셀이 결국 수익 오케스트레이션 문제가 되는 이유입니다. 이 모션은 마켓플레이스 콘솔, 파트너 포털, 클라우드 CRM, 그리고 여러분 자신의 시스템 오브 레코드 사이의 연결이 자동화될 때만, 즉 등록이 트리거되고 상태가 동기화되며 어트리뷰션이 매번 사람이 짜맞추지 않고도 포착될 때만 확장됩니다. 모든 마켓플레이스 딜을 맞춤형 프로젝트로 취급하는 기업은 얼라이언스 팀이 개인적으로 챙길 수 있는 한도까지만 마켓플레이스 매출을 제한하게 됩니다. 이를 오케스트레이션하는 기업은 하이퍼스케일러 마켓플레이스를 진정한 채널로 전환시킵니다.

핵심 요약

• 이익은 구조적입니다. 약정된 지출, 클라우드 필드 도달 범위, 그리고 프라이빗 오퍼를 통한 더 깔끔한 거래입니다.
• 혼돈은 네 가지 원천에서 나옵니다. 불투명한 프로세스, 볼 수 없는 콘솔에 흩어진 데이터, 클라우드 영업사원과의 인센티브 불일치, 그리고 다자간 어트리뷰션입니다.
• 등록을 영업 프로세스에서 트리거되는 단계로 만드십시오. 담당자가 기억하도록 맡기지 마십시오.
• 코셀과 마켓플레이스 상태를 CRM에 반영하는 것이 다른 어떤 단일 조치보다 효과적입니다.
• 몇 건을 넘어서면, 하이퍼스케일러의 시스템과 여러분의 시스템 사이의 배관이 자동화되어야만 이 모션은 확장됩니다.

마켓플레이스 코셀은 하이퍼스케일러의 파편화된 시스템 위에 하나의 일관된 계층을 구축하는 기업에게 보상을 줍니다. 딜마다 수작업으로 관리하는 기업이 아니라요. AWS, Azure, Google Cloud에 걸쳐 확장하고 있다면, Revnewo와 같은 플랫폼이 마켓플레이스 신호를 여러분의 나머지 수익 그림으로 끌어와, 세 개의 별도 모션을 운영하지 않게 해줍니다.