정직함을 유지하는 B2B 창업자를 위한 영업 파이프라인 스키마

왜 대부분의 초기 파이프라인은 신뢰성을 잃는가

초기에는 거래 수가 적고 대부분의 맥락이 머릿속에 있어 파이프라인이 명확해 보입니다. 하지만 목록이 늘고 팔로업을 놓치면 파이프라인은 현실보다 더 좋은 이야기를 하게 됩니다. 이것이 바로 '파이프라인의 거짓말'입니다: 의도적인 게 아니라 시스템에서 진실을 강제하지 않기 때문입니다.

다음과 같은 패턴으로 나타납니다:

• 거래가 최근 활동 없이 몇 주 동안 같은 단계에 머문다.
• “다음 단계”가 "다음 주 다시 확인"처럼 모호해진다.
• 마감일이 구매자가 합의한 일정이 아니라 희망적으로 미뤄진다.

일반적인 반응은 CRM을 과도하게 확장하는 것입니다: 필드와 커스텀 단계, 긴 노트를 더 추가하죠. 아이러니하게도 이는 보통 예측을 더 악화시킵니다. 업데이트가 번거로우면 사람들은 덜 업데이트하고 파이프라인은 소리 없이 썩습니다.

최소 실행 가능한 영업 파이프라인 스키마는 그 반대입니다. 의사결정을 내리기에 충분한 최소한의 구조만 제공합니다. 모든 것을 담으려 하지 않습니다. 자신을 속이지 않게 하는 몇 가지 사실만 담습니다.

한 가지 규칙만 쓴다면 이걸 사용하세요: 모든 열린 딜은 (1) 명시적인 다음 행동, (2) 그 행동의 날짜, (3) 회의·법무 단계·예산 검토 같은 실제 구매자 일정에 연동된 마감일을 가져야 합니다. 이 중 하나라도 없으면 그 딜은 활성 딜이 아닙니다.

단계는 또한 의미가 있어야 합니다. 어떤 거래는 기분 때문에 전진하는 것이 아니라 구체적인 일이 일어났을 때만 이동해야 합니다. 목표는 예쁜 대시보드가 아니라 비즈니스를 운영할 수 있는 정직한 뷰입니다.

필드와 단계를 선택하기 전에 규칙을 정하세요

영업 파이프라인 스키마는 모두가 같은 방식으로 다룰 때만 작동합니다. 필드를 추가하거나 단계에 대해 논쟁하기 전에 하나의 파이프라인 항목이 무엇을 의미하는지 결정하세요.

B2B에 대한 깔끔한 기본값은: 한 딜은 한 구매 결정이다. 같은 회사가 두 번 살 수 있다면(두 팀, 두 제품, 두 예산), 그건 두 개의 딜이지 하나의 뒤섞인 레코드가 아닙니다.

객체를 단순하게 유지하세요. 리드(연락 가능한 사람), 계정(회사), 딜(구체적 구매) 세 버킷으로도 충분히 시작할 수 있습니다. 혼자라면 정식 리드와 계정 레코드를 건너뛰고 각 딜에 회사와 주요 연락처를 명확히 적어두는 것만으로도 괜찮습니다.

특히 파이프라인을 본인이 아닌 다른 사람이 건드릴 가능성이 있다면 몇 가지 운영 규칙을 문서화하세요:

• 활동은 발생 직후 기록하세요.
• 정해진 시간에 주간 검토를 하세요.
• 각 딜에 정확히 한 명의 소유자를 지정하세요.
• 단일 진실 소스를 사용하세요: 파이프라인에 없으면 발생하지 않은 것입니다.

예시: Northwind의 Alex와 재무팀 파일럿에 대해 이야기했다면 그건 한 딜입니다. 한 달 후 제품팀이 별도 계약을 원하면 두 번째 딜을 만드세요. 한 레코드에 두 결정을 억지로 넣지 마세요.

최소 실행 가능한 딜 필드(실제로 사용하는 것들)

파이프라인은 각 딜에 매주 확인하는 소수의 필드만 있을 때 유용합니다. 혹시 몰라서 필드를 추가하면 장식이 됩니다.

