확장 가능한 반복 가능한 GTM 플레이북 설계하기

모든 수익 리더는 결국 이 벽에 부딪힙니다. 처음 열 건의 거래는 창업자나 아주 뛰어난 담당자 한 명이 끝까지 끌고 갔기 때문에 성사되었습니다. 다음 백 건은 같은 경로를 따라야 하는데, 그 경로가 오직 한 사람의 머릿속에만 존재했기 때문에 그렇게 되지 않습니다. 모션이 영웅적 행동으로 운영될 때, 성장은 채용할 수 있는 영웅의 수와 그들이 일할 수 있는 시간으로 제한됩니다.

반복 가능한 GTM 플레이북은 그 암묵적이고 개인적인 지식을 유능한 담당자라면 누구나 운영할 수 있고 어떤 매니저든 코칭할 수 있는 공유 시스템으로 전환합니다. 잘 해내면, 수익은 개성이 아니라 프로세스 품질의 함수가 됩니다. 다음은 견고한 플레이북을 만드는 방법과, 각 부분에 필요한 전술적 요소들에 대한 안내입니다.

무엇이든 쓰기 전에 모션을 먼저 선택하라

이메일 템플릿 하나라도 문서화하기 전에, 플레이북이 체계화할 모션의 종류를 결정하십시오. 사용자가 유료 등급으로 셀프서비스 전환하는 제품 주도 모션은 6자릿수 ACV와 열두 명 규모의 구매 위원회를 가진 엔터프라이즈 모션과 거의 닮은 점이 없습니다. 이 둘 모두에 걸쳐 하나의 보편적인 플레이북을 작성하면 아무도 읽지 않을 만큼 일반적인 문서를 얻게 됩니다.

여전히 옵션을 저울질하고 있다면, 제품 주도 대 영업 주도 대 생태계 주도 모션에 대한 저희의 분석이 ACV, 구매자, 제품 복잡성에 모션을 맞추는 방법을 안내합니다. 그리고 여러 모션을 동시에 운영하고 싶은 유혹이 든다면, 여러 GTM 모션을 언제 층층이 쌓을지를 먼저 읽으십시오. 층층이 쌓는 것은 복잡성을 곱하며, 이를 일찍 하는 것은 저희가 봐온 팀들이 정체되는 더 흔한 방식 중 하나입니다.

모션이 그 이후의 모든 것을 결정합니다. 누가 첫 접점인지, 사이클이 얼마나 지속되는지, 어떤 신호가 중요한지, "자격을 갖췄다"는 것이 무엇을 의미하는지까지요.

종료 기준을 갖춘 단계

확장 가능한 플레이북은 각각 명확한 진입 및 종료 기준을 가진 일련의 단계입니다. 모호한 단계("진행 중이에요")는 예측이 죽는 곳입니다. 정확한 단계는 모두에게 공유된 언어를 주고 파이프라인 리뷰를 빠르게 진행시킵니다.

각 단계에 대해, 거래가 여기 있기 위해 무엇이 참이어야 하는지(경제적 구매자가 확인됨, 고충이 정량화됨), 여기 있는 동안 담당자의 역할이 무엇인지, 그리고 다음으로 이동할 준비가 되었다는 것을 보여주는 관찰 가능한 증거가 무엇인지 적어두십시오.

결과를 기술하십시오. "후속 조치 보내기"는 활동입니다. "구매자가 예산과 일정을 서면으로 확인함"은 결과입니다. 활동은 입력값이고, 반복 가능한 플레이북은 산출물에 의해 운영됩니다. 종료 기준이 객관적일 때, 같은 거래를 보는 두 담당자는 같은 등급을 매길 것입니다. 그 일관성이야말로 담당자가 네 명이 아니라 마흔 명이 되었을 때 예측과 코칭을 가능하게 하는 것입니다.

플레이 라이브러리

