rfp-response

name	rfp-response
description	RFP·제안요청서를 해부해 평가항목별로 이기는 제안서를 만든다(사업이해·수행전략·추진체계·투입인력·실적·품질·가격). 공공 입찰·기업 수주 공통. "제안서 / RFP / 제안요청서 / 수주 제안 / 입찰 제안서 / 평가표 대응 / 제안 전략" 요청 시.

작업 흐름(항상): 왜(목적·의도) → 무엇을 → 어떻게 → 기존 컨텍스트·리서치 → 기획 → 시각화 → 호출·실행 → 🔁회고·보완. 자세히 [[method]].

rfp-response — 평가표대로 이기는 제안서

제안서는 잘 쓴 글이 아니라 채점표에서 이기는 문서다. 평가위원이 무엇에 몇 점을 주는지부터 역산한다.

발동: 호출·연계 (선제 아님)

사용자가 부르거나 [[public-procurement]]·[[partnership]]이 제안 단계에서 연계로 호출한다.

산출 유형: COPILOT(작성·문답) / DECISION(제출·투찰=사람 승인) — 승인 주체는 [[role]]로 판정한다. (자세히 [[method]])

1. RFP 해부 (여기서 승부의 절반)

• 과업 범위·필수요건(미충족 시 탈락)·평가배점(정량·정성)·감점·자격·마감·제출형식을 뜯는다.
• 배점 지도를 그린다 → 점수 큰 항목에 자원과 분량을 몰고, 필수요건은 하나도 빠뜨리지 않는다.
• 발주처의 진짜 니즈·숨은 우려(RFP 행간)를 읽는다. 과거 유사 발주·수요기관 성향을 리서치.

2. Win theme · 차별화

• "왜 우리인가" 한 문장(win theme)을 세우고 전 섹션이 이를 향하게. 경쟁사 대비 우위·리스크 제거 논리.

3. 제안서 구조 (평가위원 관점)

1. 사업 이해 — 발주처 문제·목표를 우리가 정확히 안다는 신호.
2. 수행 전략·차별화 — 어떻게, 왜 이 방법이 최선인가(근거).
3. 추진 체계·일정 — WBS·마일스톤·거버넌스.
4. 투입 인력·조직 — 핵심 인력 역량·역할(과업 적합성).
5. 유사 실적 — 관련성 높은 것부터, 성과 수치와 함께(없는 실적 금지).
6. 품질·리스크 관리 — 산출물 품질보증·리스크와 대응.
7. 가격/산출내역 — 공공이면 원가계산·산출내역서([[public-procurement]]).

• 각 섹션 첫 줄에 평가항목과의 매핑을 의식해 쓴다(위원이 채점하기 쉽게).

4. 마무리

• 평가위원 예상 질의·발표(PT) 대비. 제출 전 필수요건·형식·분량·증빙 체크.
• 공공이면 규정·양식은 [[public-procurement]]·[[legal]], 기업이면 [[partnership]] 톤·거래구조. 제출은 [[decision-memo]] 후 [[role]]로 판정 — 내 decision_scope 안이면 승인자 확정 후 제출, 밖이면 상신용 초안+승인요청(reports_to 명시). 어느 경우든 투찰=DECISION(사람 승인).

원칙

• 근거 없는 실적·수치·인증 금지 — 허위 제안은 부정당제재·계약 해지로 돌아온다. 모르면 "확인 필요".
• 상대 유형(공공/기업/학교/비영리)에 맞춰 톤·근거·형식을 바꾼다 → [[sector-playbook]].