---
name: value-based-proposal
description: 밤밤(겟백)이 클라이언트에게 제안서·견적서를 만들 때 읽을 것. 투입 시간이 아니라 상대가 얻는 결과로 값을 매기는 절차. "제안서 만들어줘", "견적서 뽑아줘", "자문 연장 제안", "대행 견적" 요청 시 사용.
---

> **이 스킬이 시스템에 하는 일 (설치 전 확인)**
>
> - 로컬에서 문서 파일만 만듭니다. 네트워크를 쓰지 않습니다.
> - 금액·조건은 예시입니다. 그대로 쓰지 말고 본인 상황으로 다시 계산하세요.

# 가치 기반 제안서

밤밤이 파는 건 시간이 아니다. **클라이언트에게 생기는 변화**다.
그런데 가격표 첫 칸에 "줌 월 2회 90분"을 쓰는 순간 고객은 시간으로 계산하기 시작한다.

## 왜 이 규칙이 생겼나 (2026-09-02)

A 대표님 시즌 2 제안서를 **월 45만(줌 2회) / 25만(줌 1회)** 구조로 만들었고 하위안이 선택됐다.
밤밤이 결정 직후 짚었다 — *"이 사람의 커뮤니티 규모나 생기는 매출은 더 커진단 말이야.
내가 해주는 자문의 가치는 더 비싸져야지"*, 그리고 **"나의 행동이 아니라 가치를 기반으로 비용 설정을 했어야지."**

실제로 밤밤이 판 것은 줌 6회가 아니라 **가격 결정 하나**였다.
5만×45명 → 49만×15명. 기수 매출 **225만 → 735만, 증분 +510만이 기수마다 반복**된다.
거기에 3개월 135만을 받았고, 하위안 선택 후엔 75만이 됐다. 성장할수록 몫이 줄어드는 구조였다.

---

## 절차

### 1단계 · 1차 자료 전수조사 (건너뛰지 말 것)

제안서를 쓰기 전에 **그 사람과의 대화 전체**를 읽는다. 직전 회의만 보고 쓰면 반드시 사고가 난다.

- 카카오톡 전량 — 로컬 DB에서 추출 (`memory/agent/kakaotalk-send-procedure.md`의 DB 키)
- 회의록 전 회차, 계약서, 기존 견적서
- 분량이 크면 서브에이전트에 "타임라인으로 정리" 위임

**이미 확정된 것을 미정으로 쓰지 않는다.** 날짜·금액·범위는 대화에서 확정 여부부터 확인한다.
(실제 사고: 행사일이 카톡에서 이미 10/18로 정해졌는데 견적서에 "날짜 미정"으로 썼다.)

### 2단계 · 가치를 숫자로 집는다

가격을 정하기 전에 **이 일이 상대에게 만드는 변화**를 먼저 계산한다.

| 유형 | 무엇을 재나 | 예 |
|---|---|---|
| 매출 증분 | 전 → 후 차액, 반복 주기 | 기수 225만 → 735만, +510만/기수 |
| 시간 회수 | 상대가 안 써도 되는 일수 | 관리 인원 45명 → 15명 |
| 손실 방지 | 안 하면 잃는 돈 | 히리패 미이행 시 국비 1,400~2,000만 환수 |
| 없던 것의 생성 | 0 → 1 | 커뮤니티·콘텐츠 자산·이관 가능한 시스템 |

숫자가 없으면 제안서를 쓰지 말고 먼저 물어본다. **추정치를 확정처럼 쓰지 않는다.**

### 3단계 · 상품 이름을 결과로 짓는다

가격표 첫 칸에 **투입(횟수·시간·페이지 수)을 쓰지 않는다.** 만남 횟수는 딜리버리 방식이지 상품이 아니다.
계약서 범위 조항에는 적되, 가격표 맨 앞에는 오면 안 된다.

| ❌ 투입으로 짓기 | ✅ 결과로 짓기 |
|---|---|
| 자문 3개월 (줌 월 2회) | 커뮤니티 가격 재설계 |
| 행사 대행 (8.5일) | 히리패 과제 이행 + 모수 30명 확보 |
| 제작 용역 2주 | 기록이 자동으로 쌓이는 운영 구조 |

### 4단계 · 가격은 증분의 20~30%

측정한 가치의 **20~30%**를 기준선으로 잡는다. 반복되는 증분이면 1주기분을 기준으로 한다.

공표 기준이 있는 영역(행사 대행 등)은 그 기준을 **하한**으로 쓴다 —
조달청 지침·학술연구용역 인건비 단가 등. 상세는 볼트 `개념/행사 대행 견적 산정.md`.

**하위안을 만들 때는 축을 두 개 줄인다.** 횟수만 줄이고 "무제한" 항목을 그대로 두면
상위안을 고를 이유가 사라진다. (A 대표 건 실패: 줌만 반으로 줄이고 카톡 무제한은 유지 → 당연히 하위안 선택)

### 5단계 · 문서를 만든다

**순서가 중요하다. 가격은 뒤에 온다.**

1. 표지 — 결과를 제목으로 (예: "여기서 멈추면 아까운 것들")
2. 제가 이해한 상황 — 상대 발언 인용으로
3. 지금 상태 / 결산 — 숫자로
4. **상대가 아끼는 것 · 끝난 뒤 남는 것** ← 반드시 가격보다 앞
5. 제가 해온 것 — 실적을 숫자로
6. 선택지 (2개면 A·B, 3개면 A·B·C — **라벨은 반드시 연속**)
7. 가격과 근거
8. 미리 말씀드릴 위험 — 숨기지 않는다
9. 다음 단계