플레이북 설계에서 가장 큰 실수는 경직된 선형 스크립트를 작성하고 거래가 그것을 따르기를 기대하는 것입니다. 거래는 갈라집니다. 사용 가능한 플레이북은 눈앞의 상황에 맞게 조합하는 독립적인 플레이들의 라이브러리입니다.

좋은 플레이에는 트리거, 타깃, 일련의 행동, 그리고 정의된 성공 결과가 있습니다. 높은 전환율을 내는 세일즈 플레이의 해부에 대한 저희의 가이드가 그 구조를 분석합니다. 대부분의 거래에서 반복되는 순간들에 대한 플레이를 구축하십시오. 고충을 표면화하고 정량화하는 디스커버리 플레이, 단일 챔피언을 넘어서기 위한 다중 채널 플레이, 기존 업체가 자리 잡고 있을 때의 경쟁 대체 플레이, 그리고 조용해진 거래를 위한 재참여 플레이입니다.

플레이가 모듈형이기 때문에, 담당자는 모든 거래가 동일하다고 가정하는 스크립트를 그대로 밟아나가는 대신 섞고 조합합니다. 이는 또한 플레이북이 진화할 수 있게 합니다. 하나의 플레이가 더 이상 작동하지 않으면, 그 모듈 하나만 교체하십시오. 시스템 전체를 다시 쓸 필요가 없습니다.

계측하지 않으면 그것은 위키 페이지일 뿐이다

측정할 수 없는 플레이북은 제안일 뿐입니다. 아무도 열어보지 않는 위키 페이지와 살아 있는 시스템을 구분하는 것은 계측입니다. 단계별, 플레이별로 무엇이 전환되고 무엇이 새고 있는지 볼 수 있어야 합니다.

바로 여기서 대부분의 정적인 플레이북이 무너지며, 그래서 그토록 많은 세일즈 플레이가 현장에서 조용히 죽는 이유입니다. 서류상으로는 훌륭해 보이는데도 말입니다. 해결책은 플레이북을 실시간 신호에 연결하는 것입니다. 어떤 플레이가 발동되는지, 어떤 것이 건너뛰어지는지, 거래가 어디서 정체되는지, 구매자 행동이 결과에 어떻게 매핑되는지를 봐야 합니다. Revnewo와 같은 수익 오케스트레이션 플랫폼은 정확히 이 간극을 메우기 위해 존재하며, 담당자가 추측하도록 남겨두는 대신 실시간 구매 신호로부터 다음 최선의 행동을 표면화합니다. 문서에서 동적 시스템으로의 이동은 충분히 큰 전환이라서 정적 플레이북에서 동적 오케스트레이션으로에서 별도로 다룹니다.

어떤 도구를 사용하든, 모든 단계를 계측하고, 데이터를 매주 살펴보고, 플레이북을 한 번 발행하고 잊어버리는 정책이 아니라 계속 반복 개선하는 제품으로 취급하십시오.

핵심 요약

• 모션을 먼저 선택하십시오. 플레이북은 하나의 특정 모션을 위해 구축될 때만 확장됩니다.
• 단계에는 결과로 작성된 객관적인 종료 기준이 필요하며, 그래야 어떤 두 담당자든 거래를 동일하게 등급 매길 수 있습니다.
• 모듈형 플레이 라이브러리를 구축하십시오. 실제 거래는 갈라지며, 선형 스크립트로는 따라갈 수 없습니다.
• 측정할 수 없다면 그것은 문서입니다. 실시간 신호에 연결하고 매주 검토하십시오.

반복 가능한 플레이북은 영역 설계부터 고객 핸드오프까지, 수익 조직의 나머지 모든 것이 그 위에 놓이는 토대입니다. 정적인 문서에서 딜이 움직임에 따라 적응하는 시스템으로 옮겨갈 준비가 되었다면, 수익 오케스트레이션이 좋은 플레이북을 실제로 실행되는 무언가로 만드는 방법입니다.