중복을 방지하는 딜 이름 형식부터 시작하세요. 간단한 패턴이 효과적입니다: 회사 - 제품/범위 - 분기/월. 예: “Acme - Team plan - 2026년 3월.” 이렇게 하면 “Acme - Demo”와 “Acme - Follow-up”이 사실상 같은 딜인지 명확해집니다.

각 딜에는 또한 명확한 정체성이 필요합니다:

• 계정/회사
• 주요 연락처
• 연락처 역할(의사결정자, 챔피언, 재무, IT)

역할은 다음에 취할 행동을 바꿉니다. 챔피언은 활성화가 필요하고, 의사결정자는 비즈니스 케이스가 필요합니다.

책임 소재 필드를 추가하세요:

• 딜 소유자(한 사람)
• 소스(인바운드, 아웃바운드, 파트너, 추천, 이벤트)

그다음 실제로 사용할 금액과 일정만 추가하세요:

• 예상 가치와 딜 타입(신규, 확장, 갱신)
• 목표 마감일("언젠가"가 아닌 구체적 날짜)
• 확률은 신뢰하는 주간 예측에 사용한다면 추가하세요

필드가 확실치 않다면 일단 빼세요. 나중에 언제든 추가할 수 있습니다. 습관이 생긴 뒤에 필드를 제거하는 건 훨씬 어렵습니다.

환상을 막는 자격(퀄리파잉) 필드

많은 "큰" 파이프라인은 사실 크지 않습니다. 구매로 이어질 명확한 경로가 없는 보기 좋은 딜로 가득합니다.

명확성을 강제하는 한 가지 필드부터 시작하세요: 사용 사례(범위). 구매자가 달성하려는 바를 평이한 문장으로 쓰고, 완료가 어떤 모습인지 적으세요. 결과를 두 문장으로 설명할 수 없다면 딜을 아직 충분히 이해하지 못한 것입니다.

다음으로 의사결정 과정을 한 곳에 기록하세요. 이는 연락처 나열이 아닙니다. 누가 서명하고 누가 막을 수 있는지, 어떤 단계들이 필요한지(보안 검토, 법무, 조달 등)를 이야기 형태로 적으세요. 서명자를 모르면 딜을 초기로 취급하세요.

대략적인 가격 적합성 신호도 캡처하세요. 범위(“< $5k”, “$5-25k”, “$25k+”)나 Likely / Unclear / Unlikely 같은 간단한 표기가 충분합니다. 요점은 감당할 수 없는 고객을 계속 전진시키지 않는 것입니다.

마지막으로 레드 플래그 필드를 한 줄로 유지하세요. 한 단락이 필요하면 노트에 넣으세요.

대부분의 B2B 창업자에게 적합한 간결한 세트:

• 사용 사례 + 성공 기준
• 의사결정 과정(서명자, 영향자, 단계)
• 가격 적합성(범위 또는 Likely/Unclear/Unlikely)
• 경쟁 옵션(명시된 경쟁자 또는 "현상 유지")
• 레드 플래그(한 줄)

예: “갱신 전 CRM 정리가 필요함, 서명자 = VP Sales, 보안 검토 필요, 예산 대략 $10-20k, 경쟁 옵션은 아무것도 안 함, 레드 플래그: 챔피언이 프로젝트를 소유하지 않음.” 이런 단일 레코드는 스스로를 속이기 어렵게 만듭니다.

파이프라인을 정직하게 유지하는 활동 추적

파이프라인이 망가지는 이유는 위시리스트가 되기 때문입니다. 해결책은 더 많은 필드가 아니라 몇 가지 활동 신호로 모든 딜이 한 가지 질문에 답하게 만드는 것입니다: 다음에는 무엇이 일어나는가?

스키마에 한 가지 층만 더 추가한다면 다음 활동 필드를 추가하세요:

• 마지막 활동 날짜(자동이면 좋고, 수동이어도 괜찮음)
• 다음 단계("팔로업"이 아닌 구체적 행동)
• 다음 단계 기한(실제 날짜)
• 마지막 접점 채널(전화, 이메일, 미팅, 데모, 채팅)
• 실패 이유(짧은 드롭다운, 선택적 한 문장 노트)

