왜 대부분의 초기 파이프라인은 신뢰성을 잃는가\n\n초기에는 거래 수가 적고 대부분의 맥락이 머릿속에 있어 파이프라인이 명확해 보입니다. 하지만 목록이 늘고 팔로업을 놓치면 파이프라인은 현실보다 더 좋은 이야기를 하게 됩니다. 이것이 바로 '파이프라인의 거짓말'입니다: 의도적인 게 아니라 시스템에서 진실을 강제하지 않기 때문입니다.\n\n다음과 같은 패턴으로 나타납니다:\n\n- 거래가 최근 활동 없이 몇 주 동안 같은 단계에 머문다.\n- “다음 단계”가 "다음 주 다시 확인"처럼 모호해진다.\n- 마감일이 구매자가 합의한 일정이 아니라 희망적으로 미뤄진다.\n\n일반적인 반응은 CRM을 과도하게 확장하는 것입니다: 필드와 커스텀 단계, 긴 노트를 더 추가하죠. 아이러니하게도 이는 보통 예측을 더 악화시킵니다. 업데이트가 번거로우면 사람들은 덜 업데이트하고 파이프라인은 소리 없이 썩습니다.\n\n최소 실행 가능한 영업 파이프라인 스키마는 그 반대입니다. 의사결정을 내리기에 충분한 최소한의 구조만 제공합니다. 모든 것을 담으려 하지 않습니다. 자신을 속이지 않게 하는 몇 가지 사실만 담습니다.\n\n한 가지 규칙만 쓴다면 이걸 사용하세요: 모든 열린 딜은 (1) 명시적인 다음 행동, (2) 그 행동의 날짜, (3) 회의·법무 단계·예산 검토 같은 실제 구매자 일정에 연동된 마감일을 가져야 합니다. 이 중 하나라도 없으면 그 딜은 활성 딜이 아닙니다.\n\n단계는 또한 의미가 있어야 합니다. 어떤 거래는 기분 때문에 전진하는 것이 아니라 구체적인 일이 일어났을 때만 이동해야 합니다. 목표는 예쁜 대시보드가 아니라 비즈니스를 운영할 수 있는 정직한 뷰입니다.\n\n## 필드와 단계를 선택하기 전에 규칙을 정하세요\n\n영업 파이프라인 스키마는 모두가 같은 방식으로 다룰 때만 작동합니다. 필드를 추가하거나 단계에 대해 논쟁하기 전에 하나의 파이프라인 항목이 무엇을 의미하는지 결정하세요.\n\nB2B에 대한 깔끔한 기본값은: 한 딜은 한 구매 결정이다. 같은 회사가 두 번 살 수 있다면(두 팀, 두 제품, 두 예산), 그건 두 개의 딜이지 하나의 뒤섞인 레코드가 아닙니다.\n\n객체를 단순하게 유지하세요. 리드(연락 가능한 사람), 계정(회사), 딜(구체적 구매) 세 버킷으로도 충분히 시작할 수 있습니다. 혼자라면 정식 리드와 계정 레코드를 건너뛰고 각 딜에 회사와 주요 연락처를 명확히 적어두는 것만으로도 괜찮습니다.\n\n특히 파이프라인을 본인이 아닌 다른 사람이 건드릴 가능성이 있다면 몇 가지 운영 규칙을 문서화하세요:\n\n- 활동은 발생 직후 기록하세요.\n- 정해진 시간에 주간 검토를 하세요.\n- 각 딜에 정확히 한 명의 소유자를 지정하세요.\n- 단일 진실 소스를 사용하세요: 파이프라인에 없으면 발생하지 않은 것입니다.\n\n예시: Northwind의 Alex와 재무팀 파일럿에 대해 이야기했다면 그건 한 딜입니다. 한 달 후 제품팀이 별도 계약을 원하면 두 번째 딜을 만드세요. 한 레코드에 두 결정을 억지로 넣지 마세요.\n\n## 최소 실행 가능한 딜 필드(실제로 사용하는 것들)\n\n파이프라인은 각 딜에 매주 확인하는 소수의 필드만 있을 때 유용합니다. 혹시 몰라서 필드를 추가하면 장식이 됩니다.\n\n중복을 방지하는 딜 이름 형식부터 시작하세요. 간단한 패턴이 효과적입니다: 회사 - 제품/범위 - 분기/월. 예: “Acme - Team plan - 2026년 3월.” 이렇게 하면 “Acme - Demo”와 “Acme - Follow-up”이 사실상 같은 딜인지 명확해집니다.\n\n각 딜에는 또한 명확한 정체성이 필요합니다:\n\n- 계정/회사\n- 주요 연락처\n- 연락처 역할(의사결정자, 챔피언, 재무, IT)\n\n역할은 다음에 취할 행동을 바꿉니다. 챔피언은 활성화가 필요하고, 의사결정자는 비즈니스 케이스가 필요합니다.\n\n책임 소재 필드를 추가하세요:\n\n- 딜 소유자(한 사람)\n- 소스(인바운드, 아웃바운드, 파트너, 추천, 이벤트)\n\n그다음 실제로 사용할 금액과 일정만 추가하세요:\n\n- 예상 가치와 딜 타입(신규, 확장, 갱신)\n- 목표 마감일("언젠가"가 아닌 구체적 날짜)\n- 확률은 신뢰하는 주간 예측에 사용한다면 추가하세요\n\n필드가 확실치 않다면 일단 빼세요. 나중에 언제든 추가할 수 있습니다. 습관이 생긴 뒤에 필드를 제거하는 건 훨씬 어렵습니다.\n\n## 환상을 막는 자격(퀄리파잉) 필드\n\n많은 "큰" 파이프라인은 사실 크지 않습니다. 구매로 이어질 명확한 경로가 없는 보기 좋은 딜로 가득합니다.\n\n명확성을 강제하는 한 가지 필드부터 시작하세요: 사용 사례(범위). 구매자가 달성하려는 바를 평이한 문장으로 쓰고, 완료가 어떤 모습인지 적으세요. 결과를 두 문장으로 설명할 수 없다면 딜을 아직 충분히 이해하지 못한 것입니다.\n\n다음으로 의사결정 과정을 한 곳에 기록하세요. 이는 연락처 나열이 아닙니다. 누가 서명하고 누가 막을 수 있는지, 어떤 단계들이 필요한지(보안 검토, 법무, 조달 등)를 이야기 형태로 적으세요. 서명자를 모르면 딜을 초기로 취급하세요.\n\n대략적인 가격 적합성 신호도 캡처하세요. 범위(“< $5k”, “$5-25k”, “$25k+”)나 Likely / Unclear / Unlikely 같은 간단한 표기가 충분합니다. 요점은 감당할 수 없는 고객을 계속 전진시키지 않는 것입니다.\n\n마지막으로 레드 플래그 필드를 한 줄로 유지하세요. 한 단락이 필요하면 노트에 넣으세요.\n\n대부분의 B2B 창업자에게 적합한 간결한 세트:\n\n- 사용 사례 + 성공 기준\n- 의사결정 과정(서명자, 영향자, 단계)\n- 가격 적합성(범위 또는 Likely/Unclear/Unlikely)\n- 경쟁 옵션(명시된 경쟁자 또는 "현상 유지")\n- 레드 플래그(한 줄)\n\n예: “갱신 전 CRM 정리가 필요함, 서명자 = VP Sales, 보안 검토 필요, 예산 대략 $10-20k, 경쟁 옵션은 아무것도 안 함, 레드 플래그: 챔피언이 프로젝트를 소유하지 않음.” 이런 단일 레코드는 스스로를 속이기 어렵게 만듭니다.\n\n## 파이프라인을 정직하게 유지하는 활동 추적\n\n파이프라인이 망가지는 이유는 위시리스트가 되기 때문입니다. 해결책은 더 많은 필드가 아니라 몇 가지 활동 신호로 모든 딜이 한 가지 질문에 답하게 만드는 것입니다: 다음에는 무엇이 일어나는가?\n\n스키마에 한 가지 층만 더 추가한다면 다음 활동 필드를 추가하세요:\n\n- 마지막 활동 날짜(자동이면 좋고, 수동이어도 괜찮음)\n- 다음 단계("팔로업"이 아닌 구체적 행동)\n- 다음 단계 기한(실제 날짜)\n- 마지막 접점 채널(전화, 이메일, 미팅, 데모, 채팅)\n- 실패 이유(짧은 드롭다운, 선택적 한 문장 노트)\n\n실용적 규칙: 딜에 다음 단계나 기한이 없으면 그 딜은 진짜 딜이 아닙니다. 보류하거나 종료하세요. 이는 어떤 스코어링 모델보다 예측 정확성에 더 기여합니다.\n\n"실패 이유"는 짧게 유지하세요: 가격, 예산 없음, 결정 없음, 경쟁사 선택, 타이밍, 적합하지 않음 등.\n\n실제 모습 예시: 화요일에 ops 리드와 데모가 있습니다. 통화 직후 마지막 활동 날짜 = 화요일, 마지막 접점 채널 = 미팅, 다음 단계 = "사례 연구 2건 전송하고 누가 서명하는지 확인", 다음 단계 기한 = 목요일로 설정합니다. 목요일에 답이 없으면 딜은 아무도 "진행"이라고 주장하지 못하게 자동으로 빨간색 신호가 됩니다.\n\n## 대부분의 B2B 창업자에게 적합한 단순한 단계 모델\n\n좋은 단계 모델은 한 가지 일을 제대로 합니다: 각 딜이 어디에 있는지 사실대로 알려주되 열 개의 사소한 단계를 돌보게 만들지 않는 것입니다. 어떤 거래가 어느 단계에 있어야 하는지 사실로 말할 수 없다면 그 단계는 느낌이 됩니다.\n\n다음 여섯 단계 설정은 대부분의 B2B 창업자에게 효과적입니다:\n\n1) New: 이름과 연락할 이유가 있음. 첫 접촉이 완료되었거나 예정됨.\n\n2) Qualified: 기본 적합성이 확인됨. 문제가 실제이며 고객이 ICP에 맞고 구매할 그럴듯한 경로가 있음.\n\n3) Discovery done: 실제 대화를 했음. 사용 사례, 성공 기준, 관련자가 파악됨.\n\n4) Proposal sent: 가격과 범위가 고객에게 전달됨. 다음 단계가 예약되었거나 명시적으로 요청됨.\n\n5) Negotiation/Legal: 조달, 보안, 예산 승인 또는 계약 수정이 진행 중임.\n\n6) Closed won / Closed lost: 결과가 표시되고 이유가 캡처됨.\n\n실제 세상에서 무언가가 발생했을 때만 딜을 전진시키세요(미팅 완료, 제안서 발송, 법무 시작 등). 아무 일도 없었다면 단계는 그대로 둡니다.\n\n## 거래가 표류하지 않게 하는 단계 정의\n\n단계 이름만으로는 충분하지 않습니다. "Qualified"나 "Negotiation" 같은 라벨만 붙이면 누군가가 무엇이 "완료"인지 합의하지 못해 거래가 그곳에 멈춰 있게 됩니다.\n\n단계 규칙을 간단한 진위 검사(true/false)로 작성하세요. 단계에 있는 모든 딜이 같은 사실을 공유하면 파이프라인은 신뢰할 만해집니다.\n\n### 감(直感)이 아닌 진입/퇴출 기준을 사용하세요\n\n진입 기준은 딜이 단계에 들어가기 전에 이미 무엇이 사실이어야 하는지 말합니다. 퇴출 기준은 앞으로 나아가기 위해 무엇이 바뀌어야 하는지 말합니다. 둘 다 짧고 측정 가능하게 유지하세요.\n\n예시:\n\n- Discovery: 첫 라이브 대화가 완료된 후에만 진입; 문제 진술과 다음 미팅 예약이 완료되어야만 퇴출.\n- Proposal sent: 가격이 명시된 제안이 실제로 전송된 경우에만 진입; 구매자가 검토 중이며 결정 날짜가 있는 경우에만 퇴출.\n- Legal/procurement: 구매자가 프로세스나 이해관계자를 소개했을 때 진입; 최종 수정안이나 구매 주문 단계가 있을 때 퇴출.\n\n"좋음", "강함", "관심 있음" 같은 단어 없이 기준을 쓸 수 없다면 그 단계는 너무 모호합니다.\n\n### 단계별 최대 체류일 규칙 추가\n\n각 단계에 최대 연령을 설정하고 이를 초기 경고로 삼으세요. 예: Discovery 최대 14일, Proposal 최대 21일. 딜이 한계에 도달하면 리셋을 트리거하세요: 다음 단계를 예약하거나 뒤로 이동시키거나 종료합니다.\n\n기준이 충족되지 않을 때의 기본 동작을 결정하세요:\n\n- 부족한 정보를 여전히 모을 수 있으면 뒤로 이동.\n- 명확한 팔로업 규칙(예: 10 영업일 동안 3회 시도 후)에도 반응이 없으면 종료로 처리.\n\n이는 "좀비 딜"이 예측을 부풀리는 것을 막습니다.\n\n## 한 오후만 투자하면 스키마를 구축할 수 있습니다\n\n스키마는 작은 제품처럼 다루면 몇 시간 안에 만들 수 있습니다: 먼저 규칙을 정하고 그 규칙을 지원하는 것만 만드세요.\n\n도구 안에서 시작하지 말고 빈 페이지에서 시작하세요. 단계와 진입/퇴출 기준을 평이한 영어(또는 팀 언어)로 적으세요. 단계 하나를 한 문장으로 설명하지 못하면 그건 아마 두 단계이거나 단계가 아닙니다.\n\n간단한 구축 흐름:\n\n- 58단계를 초안으로 작성하고 각 단계마다 명확한 '완료' 테스트를 하나 둡니다.\n- 최소 필드 세트(목표 1015개)를 만듭니다. 검증 가능한 사실에 집중하세요.\n- 활동 추적을 추가하고 활성 단계에서는 "다음 단계 기한"을 필수로 만드세요.\n- 현재 딜을 가져와 정리하면서 가져오세요: 중복 병합, 오래된 "언젠가" 항목 삭제, 소유자 누락 수정.\n- 변경 전 24주 동안 주간 검토를 실행하세요.\n\n설정 중 현실적인 테스트 하나를 하세요: 현재 작업 중인 딜 하나를 단계별로 이동시켜 보세요. 계속 추측하게 된다면 기준이 너무 모호한 것입니다.\n\n초기에 적용할 규칙 하나: 다음 활동 날짜가 비어 있으면 딜은 활성 단계에 머무를 수 없습니다.\n\n## CRM 비대화를 만드는 흔한 실수\n\n대부분의 CRM 비대화는 좋은 의도에서 시작됩니다: 더 정확하게 만들려고 필드와 단계를 추가하고 노트를 많이 남기죠. 결과는 반대입니다. 사람들은 업데이트를 중단하고 파이프라인은 거래가 숙성되는 장소가 됩니다.\n\n### 1) 느낌만 다른 단계들\n\n두 단계가 같은 느낌이라면 사람들은 똑같이 사용할 것입니다. "Discovery", "Deep discovery", "Discovery follow-up"은 종종 "대화를 나눴다"는 의미일 뿐입니다. 단계는 실제로 무언가가 변할 때만 바뀌어야 합니다.\n\n간단한 테스트: 단계에 들어가기 위해 무엇이 사실이어야 하는지 한 문장으로 말할 수 없으면 그 단계는 아마 불필요합니다.\n\n### 2) 마감일이 희망 날짜가 되는 경우\n\n마감일은 이유에 연동되어 있을 때만 유용합니다. 예: 예산 승인, 조달 회의, 서명 기한 같은 다음 결정 시점 날짜로 취급하고, 그 이벤트가 이동하면 마감일도 이동시키세요.\n\n### 3) 활동이 긴 노트로 저장되는 경우\n\n긴 노트는 필요한 한 가지를 숨깁니다: 마지막에 무슨 일이 일어났고 다음에 무슨 일이 일어나는가. 노트는 짧게 유지하고 마지막 활동 날짜와 다음 단계(담당자 및 기한 포함)로 활동을 추적하세요.\n\n### 4) 모든 것이 "Qualified"로 표기되는 경우\n\n정의가 없으면 "Qualified"는 "그들이 괜찮아 보였다"가 됩니다. 반드시 충족해야 할 34개의 체크(문제, 구매자, 일정, 예산 형태)를 고르세요. 하나라도 없으면 아직 Qualified가 아닙니다.\n\n### 5) 딜이 절대 Closed lost가 되지 않는 경우\n\n항상 성장하는 파이프라인은 파이프라인이 아니라 묘지가 됩니다. 활동이 없거나 적합하지 않으면 빠르게 Closed lost로 처리하고 한 가지 명확한 이유를 캡처해 배우세요.\n\n## 파이프라인 위생을 위한 주간 체크리스트\n\n매주 같은 시간(30분이면 충분)을 정하고 미래의 자신과의 미팅처럼 다루세요. 파이프라인 위생은 필드를 더 추가하는 것이 아니라 각 딜에 여전히 실질적 진행 경로가 있는지 확인하는 일입니다.\n\n간단한 검토 흐름:\n\n- 열린 딜마다 명시된 주요 연락처와 한 문장짜리 문제 진술이 있는지 확인하세요.\n- 모든 딜에 하나의 다음 단계와 기한이 있는지 확인하세요.\n- 정체 규칙 적용: 의미 있는 활동이 714일간 없으면 딜을 뒤로 이동시키거나 당분간 "결정 없음"으로 닫으세요.\n- 체류 기간별로 정렬해 가장 오래된 다섯 개에 대해 결정을 강제하세요.\n- 상위 열 개 딜에 대해 예측 타당성 점검: 왜 닫힐지 한 문장으로 설명하고 무엇이 블로킹할 수 있는지 적으세요.\n\n구체적 예시: 딜이 "Proposal sent"로 표시되어 있지만 검토할 미팅이 예약되지 않았다면 그것은 제안 단계 딜이 아닙니다. 뒤로 이동시키고 다음 단계를 설정한 뒤 구매자가 다시 관여할 때까지 카운트하지 마세요.\n\n## 예시 시나리오: 첫 통화부터 서명까지 한 딜\n\n당신이 50명 규모의 이커머스 회사에 B2B 분석 도구를 판매한다고 합시다. 첫 통화 후 딜을 만들고 다음 주에 실제로 쓸 정보만 채웁니다. 단순한 스키마는 서류 작업이 아니라 명확성을 강제하기 때문에 효과가 납니다.\n\n통화 직후 기록은 다음과 같습니다:\n\n- 문제: 주간 리포팅에 68시간 소요, 팀 간 수치 불일치\n- 이해관계자: 스폰서 = Head of Ops; 의사결정자 = CFO; 사용자 = Analyst\n- 다음 단계: 2페이지 요약 전송 + 30분 데모 예약\n- 다음 단계 날짜: 1월 23일 화요일\n- 목표 마감일: 2월 15일\n\n딜은 Discovery에서 시작합니다. 캘린더 초대가 수락될 때만 다음 단계로 이동하세요(누군가 "관심 있어 보인다"고 해서가 아님). 데모 후에는 평가로 이동하는 트리거가 구체적 요청(예: "Shopify와 창고 데이터를 연결할 수 있나요?")이어야 하며 기술적 확인이 뒤따릅니다.\n\n이제 정체가 발생합니다: 가격 제시 후 CFO가 조용해집니다. 로그에는 두 번의 팔로업, 회신 없음, 다음 단계 날짜 경과가 기록되어 있습니다. 규칙은 단순합니다: 명확한 다음 단계가 없으면 딜은 Proposal에 머무를 수 없습니다.\n\n정직한 결정을 내리세요: 추가 스폰서나 정보가 필요하면 평가로 되돌리거나, 의사결정자가 정해진 날짜까지 반응하지 않으면 Closed lost로 마감하세요. 이 예시에서는 뒤로 이동시키고 이해관계자를 업데이트(Ops가 재무 매니저를 끌어들임), 새 다음 단계 날짜 설정, CFO가 결정 미팅을 확인해야만 Proposal로 다시 올립니다.\n\n## 작게 유지하고 반복되는 부분만 자동화하세요\n\n파이프라인 스키마는 신뢰할 수 있어야 작동합니다. 가장 빠른 방법은 최소로 시작해 30일 동안 그대로 운영하는 것입니다. 그러면 실제로 사용하는 것이 무엇인지 보입니다.\n\n첫 달은 엄격하게 운영하세요: 필드가 결정에 영향을 주지 않으면 제거하세요. 결정이 반복적으로 나오고 파이프라인에서 답을 못 얻는다면 해당 갭을 메우는 필드를 단 하나만 추가하세요.\n\n새 필드를 추가하기 전의 간단한 테스트: "이 필드가 비어 있으면 우리가 ___ 할지 결정할 수 없는가?"\n\n일반적인 CRM 대신 가벼운 커스텀 CRM을 만들고 싶다면, Koder.ai (koder.ai) 같은 도구가 단계, 필수 필드, 검증 규칙을 작성한 후에 도움이 될 수 있습니다. 스키마가 명확할 때 단순한 앱을 생성하고 반복하는 것이 훨씬 쉽습니다.
