제안서에서 가장 먼저 고칠 것은 디자인이나 분량이 아니라 순서입니다. 대부분의 제안서가 회사 소개로 시작하는데, 고객은 우리 회사가 궁금한 게 아니라 자기 문제가 궁금합니다.
「제안서 작성법」을 검색하면 표준 목차를 알려주는 글이 줄줄이 나옵니다. 제안 개요, 회사 소개, 인력 구성, 기술, 재무. 목차는 알려주는데 왜 그 순서인지는 아무도 말해 주지 않습니다.
회사 소개부터 쓰면 무엇이 문제인가요
사업 제안서를 회사 소개부터 시작하면 읽는 사람이 아직 들을 준비가 안 된 자리에서 우리 이야기를 꺼내게 됩니다.
제안서를 받은 담당자는 대개 이런 상태입니다. 위에서 「검토해 보라」고 내려왔고, 비슷한 문서가 두세 개 더 책상에 있습니다. 이 사람이 첫 장에서 확인하고 싶은 건 하나입니다. 이게 우리 문제를 다루는 문서인가.
거기서 다른 회사의 연혁과 조직도를 만나면 읽는 속도가 그냥 떨어집니다. 문서가 나쁘다기보다, 아직 내 이야기가 아니라서 그렇습니다.
제안서와 말솜씨가 영업 성과에서 얼마나 차지하는지는 영업 성공 요인 글에서 연구와 함께 다뤘습니다.
제안서 작성법의 순서는 어디서 가져왔나요
개발자들이 쓰는 문서 프레임워크에서 가져왔습니다.
얼마 전 Diátaxis라는 프레임워크를 봤습니다. 기술 문서를 잘 쓰기 위해 만들어진 틀인데, 읽다 보니 이건 제안서 이야기였습니다.
이 틀이 만들어진 배경은 단순합니다. 읽는 사람의 필요는 제각각인데, 쓰는 사람은 늘 한 덩어리로 쓴다는 것. 그래서 문서를 네 가지로 나눕니다.
| Diátaxis | 무엇을 하는 문서인가 |
|---|---|
| Explanation (설명) | 왜 이 방식인지 이해시킨다 |
| Reference (기술 참조) | 정확한 정보를 준다 |
| How-to guide (하우투) | 목표에 닿는 순서를 준다 |
| Tutorial (튜토리얼) | 직접 해보며 알게 한다 |
사람의 이해를 돕고 방향을 잡아주는 일. 개발 문서가 하는 일과 영업 문서가 하는 일이 크게 다르지 않습니다.
저는 이 구분을 제안서에 Why → What → How, 그리고 경험 순으로 적용합니다. 기술 문서의 분류를 영업 문서에 옮긴 제 해석입니다.
사업 제안서 첫 장에는 무엇을 적나요
처음 쓰는 사람이라면 아래 네 칸부터 채워 볼 수 있습니다. 정해진 제출 양식이 없는 제안을 위한 작성 틀입니다.
| 첫 장의 칸 | 적을 내용 |
|---|---|
| 지금의 문제 | 누가 어떤 일을 하다가 어디에서 막히는가 |
| 바꿀 상태 | 도입한 뒤 무엇이 달라져야 하는가 |
| 이번 제안의 범위 | 우리가 맡을 일과 고객이 준비할 일은 각각 무엇인가 |
| 확인할 방법 | 어떤 자료나 시험으로 제안이 맞는지 확인할 것인가 |
모르는 수치는 빈칸으로 두고 「고객 확인 필요」라고 적습니다. 고객의 현재 상황을 확인하기 전에 절감 효과를 숫자로 채우면, 제안서가 가정 위에 쌓입니다.
Why에는 무엇을 쓰나요
왜 지금 이 문제를 풀어야 하는지, 왜 이 접근이어야 하는지를 씁니다.
여기가 앞에 있어야 하는 이유가 하나 더 있습니다. 우리가 만드는 건 제안서이면서 동시에 고객 회사 안에서 돌아다닐 설득 자료입니다. 실무자가 이 문서를 들고 윗선을 설득해야 합니다.
그 사람이 위에 가져가서 펼쳤을 때 첫 장이 우리 회사 소개면, 설득할 말이 없습니다.
What과 How는 어떻게 나누나요
What은 정확한 정보고, How는 고객의 경로입니다.
What(레퍼런스) 은 우리가 제공하는 것의 범위, 스펙, 조건, 일정, 가격입니다. 여기서 중요한 건 정확함입니다. 부풀린 숫자와 애매한 범위는 계약 후에 전부 부메랑으로 돌아옵니다. Why에 공감한 고객이 「그래서 정확히 뭘 해주는데」를 확인하는 자리입니다.
How(하우투) 는 고객의 지금 상태가 원하는 상태로 가는 단계입니다. 우리 제품이 뭘 할 수 있는지가 아니라, 그 회사의 그 문제가 몇 단계를 거쳐 어떻게 풀리는지를 씁니다.
기능 나열과 실행 경로는 다릅니다. 고객이 도입한 뒤의 자기 모습을 그릴 수 있어야 그때부터 검토가 시작됩니다.
글로 다 설득해야 하나요
아닙니다. 마지막은 겪게 하는 쪽이 낫습니다.
데모, PoC, 샘플 리포트. 「한번 해보시죠」가 잘 쓴 열 페이지보다 힘이 셉니다. 문서는 여기까지 오게 만드는 다리 역할이면 충분합니다.
글로 전부 설득하려고 하면 분량이 늘고, 분량이 늘면 아무도 끝까지 안 읽습니다.
다만 공공 입찰 제안서는 순서를 우리가 못 정합니다. 요청서 목차가 그대로 채점표입니다.
정리하면 순서가 이렇게 됩니다
Why로 공감을 만들고, What으로 신뢰를 만들고, How로 그림을 그리게 하고, 경험으로 확신을 만듭니다.
제안서를 처음 써 보는 분이라면 이 순서만 지켜도 「어, 잘 쓰네」 소리를 듣습니다. 반대로 넷 중 하나가 통째로 빠져 있으면 디자인이 아무리 좋아도 어딘가 허전한 문서가 됩니다.
방법론은 어디서 가져와도 됩니다. 이번에는 개발자들에게 배웠습니다.
AI로 초안을 만들기 전 고객사 자료와 확인할 질문을 나누는 방법은 AI 영업에서 제안서보다 먼저 할 일에서 이어집니다.
자주 묻는 질문
- 회사 소개는 아예 빼야 하나요?
- 빼는 게 아니라 자리를 옮깁니다. 우리가 누구인지는 What(레퍼런스) 자리에서 근거로 쓰일 때 힘이 있습니다. 맨 앞에 두면 고객이 아직 자기 문제를 확인하기도 전에 남의 회사 이야기를 읽게 됩니다.
- 정해진 양식이 있는 입찰 제안서도 이 순서로 쓰나요?
- 양식이 고정된 경우에는 목차를 바꿀 수 없습니다. 대신 각 항목의 첫 문단을 Why로 엽니다. 항목 순서는 발주처가 정하지만 문단 안의 순서는 우리가 정합니다.
- 제안서 분량은 어느 정도가 적당한가요?
- 정답은 없지만 기준은 있습니다. 고객사 실무자가 이 문서를 그대로 윗선에 전달할 수 있는가입니다. 전달하기 전에 요약본을 따로 만들어야 한다면 아직 긴 것입니다.