12CODE
지금 읽는 곳 PLG와 세일즈는 왜 대립하지 않는가 1 / 5
12code 라이브러리 아티클 표지. PLG 기반 세일즈 연동: PQL 지표를 달성한 기업 계정을 자동으로 세일즈 팀(영업망)에 전달해 엔터프라이즈 계약을 유도하는 워크플로우

PLG 기반 세일즈 연동: PQL 지표를 달성한 기업 계정을 자동으로 세일즈 팀(영업망)에 전달해 엔터프라이즈 계약을 유도하는 워크플로우

PLG는 영업을 없애는 전략이 아니라 영업의 타이밍을 바꾸는 전략입니다 — 그 타이밍을 자동으로 잡아주는 것이 이번 레슨의 워크플로우입니다.

이 과목 09 / 11편 고급 3분
과목 ID128
트랙STEP 3 고급·전략
모듈3-3. 그로스해킹·CRM 전략
레슨09
난이도고급
플랫폼제품 주도 성장(PLG)
발행일2026-08-29
검토일2026-08-29
관련 과목126 · 127
출처2건
핵심요약5개
01

PLG와 세일즈는 대립하지 않으며, PQL 기준을 넘은 계정을 세일즈로 넘기는 것이 결합 방식이다

02

PQL 라우팅의 핵심은 CRM에 우선순위 작업으로 자동 생성해 담당자 워크플로우에 바로 얹는 것이다

03

계정에 30일 내 10명 이상 사용자가 늘고 여러 부서에 걸쳐 확산되면 엔터프라이즈 확장 신호로 본다

04

셀프서브로 남는 사용자와 세일즈로 전환되는 사용자를 명확히 구분해야 자원 낭비를 막는다

05

라우팅에는 제품 사용 데이터와 CRM 적합도 데이터가 함께 필요하다

01

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

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

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

02

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

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

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

03

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

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

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

04

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

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

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

05

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

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

다음 행동

현재 PQL(또는 그에 준하는 진성 유저) 기준으로 지난 한 달간 몇 개의 계정이 식별됐는지, 그 계정들이 실제로 영업팀에 전달됐는지 확인해보세요. 전달 체계가 없다면 다음 레슨(실험 설계)에서 다룰 통계적 검증에 앞서, 이 라우팅 워크플로우부터 최소 형태로라도 갖추는 것이 우선순위입니다.

다음 글 · 레슨 10→실험 설계 및 판정 기준: 무료 체험 유저 대상 인앱 팝업 메시지 노출 시점 변경(로그인 즉시 vs 특정 기능 사용 후)에 따른 최종 결제 전환율 유의성 검증

← 이전 글 · 레슨 08 실패 사례 분석: 유료화 전환 허들(Paywall)을 지나치게 높게 설정해 유저들이 무료 기능만 쓰다 대량 이탈하거나, 반대로 너무 다 퍼주어 매출이 제로가 된 사례

출처

facts 항목 기준 · 본문 인라인 미표기2건
F-01Kissmetrics — The Product-Led Sales Workflow: Using Analytics Signals to Prioritize Outreach업계
F-02RevenueHero — Why PLG Companies Need Sales Assist (And How to Make It Work)업계

플랫폼 기능·심의 기준·가격·법률은 바뀝니다. 이 글은 2026-08-29에 위 출처를 기준으로 확인했습니다.

CHALLENGE

배운 걸 실전 문제로 확인

카테고리별 Level Test로 실무 레벨을 점검해보세요.

챌린지 보기 →
이 과목의 게시글11편
01광고 없는 성장의 메커니즘: 마케팅 예산을 태우기 전, 제품 경험(UX) 자체가 스스로 유저를 데려오게 만드는 PLG의 정의02프리미엄(Freemium) 모델 설계: 핵심 기능은 무료로 개방하되, 엔터프라이즈 기능이나 용량 제한(Paywall)을 거는 최적의 시점 도출03PQL(Product Qualified Lead) 정의: 가입 후 첫 일주일 동안 특정 기능을 5회 이상 사용해 '스스로 유료 결제 확률이 높아진 진성 유저' 판정 지표04인앱 넛지(In-app Nudge)와 툴팁 기획: 마케터의 개입 없이 유저가 스스로 제품 사용법을 깨우치도록 돕는 인터랙티브 온보딩 가이드05네트워크 효과(Network Effects) 이식: 노션의 페이지 공유, 슬랙의 팀원 초대처럼 협업과 공유가 필수적인 제품 내 바이럴 루프 설계06데이터 요건: Amplitude, Mixpanel 등 유저 행동 분석 솔루션 연동을 통한 인앱 기능별 사용 빈도 및 이탈 퍼널 정밀 계측07한계 정의: 제품력 지향 특성상 초기 인프라/개발 리소스 투입 비용이 극대화되며, 브랜드 인지도가 전무한 초기 시장에서의 초기 유저 획득 한계08실패 사례 분석: 유료화 전환 허들(Paywall)을 지나치게 높게 설정해 유저들이 무료 기능만 쓰다 대량 이탈하거나, 반대로 너무 다 퍼주어 매출이 제로가 된 사례09PLG 기반 세일즈 연동: PQL 지표를 달성한 기업 계정을 자동으로 세일즈 팀(영업망)에 전달해 엔터프라이즈 계약을 유도하는 워크플로우10실험 설계 및 판정 기준: 무료 체험 유저 대상 인앱 팝업 메시지 노출 시점 변경(로그인 즉시 vs 특정 기능 사용 후)에 따른 최종 결제 전환율 유의성 검증11발행 전 확인 항목: 믹스패널/앰플리튜드 라이선스 비용 산정 기준(MTU 또는 이벤트 수 기반) 및 자사 앱 데이터 연동 안정성 공식 확인 과목 전체 보기 →

MKT TOOLS

실무자를 위한 무료 도구

카피 글자수 검사, CPC·ROAS 계산기, UTM 생성기까지.

워크스페이스 열기 →