실용적 규칙: 딜에 다음 단계나 기한이 없으면 그 딜은 진짜 딜이 아닙니다. 보류하거나 종료하세요. 이는 어떤 스코어링 모델보다 예측 정확성에 더 기여합니다.

"실패 이유"는 짧게 유지하세요: 가격, 예산 없음, 결정 없음, 경쟁사 선택, 타이밍, 적합하지 않음 등.

실제 모습 예시: 화요일에 ops 리드와 데모가 있습니다. 통화 직후 마지막 활동 날짜 = 화요일, 마지막 접점 채널 = 미팅, 다음 단계 = "사례 연구 2건 전송하고 누가 서명하는지 확인", 다음 단계 기한 = 목요일로 설정합니다. 목요일에 답이 없으면 딜은 아무도 "진행"이라고 주장하지 못하게 자동으로 빨간색 신호가 됩니다.

대부분의 B2B 창업자에게 적합한 단순한 단계 모델

좋은 단계 모델은 한 가지 일을 제대로 합니다: 각 딜이 어디에 있는지 사실대로 알려주되 열 개의 사소한 단계를 돌보게 만들지 않는 것입니다. 어떤 거래가 어느 단계에 있어야 하는지 사실로 말할 수 없다면 그 단계는 느낌이 됩니다.

다음 여섯 단계 설정은 대부분의 B2B 창업자에게 효과적입니다:

1. New: 이름과 연락할 이유가 있음. 첫 접촉이 완료되었거나 예정됨.

2. Qualified: 기본 적합성이 확인됨. 문제가 실제이며 고객이 ICP에 맞고 구매할 그럴듯한 경로가 있음.

3. Discovery done: 실제 대화를 했음. 사용 사례, 성공 기준, 관련자가 파악됨.

4. Proposal sent: 가격과 범위가 고객에게 전달됨. 다음 단계가 예약되었거나 명시적으로 요청됨.

5. Negotiation/Legal: 조달, 보안, 예산 승인 또는 계약 수정이 진행 중임.

6. Closed won / Closed lost: 결과가 표시되고 이유가 캡처됨.

실제 세상에서 무언가가 발생했을 때만 딜을 전진시키세요(미팅 완료, 제안서 발송, 법무 시작 등). 아무 일도 없었다면 단계는 그대로 둡니다.

거래가 표류하지 않게 하는 단계 정의

단계 이름만으로는 충분하지 않습니다. "Qualified"나 "Negotiation" 같은 라벨만 붙이면 누군가가 무엇이 "완료"인지 합의하지 못해 거래가 그곳에 멈춰 있게 됩니다.

단계 규칙을 간단한 진위 검사(true/false)로 작성하세요. 단계에 있는 모든 딜이 같은 사실을 공유하면 파이프라인은 신뢰할 만해집니다.

감(直感)이 아닌 진입/퇴출 기준을 사용하세요

진입 기준은 딜이 단계에 들어가기 전에 이미 무엇이 사실이어야 하는지 말합니다. 퇴출 기준은 앞으로 나아가기 위해 무엇이 바뀌어야 하는지 말합니다. 둘 다 짧고 측정 가능하게 유지하세요.

예시:

• Discovery: 첫 라이브 대화가 완료된 후에만 진입; 문제 진술과 다음 미팅 예약이 완료되어야만 퇴출.
• Proposal sent: 가격이 명시된 제안이 실제로 전송된 경우에만 진입; 구매자가 검토 중이며 결정 날짜가 있는 경우에만 퇴출.
• Legal/procurement: 구매자가 프로세스나 이해관계자를 소개했을 때 진입; 최종 수정안이나 구매 주문 단계가 있을 때 퇴출.

"좋음", "강함", "관심 있음" 같은 단어 없이 기준을 쓸 수 없다면 그 단계는 너무 모호합니다.

단계별 최대 체류일 규칙 추가

각 단계에 최대 연령을 설정하고 이를 초기 경고로 삼으세요. 예: Discovery 최대 14일, Proposal 최대 21일. 딜이 한계에 도달하면 리셋을 트리거하세요: 다음 단계를 예약하거나 뒤로 이동시키거나 종료합니다.

기준이 충족되지 않을 때의 기본 동작을 결정하세요:

