关于 proposal-development
proposal-development 是面向提案团队的技能,可从机会评估、赢单主题到提案、SOW 或口头陈述按需起草。它强调遵循招标要求、以可核实证据支撑内容,并明确标记缺失信息。
主要功能
- 01分析强制要求与评分标准
- 02按需起草提案、SOW 或陈述
- 03将要求追溯到证据与负责人
- 04核验范围、费用与材料一致性
适用场景
- 01评估项目是否值得投入
- 02根据 RFP 编写合规提案
- 03起草工作说明书或口头陈述
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ anotb/ management-consulting-plugin --skill proposal-development安装后在 Claude Code 中输入/proposal-development确认已加载。
附带文件references/pitch-deck.mdreferences/proposal-and-sow.md
详细介绍
提案开发
针对客户的具体采购决策,制作有说服力且符合要求的提案。从用户要求的阶段开始:商机评估、制胜主题、提案、工作说明书(SOW)或口头陈述。对于已获批准的商机,不要再要求进行资格评估;如果用户要求的是有限修改,也不要重新制作已签署的协议。
使用用户提供的 RFP、对话记录、公司资质、人员配置和商务信息。遵守强制格式、章节顺序、页数限制和提交要求。完成有依据的章节,并准确标出缺少的资质或信息。不得编造客户成果、团队成员、认证、竞争对手情报、推荐案例或成果百分比。
了解采购决策
区分必须通过的要求、评分标准和推断出的偏好。记录提交截止日期、格式、强制附件、资格要求、评估权重和澄清流程。将每项重要要求追溯至其来源、回复位置、证据、负责人和完成状态。即使回复很有说服力,若未满足强制要求,也可能无法使用。
如果用户要求进行资格评估,则评估契合度、能力、产能、经济效益、战略价值和投标成本。说明建议继续或放弃的依据。不要编造中标概率,也不要仅凭某项不同寻常的要求就断定交易已内定;应指出相关证据以及需要核实的问题。
根据客户的优先事项和公司能够证实的依据,制定制胜主题。差异化优势应说明为什么该团队或方案适合这一问题,以及有哪些证据支持。使用条件式措辞,并不能为缺乏依据的节省金额范围或暗示的过往业绩开脱。
起草所需文档
对于提案,将客户面临的挑战与方法、交付物、成果、团队、证据、投资、假设和下一步决策相衔接。根据规定的回复顺序调整这一结构。应在提案完成后撰写执行摘要,确保其反映实际范围和条款。
对于 SOW,请参阅提案和 SOW 的具体做法。界定范围边界、验收标准、客户义务、依赖项、定价依据和变更控制。遵守已提供的合同条款,并区分拟议条款与已商定条款。不要将视为验收、责任上限或签字要求强加为普遍规则。
对于推介或口头答辩,请参阅推介演示文稿。遵守规定的时长、受众和决策目标。如有条件,可使用 engagement-pricing 辅助制定价格;但此技能也可独立使用。
说服力与证据
说明预期成果以及该方法如何实现成果。区分交付承诺与取决于客户行动或外部条件的业务效益预测。使用相关真实案例,并在获准的情况下注明出处;对假设性示例应准确标注。缺少的证明材料可以保留为明确的草稿标记;不要为了让文档看起来完整而编造内容填补空缺。
回应有依据的异议和重要风险。说明客户需要提供什么,以及方案提出了哪些取舍。避免泛泛而谈的能力宣称、缺乏依据的最高级表述,以及与请求无关的服务选项罗列。
完成并检查
交付用户要求的提案、SOW、推介材料或评估。如用户要求提供文件,请使用可用的文档或演示文稿工具以及格式技能(如有);不要求使用特定主机或插件。在工具允许的情况下,检查已保存的文档和渲染后的版式。
核实要求覆盖情况、章节和页数限制、范围、日期、人员配置和费用的一致性、资质依据,以及未解决事项是否清晰可见。使用可用工具核对计算。准备回复并不代表获准提交回复、联系买方或同意条款。说明哪些重大缺口会导致草稿无法直接提交。