결정을 받을 수 있는 제안서

제안서를 만든 사람은 모든 맥락을 알고 있습니다. 문제는 그다음입니다. 파일이 고객사 담당자에게 전달되고, 회의에 없던 의사결정자가 열어봅니다.

그 사람이 몇 장만 넘겨도 무엇을 제안하는지, 어디까지 해주는지, 무엇을 결정해야 하는지 알 수 있어야 합니다.

Snapdeck에 새로 추가한 Proposal은 바로 그 장면을 위한 스타일입니다.

회사 소개가 아니라 의사결정 문서로

일반적인 발표자료는 발표자가 이야기를 이어갑니다. 제안서는 혼자서도 읽혀야 합니다. 그래서 Proposal은 예쁜 소개 페이지보다 판단에 필요한 흐름을 먼저 만듭니다.

입력한 내용에 모든 항목이 없다면 억지로 페이지를 만들지 않습니다. 지금 있는 사실로 가장 설득력 있는 순서를 만들고, 검토자가 멈추는 지점을 드러냅니다.

제안서에는 고객명, 가격, 일정, SLA, 유사 실적처럼 틀리면 안 되는 정보가 많습니다. 빈칸을 자연스럽게 채우는 AI의 습관이 여기서는 가장 큰 위험이 됩니다.

Proposal은 사용자가 제공한 사실만 상업 조건으로 사용합니다. 없는 금액이나 사례는 만들어내지 않고, 필요하면 [고객명], [투자 금액], [일정], [유사 실적]처럼 검토할 수 있는 자리로 남깁니다.

참고 제안서도 마찬가지입니다. 순서와 표현 방식은 참고할 수 있지만, 그 문서의 고객·가격·로고·성과가 새 제안서의 사실로 넘어오지는 않습니다.

Proposal에는 다섯 가지 레이아웃 변형이 있습니다. 권고안이 중심인 페이지, 범위를 비교하는 페이지, 일정과 책임을 보는 페이지가 모두 같은 카드 배열일 수는 없기 때문입니다.

16:9와 4:3에도 각각 맞는 구성을 사용합니다. 커버 역시 미리 정한 표지를 붙이는 대신 실제 제안 내용과 선택한 테마를 바탕으로 생성해 본문과 자연스럽게 이어집니다.

Proposal을 선택한 뒤 고객 상황, 목표, 범위, 제외할 일, 일정, 예산처럼 이미 결정된 사실을 먼저 적어보세요. 아직 모르는 정보는 모른다고 써도 됩니다.

제조사의 해외 영업 대시보드 구축 제안서를 만들어줘. 기간은 8주이고 데이터 연동과 관리자 교육을 포함해. 하드웨어 구매는 제외하고, 예산은 아직 미정으로 표시해줘.

좋은 제안서는 빈칸이 없는 문서가 아닙니다. 결정할 수 있는 것과 더 확인해야 할 것을 정확히 나눈 문서입니다. Proposal은 그 구분에서 시작합니다.