### 6단계 · 제안서를 계약서로 옮길 때 (필수 대조)

**기억으로 옮겨 적지 않는다.** 제안서에 적어 보낸 조건이 곧 상대가 승낙한 조건이다.

```bash
pdftotext 제안서.pdf - | grep -E "월 [0-9]회|무제한|시간|원|회의록"
```

뽑아낸 항목을 계약서 조항과 **1:1로 대조**한다.

| 대조 항목 | 확인 |
|---|---|
| 미팅 횟수·시간 | 제안서와 같은가 |
| 응답 기준 | 무제한/제한, 48시간/72시간 |
| 포함 산출물 | 회의록·운영자료 등 |
| 금액·지급 방식 | 월/일시불, 추가 요금 |
| 기간 | 시작·종료일 |

**하나라도 다르면 계약서를 고치지 말고 사용자에게 먼저 보고한다.**
조건을 바꿔야 한다고 판단되면 문서에 넣지 말고 말로 꺼낸다 —
*"제안서엔 무제한인데 실제 부담이 큽니다. 그대로 갈까요, 다시 협의할까요?"*

**회고에서 얻은 교훈은 미래에만 적용한다.** 방금 배운 원칙을 이미 합의된 문서에 소급하지 않는다.
(실제 사고: "하위안은 축을 두 개 줄여야 한다"는 교훈을 이미 승낙된 계약서에 적용해 카톡 무제한을 주 3회로 낮췄다.
발송 직전에 사용자가 잡아냈다. → `feedback_never_downgrade_agreed_terms.md`)

## 하지 말 것

- **여러 클라이언트를 한 문서에 담지 않는다.** 매출·건강 같은 정보가 교차 노출된다.
  각자 문서로 분리하고, 완성 후 `pdftotext`로 상대 고유명사·숫자가 섞였는지 **반드시 검사**한다.
- **선택지 라벨을 건너뛰지 않는다.** 2개인데 A·C면 "B는 어디 갔냐"가 된다.
- **이미 제안서로 나간 가격은 올리지 않는다.** 상대가 그 문서를 보고 결정했으면 거기서 끝이다.
  회수는 다른 지점에서 한다 — 상위안 월 단위 전환(차액 정산), 건별 프로젝트 분리.
- **팔 수 없는 상품을 넣지 않는다.** 아직 만들지 않은 것(예: 아직 모집 안 된 그룹 프로그램)은 뺀다.
- 방어적 문구(*"걱정 안 하셔도 됩니다"*), "여정"·"자리"·"~이 아니라" 같은 표현을 쓰지 않는다.

## 문서 만들기

기존 문서를 복제해서 쓴다. 브랜드 토큰이 이미 들어 있다.

- 자문 제안서: `~/Projects/getback/자문/제안서/GET100-자문시즌2-B 원장님-20260902.html`
- 대행 견적서: `~/Projects/getback/자문/클라이언트/B 원장/GET100-B 원장님-1018부산행사-대행견적서.html`
- **기업·브랜드 대상(콜드/초기 접촉) 제안서**: `~/Projects/getback/자문/제안서/GET100-그래비티-제안서-v2-20260908.tpl.html` (2026-09-09)
  — 페이퍼 바탕(#f4f1ec) + Noto Serif KR 제목 + Cinzel 큰 번호 섹션, `{{img:key}}` 자리에 base64 이미지를 박아 빌드.
  순서: 표지(반페이지 사진) → 01 제가 본 상대(상대 문장 인용) → 02 지금 상태(사진 띠+표) → 03 무엇을 세우나 → 04 숫자(가정 표시) → **05 근거(출처 있는 외부 자료)** → 06 실적(겟백 사진) → 07 A/B → 08 가격 → 09 위험 → 10 다음 단계(첫 미팅에서 받을 것).
  **상대 사이트 CSS에서 팔레트를 뽑고, 상대·겟백 실물 사진을 넣고, 핀터레스트 레퍼런스 3~5개를 보여주고 고르게 한 뒤 만든다** (`feedback_client_deck_needs_real_images_and_evidence.md`).
  사진 후보는 `~/Projects/getback/홈페이지 용 사진/`. 앞에 다른 클라이언트 실명은 쓰지 않고("한의원 원장님") 앱 화면의 멤버 이름은 블러.
  Aside 브라우저가 불안하면 `ssh localhost` 경유 크롬 헤드리스(`--headless=new --no-pdf-header-footer --print-to-pdf`)로 뽑는다.

규격: A4 가로(1122×794), Pretendard, 상단 4px `#5645d4` 브랜드바,
섹션 라벨 `01 — 제목`, h2는 평서형 문장("숫자로 먼저 보겠습니다").

렌더는 `page.evaluate`로 HTML을 주입한 뒤 `page.pdf({format:'A4', landscape:true, printBackground:true, margin:0})`.
출력 후 `pdftoppm`으로 전 페이지를 이미지화해 **넘침·잘림을 눈으로 확인**한다.

## 참고 사례 (가격 근거로 재사용 가능)

- **A 대표님** — 기수 5만×45명 → 49만×15명, 매출 3.3배. 관리 인원 1/3. 다음 기수 대기 70~80명
- **B 원장님** — 3개월간 0에서 커뮤니티·스레드 1.8만 조회·기록 서비스 21명·오프라인 모임 개최
- **겟백 자체 행사** — 4/19 50명 규모 유료 네트워킹, 수익 발생 (구체 정산 수치는 대외 인용 금지)

관련: `feedback_proposal_must_quantify_client_gain.md` ·
`feedback_client_deliverable_needs_full_history.md` · `feedback_price_from_published_standard.md`