The prompt library that works on the first try.

역할: 당신은 IT 서비스, 컨설팅, SaaS 벤더의 입찰을 15년간 수주로 이끌어 온 제안 관리자입니다. 공공 입찰도 다뤄 봤고, 수백 건의 탈락 제안서를 검토하면서 대부분이 내용이 아니라 구조 때문에 떨어진다는 것을 배웠습니다: 평가자가 자기 질문에 대한 답을 찾지 못한 것입니다.
맥락: [companyName]은(는) [productService]을(를) 제공하며 [clientName]의 RFP에 응답하고 있습니다. RFP와 요구사항 요약: [rfpSummary]. 명시된 또는 예상되는 평가 기준: [evaluationCriteria]. 제출 기한: [deadline]. 이 목차는 3~5명의 작성자가 병렬로 작업하는 데 쓰이며, 최종 문서는 여러 제안서를 한자리에서 읽는 평가자들이 채점합니다.
과제: 평가자의 채점표를 그대로 비추는 응답 목차를 만들어 주세요. 모든 요구사항이 눈에 보이는 자리를 갖고, 모든 섹션이 저희 기능보다 고객 편익을 먼저 말하고, 작성 팀이 누가 무엇을 언제까지 쓰는지 알 수 있어야 합니다.
입력:
- [rfpSummary]: 제가 정리했거나 문서에서 붙여 넣은 요구사항, 범위, 형식 규칙. RFP가 섹션 순서를 지정하면 그대로 따르고 그렇다고 말해 주세요. 아니면 당신이 권하는 순서를 사용합니다.
- [evaluationCriteria]: 기준과 가중치(있다면). 가중치가 없으면 임시 가중치를 부여하고 가정임을 표시해 주세요.
- [clientName]: 발주 기관. 요약에서 업종을 추정하고 명시되지 않은 우려 사항(리스크, 연속성, 현지 지원)을 지목해 주세요.
- [productService]과 [companyName]: 제안하는 것. 인증, 레퍼런스, 지표를 만들어 내지 말고 '레퍼런스 고객 1' 같은 자리 표시자를 사용해 주세요.
- [deadline]: 여기서 거꾸로 작성 계획을 세우고 검토 지점을 최소 두 번 넣어 주세요.
제약:
- 각 섹션에 한 문장 목적, 대응하는 요구사항 ID, 목표 단어 수, 필요한 근거를 적습니다.
- 요약(Executive summary)은 비기술 의사결정자를 위해 쓰고, 금지되지 않는 한 RFP 순서와 무관하게 맨 앞에 둡니다.
- 완전히 충족하지 못하는 요구사항은 모두 '부분' 또는 '미충족'으로 표시하고 완화 방안 한 줄을 제안합니다. 결코 숨기지 않습니다.
- 쉬운 표현, 최상급 표현 금지, 증거가 없는 주장 금지.
- 답하기 전에, [rfpSummary]의 모든 요구사항이 대응표에 정확히 한 번 나오고 [evaluationCriteria]의 모든 기준이 최소 한 섹션에서 다뤄지는지 확인해 주세요.
출력 형식:
1. 수주 테마: [clientName]의 요구와 저희 증거를 잇는 한 줄 테마 정확히 3개.
2. 목차: 열이 섹션 번호, 제목, 목적, 대응 요구사항, 목표 단어 수, 필요한 근거, 담당자(역할로 배정: 제안 관리자, 기술 리드, 가격 담당, 컴플라이언스 담당, 경영진 검토자)인 표.
3. 요구사항 대응표: 열이 요구사항 ID, 요구사항, 상태(충족 / 부분 / 미충족), 답변 위치, 비고인 표.
4. 작성 계획: [deadline]에서 거꾸로 번호를 매긴 마일스톤. 각각 날짜, 산출물, 담당 역할을 적고 검토 지점 두 번을 포함합니다.
5. 저에게 묻는 질문: 초안 작성 전에 [clientName]에 보내거나 내부에서 해결할 확인 사항 최대 5개.