• 부족한 정보를 여전히 모을 수 있으면 뒤로 이동.
• 명확한 팔로업 규칙(예: 10 영업일 동안 3회 시도 후)에도 반응이 없으면 종료로 처리.

이는 "좀비 딜"이 예측을 부풀리는 것을 막습니다.

한 오후만 투자하면 스키마를 구축할 수 있습니다

스키마는 작은 제품처럼 다루면 몇 시간 안에 만들 수 있습니다: 먼저 규칙을 정하고 그 규칙을 지원하는 것만 만드세요.

도구 안에서 시작하지 말고 빈 페이지에서 시작하세요. 단계와 진입/퇴출 기준을 평이한 영어(또는 팀 언어)로 적으세요. 단계 하나를 한 문장으로 설명하지 못하면 그건 아마 두 단계이거나 단계가 아닙니다.

간단한 구축 흐름:

• 5~8단계를 초안으로 작성하고 각 단계마다 명확한 '완료' 테스트를 하나 둡니다.
• 최소 필드 세트(목표 10~15개)를 만듭니다. 검증 가능한 사실에 집중하세요.
• 활동 추적을 추가하고 활성 단계에서는 "다음 단계 기한"을 필수로 만드세요.
• 현재 딜을 가져와 정리하면서 가져오세요: 중복 병합, 오래된 "언젠가" 항목 삭제, 소유자 누락 수정.
• 변경 전 2~4주 동안 주간 검토를 실행하세요.

설정 중 현실적인 테스트 하나를 하세요: 현재 작업 중인 딜 하나를 단계별로 이동시켜 보세요. 계속 추측하게 된다면 기준이 너무 모호한 것입니다.

초기에 적용할 규칙 하나: 다음 활동 날짜가 비어 있으면 딜은 활성 단계에 머무를 수 없습니다.

CRM 비대화를 만드는 흔한 실수

대부분의 CRM 비대화는 좋은 의도에서 시작됩니다: 더 정확하게 만들려고 필드와 단계를 추가하고 노트를 많이 남기죠. 결과는 반대입니다. 사람들은 업데이트를 중단하고 파이프라인은 거래가 숙성되는 장소가 됩니다.

1) 느낌만 다른 단계들

두 단계가 같은 느낌이라면 사람들은 똑같이 사용할 것입니다. "Discovery", "Deep discovery", "Discovery follow-up"은 종종 "대화를 나눴다"는 의미일 뿐입니다. 단계는 실제로 무언가가 변할 때만 바뀌어야 합니다.

간단한 테스트: 단계에 들어가기 위해 무엇이 사실이어야 하는지 한 문장으로 말할 수 없으면 그 단계는 아마 불필요합니다.

2) 마감일이 희망 날짜가 되는 경우

마감일은 이유에 연동되어 있을 때만 유용합니다. 예: 예산 승인, 조달 회의, 서명 기한 같은 다음 결정 시점 날짜로 취급하고, 그 이벤트가 이동하면 마감일도 이동시키세요.

3) 활동이 긴 노트로 저장되는 경우

긴 노트는 필요한 한 가지를 숨깁니다: 마지막에 무슨 일이 일어났고 다음에 무슨 일이 일어나는가. 노트는 짧게 유지하고 마지막 활동 날짜와 다음 단계(담당자 및 기한 포함)로 활동을 추적하세요.

4) 모든 것이 "Qualified"로 표기되는 경우

정의가 없으면 "Qualified"는 "그들이 괜찮아 보였다"가 됩니다. 반드시 충족해야 할 3~4개의 체크(문제, 구매자, 일정, 예산 형태)를 고르세요. 하나라도 없으면 아직 Qualified가 아닙니다.

5) 딜이 절대 Closed lost가 되지 않는 경우

항상 성장하는 파이프라인은 파이프라인이 아니라 묘지가 됩니다. 활동이 없거나 적합하지 않으면 빠르게 Closed lost로 처리하고 한 가지 명확한 이유를 캡처해 배우세요.

파이프라인 위생을 위한 주간 체크리스트

매주 같은 시간(30분이면 충분)을 정하고 미래의 자신과의 미팅처럼 다루세요. 파이프라인 위생은 필드를 더 추가하는 것이 아니라 각 딜에 여전히 실질적 진행 경로가 있는지 확인하는 일입니다.

