제안서를 써도 수주가 안 된다면. 클라이언트의 언어로 말하는 제안 전략 — 15년차 PD/PM이 수주율을 가르는 결정적 차이를 짚는다.
Created by ChatGPT - DALL-E 3

 

제안서 작성법이나 양식, 수주 잘하는 제안 전략을 검색해서 들어오셨다면 도움이 될 것이다. 문제는 대부분 퀄리티가 아니라 구조다. 클라이언트의 언어로 쓰지 않았기 때문이다. 실제 수주로 이어진 제안서가 어떤 구조로 짜여졌는지, 제출 이후 팔로업까지 실무 기준으로 정리했다.

 


 

 

1. 제안서는 설명서가 아니다

Created by ChatGPT - DALLE 3

 

많은 PD/PM이 제안서를 "우리가 할 수 있는 것의 목록"으로 만든다. 기술 스택, 포트폴리오, 제작 파이프라인, 팀 구성 — 이런 것들로 채워진 제안서는 결국 회사 소개서와 다르지 않다.

 

클라이언트가 제안서에서 찾는 것은 하나다. "이 회사가 우리 문제를 이해하고 있는가." 그 확신이 생기는 순간 제안서는 채택된다. 확신이 없으면 아무리 화려한 포트폴리오도 의미가 없다.

 

필자가 처음 제안서를 쓸 때 가장 많이 한 실수도 바로 이것이었다. 우리가 얼마나 잘할 수 있는지를 설명하는 데 집중했고, 클라이언트가 왜 이 프로젝트를 하려는지를 제대로 담지 못했다.

 

 

2. 클라이언트의 언어를 먼저 수집하라

Created by Gemini - Nano Banana 2

 

제안서를 쓰기 전에 해야 할 일이 있다. 클라이언트가 이 프로젝트를 어떤 언어로 설명하는지를 파악하는 것이다.

 

브리핑 문서를 그대로 활용하라: 클라이언트가 보내온 브리핑 문서에는 그들이 중요하게 생각하는 단어와 맥락이 담겨 있다. "글로벌 런치 임팩트"를 강조했다면 제안서에도 그 단어가 들어가야 한다. "온라인 전환율"을 언급했다면 컨피규레이터의 UX 흐름을 그 맥락으로 연결해야 한다.

 

미팅 메모를 소재로 써라: 사전 미팅이 있었다면 거기서 나온 클라이언트의 발언이 제안서의 가장 강력한 소재다. "올해 안에 쇼룸 없이도 프리미엄 경험을 줄 수 있어야 한다"는 말을 들었다면, 제안서 첫 페이지에 그 문장의 해법을 놓아야 한다.

 

경쟁사 동향을 레퍼런스로 써라: 클라이언트는 항상 경쟁사를 의식한다. "경쟁사 A는 이미 이런 방식을 도입했고, 귀사는 이 방향으로 차별화할 수 있다"는 구조는 클라이언트의 긴장감을 자극하고 제안의 설득력을 높인다.

 

 

3. 제안서의 구조 — 세 가지 층위

Created by ChatGPT - DALLE 3

 

제안서는 읽히는 순서가 있다. 처음부터 끝까지 정독하는 클라이언트는 드물다. 첫 페이지와 마지막 페이지, 그리고 눈에 걸리는 비주얼 몇 개로 판단한다. 이 구조를 알고 써야 한다.

 

첫 페이지 — 문제 정의: 클라이언트의 상황과 과제를 필자가 먼저 정리해서 보여준다. "현재 귀사의 온라인 채널에서는 차량 경험의 깊이가 아쉽고, 이것이 전환율에 영향을 주고 있다"처럼 — 클라이언트가 고개를 끄덕이는 문장으로 시작해야 한다.

 

중간 — 해법과 차별점: 우리가 제안하는 방식이 왜 이 문제에 맞는지를 설명한다. 단순한 기능 나열이 아니라, 클라이언트의 문제와 우리의 솔루션을 1:1로 연결하는 방식으로 써야 한다. 자동차 컨피규레이터 프로젝트라면 WebGL 기반인지 클라우드 스트리밍 기반인지에 따라 클라이언트의 운영 편의성이 어떻게 달라지는지까지 담아야 한다.

 

마지막 페이지 — 다음 스텝: 제안서는 "검토해주세요"로 끝나면 안 된다. "다음 주 내로 킥오프 미팅 일정을 잡겠습니다"처럼 행동을 유도하는 문장으로 닫아야 한다. 클라이언트가 다음에 무엇을 해야 하는지를 명확하게 제시하는 것이 제안의 마지막 설득이다.

 

 

4. 비주얼이 절반이다

Created by ChatGPT - DALLE 3

 

리얼타임 콘텐츠 제안서에서 비주얼은 선택이 아니다. 우리가 만드는 것이 본질적으로 비주얼인데, 제안서가 텍스트로만 채워져 있다면 그 자체가 모순이다.

 

포트폴리오는 맥락과 함께: 레퍼런스 이미지나 영상을 넣을 때, 단순히 "이런 거 만들었습니다"가 아니라 "이 프로젝트에서 어떤 문제를 어떻게 해결했는지"를 함께 담아야 한다. 결과물의 퀄리티와 문제 해결 능력을 동시에 보여주는 것이 포트폴리오의 역할이다.

 

모션과 인터랙션은 직접 보여줘라: 리얼타임 컨피규레이터나 HMI 콘텐츠를 제안할 때, PDF 제안서 한 장보다 간단한 데모 링크 하나가 더 강력하다. 클라이언트가 직접 인터랙션을 경험하면 "이게 우리 것이 되면 어떨까"라는 상상이 시작된다. 필자의 부서는제안 시 가급적 간단한 인터랙티브 데모를 함께 제출한다.

 

 

5. 제안서 제출 이후가 더 중요하다

Created by Gemini - Nano Banana 2

 

제안서를 제출하고 기다리는 PD/PM이 많다. 이것이 두 번째로 흔한 실수다.

제출 후 48시간 안에 팔로업: 제안서를 받았는지, 검토하면서 궁금한 점은 없는지 — 가볍게 확인하는 연락 하나가 관심과 책임감을 동시에 보여준다.

 

클라이언트 내부 발표를 도와줘라: 실무 담당자가 내부에서 이 제안을 설명해야 하는 경우가 많다. 담당자가 임원에게 보고할 때 쓸 수 있는 한 페이지 요약본을 따로 만들어 주는 것 — 이 작은 행동이 수주율을 실제로 높인다. 필자가 직접 경험한 방법이다.

 

 

결론

Created by Gemini - Nano Banana 2

 

제안서는 우리를 설명하는 문서가 아니다. 클라이언트의 문제를 우리가 얼마나 깊이 이해하고 있는지를 증명하는 문서다. 클라이언트의 언어로 시작하고, 그들의 다음 행동을 설계하며 끝내는 제안서 — 그것이 수주로 이어지는 제안서다.

 

 


 

 

다음 강에서는 대부분의 PD/PM이 가장 두려워하는 순간을 다룬다. 견적서에서 숫자를 어떻게 설계하는가 — 너무 낮으면 신뢰를 잃고, 너무 높으면 탈락한다. 그 사이를 가르는 기준이 있다.