PLG와 세일즈는 왜 대립하지 않는가

레슨 1에서 정리했듯 PLG는 영업 조직을 없애는 전략이 아니라, 영업이 개입하는 시점을 사용자가 이미 가치를 경험한 이후로 늦추는 전략입니다. 이번 레슨은 그 결합이 실제 워크플로우로 어떻게 구현되는지를 다룹니다. 셀프서브만으로 결제까지 이어지는 개인·소규모 팀 고객은 세일즈 개입 없이 그대로 흘러가게 두고, 엔터프라이즈급 계약이 필요한 규모의 계정만 골라 세일즈 담당자에게 넘기는 것이 이 결합의 핵심입니다.

이 구분이 필요한 이유는 자원 배분 때문입니다. 영업 담당자가 모든 무료 가입자를 하나하나 접촉하는 것은 비효율적이고, 반대로 이미 엔터프라이즈급으로 확장 중인 계정을 셀프서브로만 방치하면 그 계정이 필요로 하는 SSO·컴플라이언스·전담 지원 같은 요구를 채워주지 못해 이탈하거나 경쟁사로 넘어갈 수 있습니다. PQL은 바로 이 두 그룹을 가르는 기준선 역할을 합니다.

PQL을 세일즈로 넘기는 워크플로우는 어떻게 작동하는가

가장 효과적인 PQL 라우팅 방식은 PQL을 담당 영업 담당자의 CRM 레코드에 우선순위 작업(Task)으로 직접 밀어넣는 것입니다. 사용자가 레슨 3에서 정의한 PQL 기준을 넘으면 자동화된 워크플로우가 CRM에 사용자 이름·회사·PQL 점수·그 점수를 유발한 제품 행동 요약을 담은 작업을 생성하고, 담당자는 이를 평소 업무 흐름 안에서 확인해 맥락을 가진 채로 대화를 시작합니다.

이 워크플로우에서 중요한 것은 '맥락 전달'입니다. 영업 담당자가 아무 정보 없이 "이 계정이 PQL이 됐다"는 알림만 받으면, 실제 접촉 시 어떤 대화를 시작해야 할지 감을 잡기 어렵습니다. 반면 "이 계정은 최근 30일간 특정 기능을 15회 사용했고 팀원 3명을 초대했다"는 구체적 행동 요약이 함께 전달되면, 담당자는 그 행동에 맞춰 관련성 높은 대화를 시작할 수 있습니다. 이 맥락 데이터는 레슨 6에서 다룬 이벤트 기반 계측이 정밀하게 돼 있어야 만들 수 있습니다.

엔터프라이즈 확장 신호는 무엇을 기준으로 판단하는가

한 계정에 30일 이내 10명 이상의 사용자가 추가되고, 특히 여러 부서·이메일 도메인에 걸쳐 늘어나는 패턴은 엔터프라이즈급 확장 신호로 간주됩니다. 이런 계정은 SSO·컴플라이언스 기능·대량 관리 도구처럼 사람이 직접 안내해야 하는 고급 권한·기능이 필요한 경우가 많아, 셀프서브에서 세일즈 지원(Sales Assist)으로 전환하는 트리거로 쓰입니다.

이 신호는 개인 단위 PQL 신호(레슨 3의 반복 사용 빈도 등)와는 성격이 다릅니다. 개인 단위 신호가 "이 사용자가 결제할 가능성이 높은가"를 보는 것이라면, 계정 단위 확장 신호는 "이 조직이 셀프서브 요금제로는 감당하기 어려운 규모로 커지고 있는가"를 보는 것입니다. 두 신호를 구분해서 관리해야, 개인 결제 전환은 자동화된 셀프서브 플로우로 처리하고 조직 확장은 세일즈 개입으로 처리하는 이원화된 워크플로우를 만들 수 있습니다.

라우팅에 필요한 데이터는 어떻게 구성해야 하는가

PQL을 실제로 운영하려면 제품 사용 데이터와 CRM 적합도 데이터가 결합된 데이터 기반이 필요합니다. 제품 사용 데이터만으로는 "이 사용자가 활발히 쓰고 있다"는 것은 알 수 있어도, 그 사용자가 속한 회사가 실제로 영업이 접촉할 가치가 있는 규모·업종인지는 알 수 없습니다. 반대로 CRM의 회사 정보만으로는 그 회사 안에서 실제로 제품을 얼마나 쓰고 있는지 알 수 없습니다. 두 데이터를 연결해야 비로소 "규모도 맞고 실제로 잘 쓰고 있는 계정"을 정확히 골라낼 수 있습니다.

이 데이터 연결에는 제품 사용자 계정과 CRM 상의 회사 레코드를 매칭하는 작업(보통 이메일 도메인 기준)이 선행돼야 합니다. 이 매칭이 부정확하면 PQL 라우팅 자체가 엉뚱한 담당자에게 잘못 전달되거나, 아예 매칭되지 않아 놓치는 계정이 생길 수 있습니다. 개인 이메일(예: 지메일)로 가입한 사용자는 도메인 매칭이 애초에 불가능하므로, 이런 계정을 어떻게 처리할지(별도 스코어링 트랙을 둘지, 아예 라우팅 대상에서 제외할지)도 워크플로우 설계 초기에 정해두어야 합니다.

이 워크플로우를 도입할 때 흔히 놓치는 지점

워크플로우를 처음 구축할 때 흔히 놓치는 것은 '셀프서브로 남아야 할 계정까지 세일즈로 넘기는' 과잉 라우팅입니다. PQL 기준을 너무 느슨하게 잡으면 영업 담당자에게 매일 너무 많은 작업이 쏟아져, 정작 진짜 엔터프라이즈 신호가 있는 계정이 그 안에 묻혀버릴 수 있습니다. 레슨 3에서 강조했듯 PQL 기준은 실제 결제 전환 데이터로 검증된 것이어야 하며, 이 검증 없이 넓게 잡은 기준으로 라우팅을 시작하면 세일즈팀의 신뢰를 잃어 이후 PQL 알림 자체를 무시하게 되는 역효과가 날 수 있습니다.