간단한 검토 흐름:

• 열린 딜마다 명시된 주요 연락처와 한 문장짜리 문제 진술이 있는지 확인하세요.
• 모든 딜에 하나의 다음 단계와 기한이 있는지 확인하세요.
• 정체 규칙 적용: 의미 있는 활동이 7~14일간 없으면 딜을 뒤로 이동시키거나 당분간 "결정 없음"으로 닫으세요.
• 체류 기간별로 정렬해 가장 오래된 다섯 개에 대해 결정을 강제하세요.
• 상위 열 개 딜에 대해 예측 타당성 점검: 왜 닫힐지 한 문장으로 설명하고 무엇이 블로킹할 수 있는지 적으세요.

구체적 예시: 딜이 "Proposal sent"로 표시되어 있지만 검토할 미팅이 예약되지 않았다면 그것은 제안 단계 딜이 아닙니다. 뒤로 이동시키고 다음 단계를 설정한 뒤 구매자가 다시 관여할 때까지 카운트하지 마세요.

예시 시나리오: 첫 통화부터 서명까지 한 딜

당신이 50명 규모의 이커머스 회사에 B2B 분석 도구를 판매한다고 합시다. 첫 통화 후 딜을 만들고 다음 주에 실제로 쓸 정보만 채웁니다. 단순한 스키마는 서류 작업이 아니라 명확성을 강제하기 때문에 효과가 납니다.

통화 직후 기록은 다음과 같습니다:

• 문제: 주간 리포팅에 6~8시간 소요, 팀 간 수치 불일치
• 이해관계자: 스폰서 = Head of Ops; 의사결정자 = CFO; 사용자 = Analyst
• 다음 단계: 2페이지 요약 전송 + 30분 데모 예약
• 다음 단계 날짜: 1월 23일 화요일
• 목표 마감일: 2월 15일

딜은 Discovery에서 시작합니다. 캘린더 초대가 수락될 때만 다음 단계로 이동하세요(누군가 "관심 있어 보인다"고 해서가 아님). 데모 후에는 평가로 이동하는 트리거가 구체적 요청(예: "Shopify와 창고 데이터를 연결할 수 있나요?")이어야 하며 기술적 확인이 뒤따릅니다.

이제 정체가 발생합니다: 가격 제시 후 CFO가 조용해집니다. 로그에는 두 번의 팔로업, 회신 없음, 다음 단계 날짜 경과가 기록되어 있습니다. 규칙은 단순합니다: 명확한 다음 단계가 없으면 딜은 Proposal에 머무를 수 없습니다.

정직한 결정을 내리세요: 추가 스폰서나 정보가 필요하면 평가로 되돌리거나, 의사결정자가 정해진 날짜까지 반응하지 않으면 Closed lost로 마감하세요. 이 예시에서는 뒤로 이동시키고 이해관계자를 업데이트(Ops가 재무 매니저를 끌어들임), 새 다음 단계 날짜 설정, CFO가 결정 미팅을 확인해야만 Proposal로 다시 올립니다.

작게 유지하고 반복되는 부분만 자동화하세요

파이프라인 스키마는 신뢰할 수 있어야 작동합니다. 가장 빠른 방법은 최소로 시작해 30일 동안 그대로 운영하는 것입니다. 그러면 실제로 사용하는 것이 무엇인지 보입니다.

첫 달은 엄격하게 운영하세요: 필드가 결정에 영향을 주지 않으면 제거하세요. 결정이 반복적으로 나오고 파이프라인에서 답을 못 얻는다면 해당 갭을 메우는 필드를 단 하나만 추가하세요.

새 필드를 추가하기 전의 간단한 테스트: "이 필드가 비어 있으면 우리가 ___ 할지 결정할 수 없는가?"

일반적인 CRM 대신 가벼운 커스텀 CRM을 만들고 싶다면, Koder.ai (koder.ai) 같은 도구가 단계, 필수 필드, 검증 규칙을 작성한 후에 도움이 될 수 있습니다. 스키마가 명확할 때 단순한 앱을 생성하고 반복하는 것이 훨씬 쉽습니다.