Showing Posts From
Bmt
- 07 Dec, 2025
BMT 일정 조율할 때 내가 쓰는 협상 기술
BMT 일정 조율할 때 내가 쓰는 협상 기술 시작은 언제나 고객사의 '불가능한' 요구 "다음 주 월요일에 BMT 하고 싶은데요." 오늘 목요일이다. 영업일로 2일. 우리 SE는 부산 출장 중이고, 제안팀은 다른 프로젝트 마감이다. 장비는 데모센터에 있고, 세팅만 하루 걸린다. 불가능하다. 근데 "안 됩니다"라고 하면 그 순간 끝이다. 경쟁사가 "저희는 됩니다" 하고 들어간다. 그래서 나는 이렇게 답한다. "가능합니다. 다만 최적의 데모를 보여드리려면 일정 조정이 필요할 것 같아요. 잠깐 조율해볼게요." 일단 긍정. 그다음 조건 협상. 10년 하면서 터득한 거다. BMT 일정 조율은 영업의 반이다.첫 번째 원칙: 절대 혼자 결정하지 않는다 예전에 실수했다. 고객사가 "다음 주 화요일 오후 2시"라고 하길래 바로 "네" 했다. 우리 팀 일정 확인도 안 하고. 그날 SE가 병가였다. 제안팀장은 다른 미팅이 있었다. 장비는 다른 데모에 쓰고 있었다. 결국 내가 혼자 가서 PPT만 보여줬다. 경쟁사는 실시간 해킹 시연까지 했다. 당연히 탈락. 그 이후로는 절대 즉답 안 한다. "일정 확인하고 30분 내로 회신드릴게요." 그 30분 동안 내가 하는 일:SE팀장한테 카톡 (일정 가능 여부) 데모센터에 전화 (장비 상황) 제안팀한테 슬랙 (지원 가능 인력) 우리 팀장한테 보고 (다른 일정과 충돌 체크)4곳에 동시다발 확인. 5분 안에 답 받는다. 그래야 고객사한테 "가능합니다" 또는 "이 날은 어떠세요?"라고 대안을 줄 수 있다. 혼자 결정하는 순간, 나중에 내가 죽는다.두 번째 원칙: 우리한테 유리한 날짜로 유도한다 고객사는 보통 빨리 하고 싶어 한다. 이해한다. 그들도 윗선 보고 일정이 있으니까. 근데 빨리 하면 우리가 준비 못 한다. 준비 못 하면 진다. 그래서 나는 항상 "최소 일주일"을 확보한다. "다음 주 월요일요? 물론 가능합니다. 다만 귀사 환경에 맞춘 커스터마이징 시연을 준비하려면 금요일 정도가 더 좋을 것 같은데, 어떠세요?" 이렇게 말하면 70%는 수긍한다. 왜냐하면 "커스터마이징 시연"이라는 키워드. 고객은 자기들 환경에 맞춘 걸 보고 싶어 한다. 그리고 금요일 오후를 제안하는 이유가 있다. 금요일 오후면:고객사 임원들 골프 가거나 조기 퇴근 의사결정권자들 없어서 편하게 기술 데모 가능 주말 지나면 기억이 희미해져서 우리가 정리한 보고서가 기준이 됨 경쟁사는 보통 주중 데이타임 선호해서 비교 시점 벌어짐물론 이건 고객사 성향 봐야 한다. 어떤 곳은 월요일 오전이 오히려 좋다. 임원들 집중력 높을 때. 핵심은 "우리가 이길 수 있는 날짜"를 찾는 거다. 세 번째 원칙: 고객사 내부 일정도 파악한다 BMT 날짜 정할 때 난 항상 묻는다. "혹시 그날 다른 중요한 회의 있으세요?" "평가하실 분들 모두 참석 가능하신가요?" "IT팀 말고 실사용 부서분들도 오시나요?" 이게 중요하다. 작년에 한 공공기관 BMT. 우리가 1순위로 먼저 했다. 경쟁사는 3일 뒤. 근데 우리 데모 다음 날, 고객사에 감사가 들어왔다. 그 주 내내 난리. 우리 BMT? 아무도 기억 못 했다. 경쟁사 BMT 때는 감사 끝나고 집중력 회복된 상태. 결과는 뻔했다. 그 이후로 난 꼭 확인한다. "그 주에 혹시 감사나 큰 행사 있으세요?" "월말 결산 시즌 아니에요?" "타 프로젝트 마감 일정 겹치진 않나요?" 고객사 담당자가 "아 그거 신경 써주네요"라고 한다. 당연하다. 내가 이기려면 고객이 집중해야 한다. BMT 날짜는 단순히 우리 일정만의 문제가 아니다. 고객사의 컨텍스트를 이해해야 한다.네 번째 원칙: 경쟁사 순서를 파악하고 포지셔닝한다 BMT는 순서가 중요하다. 첫 번째는 기준이 된다. 마지막은 기억에 남는다. 중간은 묻힌다. 이상적으로는 첫 번째 또는 마지막. 근데 이게 항상 되는 건 아니다. 그래서 난 고객사 담당자한테 슬쩍 묻는다. "혹시 다른 업체분들 일정은 어떻게 되나요? 저희가 너무 겹치면 평가하시기 힘드실까봐요." 대부분 알려준다. "A사가 월요일, B사가 수요일" 그럼 난 화요일이나 목요일을 피한다. 왜? 비교가 너무 직접적이니까. 대신 금요일을 제안한다. 일주일 뒤, 모든 BMT 끝나고. "귀사에서 다른 업체들 평가 결과 보시고, 마지막으로 저희 차별점 확인하시면 좋을 것 같아요." 이렇게 말하면 자신감 있어 보인다. 그리고 실제로 마지막 순서는 유리하다. 고객은 이미 다른 업체들 장단점을 파악한 상태. 우리가 그걸 보완한 메시지를 주면 된다. 물론 첫 번째도 좋다. "저희가 기준을 제시하겠습니다"라고 포지셔닝. 중요한 건 "우리가 왜 이 순서인지" 스토리를 만드는 거다. 그냥 일정상 그렇게 됐다고 하면 약해 보인다. 다섯 번째 원칙: 시간대는 우리 강점이 빛나는 때로 BMT 날짜만큼 중요한 게 시간. 오전 10시 vs 오후 2시 vs 오후 4시. 완전히 다르다. 우리 솔루션이 복잡한 기술 시연 위주면? 오전이 좋다. 고객 집중력 높을 때. UI/UX나 사용 편의성이 강점이면? 오후가 좋다. 피곤할 때 '쉽다'는 게 더 부각된다. 실제 해킹 시연 같은 임팩트 있는 데모면? 오후 늦게. 다들 지쳐 있을 때 한 방. 작년에 DLP 프로젝트 BMT. 우리 강점은 '실시간 차단'이었다. 나는 오후 4시를 제안했다. 고객사 담당자들 하루 일과 끝날 무렵. 실제로 USB 꽂아서 파일 복사하려는 순간 팝업 뜨고 차단되는 거 보여줬다. 실시간으로. 한 담당자가 "우와" 했다. 그 반응이 평가서에 그대로 반영됐다. 경쟁사는 오전 10시에 했다. PPT 위주 설명. 졸린 오후가 아니라 멀쩡한 오전에. 임팩트 차이가 났다. 시간대 선택은 전략이다. 여섯 번째 원칙: 우리 팀 컨디션도 체크한다 고객사 일정만 맞추다 보면 우리 팀을 놓친다. SE가 전날 밤샘 작업하고 BMT 가면? 망한다. 집중력 떨어지고, 질문 대응 느리고, 실수한다. 제안팀이 다른 프로젝트 마감 직전이면? 지원 제대로 못 받는다. 그래서 난 일정 조율할 때 우리 팀 상태를 먼저 본다. "이번 주 SE팀 야근 상황 어때요?" "제안팀 다른 프로젝트 언제 끝나요?" "장비 세팅 여유 있게 할 수 있어요?" 여유 있는 일정을 만들어야 한다. 그래야 준비 제대로 하고, 데모 완벽하게 하고, 이긴다. 지난달에 한 프로젝트. 고객사가 수요일을 원했다. 근데 우리 SE가 화요일까지 다른 BMT 있었다. 나는 금요일로 조율했다. "더 완벽한 준비를 위해"라는 명분. SE가 수요일, 목요일 이틀 동안 여유 있게 세팅하고 리허설 했다. 금요일 BMT는 완벽했다. 한 건의 실수도 없었다. 그리고 수주했다. 팀 컨디션은 곧 성공률이다. 일곱 번째 원칙: 플랜B는 항상 준비한다 BMT 일정 조율에서 가장 무서운 건 "당일 변경"이다. 고객사 임원이 갑자기 출장 가거나, 장비가 고장 나거나, SE가 아프거나. 실제로 작년에 한 번 당했다. BMT 당일 아침, 고객사에서 전화 왔다. "죄송한데 오늘 사장님이 급히 오라고 하셔서요. 내일로 미뤄도 될까요?" 패닉. 근데 나는 이미 플랜B가 있었다. 다음 날 오전에 우리 데모센터에서 다른 고객 데모가 있었지만, 오후는 비어 있었다. "네, 가능합니다. 내일 오후 2시 어떠세요?" 즉답. 고객이 놀랐다. "확인 안 하세요?" "이미 확인돼 있습니다." 사실은 매번 BMT 일정 잡을 때 ±2일 여유 일정을 미리 확보해둔다. SE팀, 장비, 제안팀 모두. "만약을 위해" 라고 말하면 다들 이해한다. 그 플랜B가 몇 번 날 살렸다. BMT 일정은 칼같이 지켜지지 않는다. 유연성이 생명이다. 여덟 번째 원칙: 조율 과정 자체를 신뢰 구축에 쓴다 일정 조율하면서 나는 고객사 담당자한테 자주 연락한다. "확인했습니다. 금요일 오후 2시 가능합니다." "SE팀이랑 협의해서 최적의 시연 시나리오 준비 중입니다." "혹시 당일 네트워크 환경 미리 체크하고 싶은데 가능할까요?" 이런 커뮤니케이션이 쌓인다. 고객은 "꼼꼼하네", "신경 쓰네"라고 느낀다. 실제로 한 고객사 담당자가 말했다. "다른 업체는 날짜만 딱 정하고 끝인데, 당신은 계속 챙기더라. 그래서 믿음이 갔어." BMT 전에 이미 신뢰가 쌓인 거다. 그 신뢰가 평가에 반영된다. 일정 조율은 단순한 행정 업무가 아니다. 영업 활동이다. 고객과의 모든 접점이 세일즈 포인트다. 아홉 번째 원칙: 기록은 반드시 문서로 남긴다 전화로 일정 정하면 나중에 꼭 문제 생긴다. "아니 저는 화요일이라고 들었는데요?" "장비 2대라고 하셨잖아요." 말이 다르다. 기억이 다르다. 그래서 나는 일정 확정되면 즉시 이메일 보낸다.제목: [BMT 일정 확정] XX솔루션 기술 검증 일정 안내 ○○님, 안녕하세요. 말씀하신 BMT 일정 확정해서 안내드립니다.일시: 2024년 X월 X일(금) 14:00~17:00 장소: 귀사 본사 3층 회의실 참석: 귀사 보안팀 5명 / 당사 SE 2명, 영업 1명 시연 내용: DLP 실시간 차단, 정책 설정, 리포팅 준비 사항: 당사 테스트 장비 2대, 귀사 네트워크 환경 사전 점검혹시 변경 사항 있으시면 말씀 주세요. 감사합니다. 이렇게 쓰면 나중에 분쟁 없다. 그리고 프로페셔널해 보인다. 고객도 안심한다. "정리 잘하네." 문서는 무기다. 열 번째 원칙: 실패한 일정도 배운다 모든 조율이 성공하는 건 아니다. 작년에 한 프로젝트. 내가 완벽하게 일정 잡았다고 생각했다. 우리 팀 준비도 완료, 고객사 일정도 확인. 근데 BMT 당일, 경쟁사가 먼저 한 데모가 너무 좋았다. 고객사가 이미 마음 정한 상태로 우리 차례가 왔다. 아무리 잘해도 역전 안 됐다. 실패 원인: 경쟁사 순서를 너무 가볍게 봤다. 그 업체가 준비를 얼마나 했는지 파악 안 했다. 그 이후로 나는 경쟁사 동향도 체크한다. 가능하면 그들이 어떤 시연 준비하는지, 어떤 메시지 쓰는지. 실패한 BMT마다 조율 노트에 기록한다. "이 고객사는 오전 선호" "이 업종은 마지막 순서 불리" "이 경쟁사는 항상 첫 번째 고집" 데이터가 쌓인다. 그게 다음 협상의 무기가 된다. 마무리하며 BMT 일정 조율. 누가 봐도 단순한 행정 업무다. 근데 나는 안다. 여기서 승부가 갈린다. 날짜 하나, 시간대 하나, 순서 하나가 수주를 결정한다. 10년 하면서 수십 번의 BMT 조율했다. 이기는 조율이 있고, 지는 조율이 있다. 핵심은 "우리에게 유리한 환경"을 만드는 거다. 강압적이지 않게, 자연스럽게. 고객은 모른다. 내가 얼마나 치밀하게 계산했는지. 그냥 "프로페셔널하네", "배려심 있네" 정도로 느낀다. 그걸로 충분하다. 오늘도 BMT 일정 조율 메일이 왔다. "다음 주 아무 때나 괜찮아요." 아무 때나? 없다. 딱 하루, 딱 한 시간, 우리가 이길 수 있는 타이밍이 있다. 그걸 찾는 게 내 일이다.또 일정 조율 메일 온다. 이번엔 이길 거다.
- 05 Dec, 2025
제안서 마감 24시간 전, 최고의 스토리라인은 만들어진다
제안서 마감 24시간 전, 최고의 스토리라인은 만들어진다 D-1, 오후 4시 내일 오전 10시 제안 발표다. 자료는 있다. PPT 120장. 근데 이게 제안서가 아니라 자료 더미인 거다. SE가 보낸 기술 스펙 40장. 컨설턴트가 작성한 현황 분석 30장. 마케팅팀이 준 레퍼런스 20장. 나머지는 회사 소개랑 가격표. 고객은 CISO. 임원 보고용 자료 원한다고 했다. "핵심만 20장으로" 그랬다. 120장을 20장으로. 이게 편집이 아니다. 재창조다. 커피 마셨다. 네 번째다.스토리라인이 없으면 그냥 카탈로그다 10년 하면서 배운 거. 제안서는 제품 설명서가 아니다. 설득의 도구다. 고객이 보는 건 기능이 아니다. 솔루션이다. 내 문제를 어떻게 해결해주냐는 거다. DLP 제안서 100개 봤다. 다 똑같다. "개인정보 유출 방지", "7가지 차단 기술", "클라우드 연동". 근데 통하는 제안서는 다르다. 고객 이야기로 시작한다. "귀사는 지난 6개월간 3번의 개인정보 유출 위험 상황이 있었습니다. 협력업체 USB, 재택근무 PC, 퇴사자 이메일. 다행히 큰 사고는 없었지만, 다음엔 모릅니다." 첫 장부터 심장 찌른다. "이거 우리 얘기잖아" 이렇게 만드는 거다. 그 다음이 문제 정의. 왜 이런 일이 반복되는가. 기술 문제가 아니다. 프로세스 문제다. 가시성 문제다. 그리고 우리 솔루션. "이렇게 하면 됩니다." 마지막이 ROI. "이 정도 투자로 이만큼 리스크 줄입니다." 이게 스토리라인이다. 기승전결. 문제-원인-해결-효과. 근데 이걸 마감 24시간 전에 만든다. 왜? 그때까지 자료가 안 모여서. Pain Point 찾기: 고객사 3번 방문의 의미 제안서 쓰기 전에 한 것들. 고객사 3번 갔다. 첫 번째: 담당자 미팅. 보안팀 과장. RFP 받으러 간 거지만 질문 30분 했다. "요즘 제일 골치 아픈 게 뭐예요?" "임원들이 자꾸 개인 클라우드 쓰는 거요. 파일 막 올리고." "막을 수는 없나요?" "막으면 일을 못 한다고 난리예요. 대안 달래요." 메모했다. 임원 - 클라우드 - 업무 연속성. 두 번째: CISO 미팅. 의사결정자. 30분 약속인데 15분 걸렸다. "우리 회사 DLP 도입 이유 아시죠?" "규제 대응이요." "맞아요. 근데 그것만으론 예산 안 나와요. 이사회 설득할 숫자 필요해요." 메모했다. 이사회 - 정량적 효과 - 비용 대비. 세 번째: 현장 실사. 보안팀이랑 IT팀이랑 같이. 실제 업무 환경 봤다. 개발팀은 GitHub 쓴다. 영업팀은 파일 공유에 네이버 클라우드 쓴다. 임원 비서실은 USB 쓴다. "통제가 안 되는 거네요." "안 되는 게 아니라 안 하는 거죠. 방법이 없어서." 메모했다. 부서별 - 다른 환경 - 통합 필요. 이 메모들이 Pain Point다. 제안서 첫 5장이다.산발적 자료를 하나의 흐름으로 오후 7시. 본격 작업 시작. SE한테 받은 기술 스펙 40장. 이거 그대로 못 쓴다. 기술자 언어다. "멀티 채널 모니터링 엔진", "정책 기반 필터링", "머신러닝 패턴 분석". 이해는 한다. 근데 CISO는 이거 안 궁금하다. "그래서 뭐가 좋은데?" 이거 궁금한 거다. 번역 작업. 기술을 비즈니스 언어로. "멀티 채널 모니터링 엔진" → "USB, 이메일, 메신저, 클라우드 모두 하나의 화면에서 관리" "정책 기반 필터링" → "부서별로 다른 규칙 적용 가능. 개발팀은 GitHub 허용, 영업팀은 제한" "머신러닝 패턴 분석" → "신규 유출 경로 자동 탐지. 관리자 설정 불필요" 40장이 10장 됐다. 컨설턴트 자료 30장. 현황 분석. AS-IS 다이어그램 15장, TO-BE 다이어그램 15장. 다이어그램 좋다. 근데 너무 많다. 눈 아프다. 핵심만 뽑았다. AS-IS 3장, TO-BE 3장. 나머지는 부록. 비교 표 하나 만들었다.현재 도입 후8개 시스템 개별 관리 1개 통합 콘솔사고 후 사후 대응 사전 차단월 40시간 수작업 점검 자동화숫자 넣으니까 확실히 달라 보인다. 마케팅 자료 20장. 레퍼런스. "A사 도입 사례", "B사 도입 사례". 다 비슷하다. "성공적으로 구축", "만족도 높음". 이것도 번역. 고객 입장에서. "제조업 C사: 협력업체 300개 관리. USB 통제로 도면 유출 제로화" "금융 D사: 재택근무 500명. VDI 연동으로 집 PC도 회사 수준 보안" 구체적 숫자. 구체적 상황. 이게 레퍼런스다. 20장이 4장 됐다. 120장에서 50장. 아직 반이다.설득의 흐름: 왜-무엇-어떻게-얼마 오후 10시. 구조 잡는다. 제안서는 4막 구조다. 1막: 왜 (Why)고객 Pain Point 현재 리스크 규제 이슈 목표: 공감 형성5장. 첫 장: "귀사의 보안 현황"8개 시스템 사일로 가시성 부족 사후 대응둘째 장: "3가지 위험 시나리오"시나리오 1: 협력업체 USB 시나리오 2: 임원 개인 클라우드 시나리오 3: 퇴사자 이메일 (실제 그 회사에서 있었던 일)셋째 장: "규제 환경 변화"개인정보보호법 개정 과징금 최대 3% 인증 심사 강화넷째 장: "보안팀의 현실"월 40시간 수작업 사고 때마다 보고서 인력 부족다섯째 장: "해결해야 할 과제"통합 관리 사전 차단 업무 연속성 비용 효율고객이 고개 끄덕이게 만드는 거다. "맞아, 우리 문제가 이거야." 2막: 무엇 (What)우리 솔루션 핵심 기능 차별점 목표: 이해와 신뢰10장. "OO DLP 개요"올인원 플랫폼 3가지 핵심 모듈"기능 1: 통합 모니터링"7개 채널 실시간 단일 콘솔 스크린샷 (실제 화면)"기능 2: 지능형 차단"정책 엔진 부서별 설정 예외 처리"기능 3: 자동 대응"실시간 알림 워크플로우 증적 관리각 기능마다 Before/After 비교. 시각적으로. "경쟁 제품 대비 강점"표로 정리 3개 경쟁사 5가지 기준 (가격은 빼고. 기술로 승부)"국산 솔루션의 장점"기술 지원 속도 커스터마이징 한글 처리마지막: "레퍼런스"동종 업계 2곳 구체적 수치객관적 근거. 신뢰 쌓는 거다. 3막: 어떻게 (How)도입 방안 구축 프로세스 리스크 관리 목표: 실행 가능성6장. "도입 로드맵"3개월 타임라인 단계별 산출물 마일스톤"1단계: 현황 분석 (2주)"자산 조사 정책 수립 테스트 계획"2단계: 파일럿 (4주)"부서 1개 100명 검증"3단계: 전사 확대 (6주)"단계적 롤아웃 사용자 교육 안정화"리스크 관리"예상 이슈 3가지 대응 방안 롤백 계획"추진 체계"우리 팀 구성 고객 TF 협업 방식실행 가능해 보이게. 구체적으로. 4막: 얼마 (How much)비용 ROI 기대 효과 목표: 의사결정6장. "투자 비용"라이선스 구축 교육 1년 유지보수 (총액 하나, 세부 하나)"TCO 분석"3년 총소유비용 경쟁사 대비 숨은 비용 없음"ROI 산출" 이게 핵심이다.유출 사고 방지: 연 2억 (과징금 + 대응 비용) 관리 시간 절감: 연 6000만원 (월 40시간 → 10시간) 인증 비용 절감: 연 3000만원 (통합 관리로) 합계: 연 2.9억투자: 1.8억 회수 기간: 8개월 숫자는 보수적으로. 근거는 구체적으로. "기대 효과"정량적: 위의 ROI 정성적: 보안 수준 향상, 컴플라이언스, 업무 효율마지막 장: "제안 조건"가격 계약 조건 특별 제공 (교육 추가 무료 등)새벽 2시, 스토리 점검 4막 구조 완성. 이제 27장. 처음부터 다시 읽는다. 고객 입장에서. 1장: Pain Point 공감 → OK 5장: 문제 정의 명확 → OK 10장: 우리 솔루션 이해 → OK 15장: 차별점 납득 → OK 20장: 실행 가능성 → OK 27장: 투자 결정 → OK 흐름 자연스럽다. 논리 빈틈없다. 근데 뭔가 부족하다. 감정이 없다. 제안서는 논리만으론 안 된다. 공감이 필요하다. 다시 손본다. 첫 장에 사진 넣었다. 보안팀 야근 사진. (웹에서 찾은 거) "이게 귀사 보안팀의 현실입니다." 레퍼런스에 인터뷰 넣었다. C사 보안팀장 말. "도입 전엔 매일 불안했습니다. 도입 후엔 잠이 옵니다." ROI 페이지에 그래프. 막대 그래프로 비용 대비 효과. 시각적으로 확 들어온다. 마지막 장. "함께 만들겠습니다" "이 제안서는 제품 판매가 아닙니다. 파트너십 제안입니다." 좀 오글거린다. 근데 먹힌다. 진심 담으면. 새벽 4시, 디테일 전쟁 큰 틀 완성. 이제 디테일. 오타 잡는다. 맞춤법 검사 3번. 고객사 이름 20번 나온다. 한 번이라도 틀리면 끝이다. 전부 확인. 페이지 번호 맞춘다. 목차랑 일치하는지. 그래프 색깔 통일. 파랑-빨강-회색 일관성. 폰트 크기. 제목 28pt, 소제목 20pt, 본문 16pt. 전부 체크. 이미지 해상도. 흐린 거 다시 만든다. 각주 다 붙인다. "출처: 한국인터넷진흥원, 2024" 페이지 레이아웃. 여백 적당한지. 숨 쉬는 느낌. 하이퍼링크. 작동하는지 하나씩 클릭. PDF 변환. 파일명 "OO사_DLP_제안서_최종_240315.pdf" 용량 확인. 50MB 넘으면 메일 안 간다. 압축. 백업 3곳. 노트북, USB, 클라우드. 새벽 5시. 완성. 27장. 60MB. 완벽하다. 발표 전 1시간, 최종 리허설 아침 9시. 회의실 도착. 빔 프로젝터 연결. 노트북이랑 안 맞는다. 어댑터 바꿨다. 됐다. 리모컨 작동 확인. 배터리 새 거로. 화면 밝기 조절. 형광등 켜면 안 보인다. 조명 껐다. 제안서 출력본 5부. 나눠 드릴 거. 명함 10장. 주머니에. 커피 마셨다. 여덟 번째다. 손 떨린다. 안 마실 걸. 혼자 리허설. 27장 15분 안에. 1분에 2장. 빠르다. 근데 가능하다. 흐름 외웠다. 첫 장: "오늘 제안드릴 내용은 귀사의 3가지 보안 과제 해결 방안입니다." 10장: "OO DLP는 8개 시스템을 하나로 통합합니다." 20장: "투자 대비 효과, 8개월 만에 회수 가능합니다." 27장: "함께 만들어가고 싶습니다." 마무리: "질문 받겠습니다." 연습 3번. 13분 28초. 적당하다. 오전 10시, 발표 CISO 들어왔다. 임원 2명 더. 보안팀장, 담당 과장. 5명. 예상대로. "시작하겠습니다." 첫 장 넘겼다. CISO 표정 읽는다. 집중한다. 5장. Pain Point. 고개 끄덕인다. 통했다. 10장. 솔루션 설명. 임원이 손 들었다. "다른 부서도 같은 정책 쓰나요?" "아닙니다. 부서별 커스터마이징 가능합니다." "좋네요." 15장. 레퍼런스. CISO가 물었다. "C사랑 우리랑 규모 비슷한가요?" "직원 수 거의 같습니다. 자산 규모는 귀사가 20% 더 큽니다." "그럼 기간은?" "비슷할 겁니다. 3개월 잡았습니다." 20장. ROI. 다들 집중한다. 숫자 나오니까. 보안팀장이 물었다. "관리 시간 40시간에서 10시간, 이거 확실한가요?" "C사 실측 데이터입니다. 자동화 범위에 따라 달라질 순 있습니다." "레퍼런스 연락처 줄 수 있나요?" "네, 제안서 부록에 있습니다." 27장. 마무리. "질문 있으십니까?" CISO가 말했다. "인상적이네요. 우리 상황 많이 파악하셨어요." 통했다. 3번 방문한 게 보였다. "다음 주 화요일까지 검토하고 연락드리겠습니다." 끝. 회의실 나왔다. 다리 풀렸다. 결과: 2주 후 전화 왔다. "수주 축하드립니다." 그 순간. 24시간의 가치. 산발적이던 자료들. 하나의 스토리가 됐다. 기술은 기술대로. 숫자는 숫자대로. 근데 그걸 엮은 건 '흐름'이었다. Pain Point에서 시작해서 ROI로 끝나는 여정. 고객이 공감하고, 이해하고, 신뢰하고, 결정하게 만드는 구조. 이게 제안서다. 제안서는 정보 전달이 아니다. 설득의 도구다. 마감 24시간 전. 그때 최고의 스토리라인이 나온다. 왜? 더 이상 미룰 시간이 없으니까. 집중력이 최고조니까. 본질만 남으니까. 10년 했다. 아직도 마감 24시간 전엔 떨린다. 근데 그 떨림이 좋다. 살아있다는 느낌. 오늘도 RFP 왔다. 마감 2주. 실제론 13일 후 밤 10시에 시작할 거다. 그게 내 방식이다.결국 통하는 건 '그들의 이야기'로 시작하는 제안서다.