Proposal
A proposal is not just a document.
A proposal is a decision tool.
Most weak proposals fail for the same reason: they explain what will be done,
but not why it matters, why this approach fits, what outcome is being bought,
what risks are reduced, or what decision should happen next.
A good proposal reduces hesitation by making the value, structure, and choice clearer.
This skill helps turn vague offers into persuasive, usable proposals.
Trigger Conditions
Use this skill when the user needs to:
- - create a proposal for a client, customer, partner, or stakeholder
- structure an offer after discovery or intake
- present scope, pricing, terms, and timeline clearly
- improve proposal win rate
- turn a service idea into a decision-ready document
- compare proposal options or packaging
- rewrite a weak or confusing proposal
- align a proposal with the buyer's goals and constraints
Also trigger when the user says things like:
- - "Help me write a proposal"
- "I need to send an offer"
- "How should I structure this proposal"
- "Turn this into a client proposal"
- "Why is my proposal not converting"
- "I need pricing and scope explained clearly"
Core Principle
A proposal should make the buyer feel:
- - understood
- confident
- clear on what happens next
The proposal is not mainly about your service.
It is about the buyer's problem, the promised outcome, the logic of the solution,
the boundaries of the work, and the terms under which a decision feels safe.
What This Skill Does
This skill helps:
- - translate discovery into a structured offer
- define the problem, outcome, and proposed approach
- clarify scope, timeline, pricing, assumptions, and boundaries
- improve proposal logic and persuasiveness
- reduce ambiguity that creates delay or mistrust
- structure options when helpful
- move the reader toward a decision rather than passive review
Default Outputs
Depending on the request, produce one or more of the following:
- 1. Proposal Draft
A full proposal with sections, flow, and buyer-facing language.
- 2. Proposal Structure
An outline showing what sections should exist and why.
- 3. Offer Framing
A clearer articulation of problem, value, outcome, and fit.
- 4. Scope and Pricing Model
A structured explanation of deliverables, assumptions, options, and fees.
- 5. Proposal Audit
A diagnosis of why an existing proposal feels weak, unclear, or low-converting.
- 6. Decision Version
A simplified proposal optimized for quick stakeholder review and approval.
Response Rules
When responding:
- - start from the buyer's goals, not the seller's features
- define the problem before presenting the solution
- connect deliverables to outcomes
- make scope and exclusions explicit
- reduce ambiguity around timeline, pricing, and responsibility
- use options only when they clarify rather than confuse
- distinguish confidence from hype
- end with a clear decision path
Proposal Architecture
~~~python
PROPOSAL_ARCHITECTURE = {
"core_elements": {
"context": "What the buyer is dealing with and why this matters now",
"goal": "What outcome the buyer wants",
"approach": "How the proposed work addresses the goal",
"scope": "What is included and what is not",
"timeline": "When major steps and outcomes happen",
"pricing": "How the work is priced and why",
"terms": "What assumptions, responsibilities, and conditions apply",
"decision_path": "What the buyer should do next"
},
"guiding_questions": [
"What problem is the buyer trying to solve",
"Why now",
"What does success look like",
"Why this approach over alternatives",
"What uncertainty could block approval",
"What part of the proposal is most likely to create hesitation"
]
}
~~~
Proposal Workflow
~~~python
PROPOSAL_WORKFLOW = {
"step
1extract
buyingcontext": {
"purpose": "Clarify what decision the proposal is supporting",
"outputs": [
"buyer goal",
"pain point",
"urgency",
"stakeholders",
"constraints"
]
},
"step
2define_offer": {
"purpose": "Translate need into a concrete solution shape",
"outputs": [
"recommended approach",
"deliverables",
"work phases",
"client responsibilities",
"assumptions"
]
},
"step
3define_boundaries": {
"purpose": "Prevent later ambiguity",
"outputs": [
"included items",
"excluded items",
"change logic",
"approval points",
"dependency risks"
]
},
"step
4price
andpackage": {
"purpose": "Present the commercial logic clearly",
"outputs": [
"fee structure",
"payment terms",
"option tiers if useful",
"rationale for pricing"
]
},
"step
5reduce_friction": {
"purpose": "Address what may slow or block a yes",
"methods": [
"clarify process",
"remove jargon",
"answer obvious objections",
"make next steps simple",
"show credibility without overloading"
]
},
"step
6close_cleanly": {
"purpose": "Make the decision path explicit",
"outputs": [
"decision options",
"acceptance step",
"timeline to start",
"what happens after approval"
]
}
}
~~~
Common Proposal Types
~~~python
PROPOSAL_TYPES = {
"service_proposal": {
"use_when": "Selling a defined service engagement",
"focus": ["problem", "scope", "timeline", "pricing", "deliverables", "working model"]
},
"project_proposal": {
"use_when": "Proposing a project with phases and milestones",
"focus": ["objectives", "phases", "dependencies", "ownership", "success criteria"]
},
"partnership_proposal": {
"use_when": "Exploring a strategic or commercial collaboration",
"focus": ["shared value", "roles", "economics", "coordination model", "risk"]
},
"internal_proposal": {
"use_when": "Seeking approval from internal stakeholders",
"focus": ["business case", "cost", "impact", "tradeoffs", "decision ask"]
},
"retainer_proposal": {
"use_when": "Structuring ongoing work over time",
"focus": ["scope rhythm", "capacity", "reporting", "responsiveness", "renewal logic"]
}
}
~~~
Proposal Logic
~~~python
PROPOSAL_LOGIC = {
"principles": [
"The buyer cares more about outcome than activity",
"Specificity builds confidence",
"Unclear scope creates slow decisions",
"Every proposal implies a risk allocation",
"The document should match the buyer's attention span and decision style",
"More pages do not equal more persuasion"
],
"common_failures": [
"Too much about the seller",
"No clear problem framing",
"Deliverables disconnected from business value",
"Scope hidden in vague language",
"Pricing presented without logic",
"No clear call to decision",
"Trying to impress instead of clarify"
],
"corrections": [
"Lead with the buyer's objective",
"Show why the approach fits",
"Tie work to outcomes and constraints",
"Define scope and exclusions clearly",
"Make decision steps obvious",
"Reduce unnecessary complexity"
]
}
~~~
Proposal Output Format
Proposal Summary
- - Buyer or Stakeholder:
- Goal:
- Problem or Opportunity:
- Recommended Approach:
- Scope:
- Timeline:
- Pricing or Commercial Structure:
- Key Assumptions:
- Risks or Open Questions:
- Recommended Next Step:
Boundaries
This skill helps structure and improve proposals, offers, and decision documents.
It does not replace legal, tax, financial, procurement, or contract advice.
For regulated, high-value, or high-risk deals, outputs should be reviewed against the
user's jurisdiction, internal policies, and formal agreements.
Quality Check Before Delivering
- - [ ] The buyer's goal is clearly stated
- [ ] The proposal explains why this approach fits
- [ ] Scope and exclusions are explicit
- [ ] Timeline and pricing are understandable
- [ ] Assumptions and responsibilities are visible
- [ ] The proposal supports a decision, not just a read-through
- [ ] The next step is concrete
提案
提案不仅仅是一份文件。
提案是一种决策工具。
大多数薄弱的提案失败的原因相同:它们解释了将要做什么,但没有说明为什么重要、为什么这种方法合适、购买了什么成果、降低了哪些风险、或者下一步应该做什么决定。
一份好的提案通过让价值、结构和选择更清晰来减少犹豫。
这项技能有助于将模糊的提议转化为有说服力、可用的提案。
触发条件
当用户需要以下情况时使用此技能:
- - 为客户、顾客、合作伙伴或利益相关者创建提案
- 在需求发现或信息收集后构建报价
- 清晰呈现范围、定价、条款和时间表
- 提高提案中标率
- 将服务想法转化为可供决策的文件
- 比较提案选项或打包方案
- 重写薄弱或令人困惑的提案
- 使提案与买家的目标和约束条件保持一致
当用户说出类似以下内容时也触发:
- - 帮我写一份提案
- 我需要发送一份报价
- 我应该如何构建这份提案
- 把这个变成客户提案
- 为什么我的提案转化率不高
- 我需要清晰解释定价和范围
核心原则
一份提案应该让买家感到:
提案主要不是关于你的服务。
而是关于买家的问题、承诺的成果、解决方案的逻辑、
工作的边界,以及让决策感到安全的条款。
这项技能的作用
这项技能有助于:
- - 将需求发现转化为结构化的报价
- 定义问题、成果和拟议方法
- 明确范围、时间表、定价、假设和边界
- 提高提案的逻辑性和说服力
- 减少造成延迟或不信任的模糊性
- 在有用时构建选项
- 推动读者做出决策,而不是被动审阅
默认输出
根据请求,生成以下一项或多项:
- 1. 提案草稿
包含章节、流程和面向买家语言的完整提案。
- 2. 提案结构
显示应包含哪些章节及其原因的提纲。
- 3. 报价框架
对问题、价值、成果和匹配度的更清晰阐述。
- 4. 范围与定价模型
对可交付成果、假设、选项和费用的结构化说明。
- 5. 提案审计
诊断现有提案为何薄弱、不清晰或转化率低的原因。
- 6. 决策版本
为快速利益相关者审阅和批准而优化的简化提案。
响应规则
回应时:
- - 从买家的目标出发,而非卖家的特性
- 在提出解决方案之前先定义问题
- 将可交付成果与成果联系起来
- 明确范围和排除项
- 减少时间表、定价和责任方面的模糊性
- 仅在有助于澄清而非混淆时使用选项
- 区分信心与夸大
- 以清晰的决策路径结束
提案架构
~~~python
PROPOSAL_ARCHITECTURE = {
核心要素: {
背景: 买家正在处理什么以及为什么现在重要,
目标: 买家想要什么成果,
方法: 拟议工作如何实现目标,
范围: 包括什么和不包括什么,
时间表: 主要步骤和成果何时发生,
定价: 工作如何定价及其原因,
条款: 适用哪些假设、责任和条件,
决策路径: 买家下一步应该做什么
},
引导性问题: [
买家试图解决什么问题,
为什么是现在,
成功是什么样的,
为什么选择这种方法而非其他方案,
哪些不确定性可能阻碍批准,
提案的哪部分最可能造成犹豫
]
}
~~~
提案工作流程
~~~python
PROPOSAL_WORKFLOW = {
步骤一_提取购买背景: {
目的: 明确提案支持什么决策,
输出: [
买家目标,
痛点,
紧迫性,
利益相关者,
约束条件
]
},
步骤二_定义报价: {
目的: 将需求转化为具体的解决方案形态,
输出: [
推荐方法,
可交付成果,
工作阶段,
客户责任,
假设
]
},
步骤三_定义边界: {
目的: 防止后续模糊性,
输出: [
包含项,
排除项,
变更逻辑,
审批节点,
依赖风险
]
},
步骤四_定价与打包: {
目的: 清晰呈现商业逻辑,
输出: [
费用结构,
付款条款,
选项层级(如有用),
定价理由
]
},
步骤五_减少摩擦: {
目的: 解决可能延缓或阻碍同意的问题,
方法: [
澄清流程,
去除行话,
回答明显的异议,
简化后续步骤,
展示可信度而不过度
]
},
步骤六_干净收尾: {
目的: 明确决策路径,
输出: [
决策选项,
接受步骤,
启动时间表,
批准后的流程
]
}
}
~~~
常见提案类型
~~~python
PROPOSAL_TYPES = {
服务提案: {
使用场景: 销售明确的服务合作,
重点: [问题, 范围, 时间表, 定价, 可交付成果, 工作模式]
},
项目提案: {
使用场景: 提出包含阶段和里程碑的项目,
重点: [目标, 阶段, 依赖关系, 所有权, 成功标准]
},
合作提案: {
使用场景: 探索战略或商业合作,
重点: [共享价值, 角色, 经济性, 协调模式, 风险]
},
内部提案: {
使用场景: 寻求内部利益相关者的批准,
重点: [商业案例, 成本, 影响, 权衡, 决策请求]
},
顾问服务提案: {
使用场景: 构建长期持续的工作,
重点: [范围节奏, 能力, 报告, 响应速度, 续约逻辑]
}
}
~~~
提案逻辑
~~~python
PROPOSAL_LOGIC = {
原则: [
买家更关心成果而非活动,
具体性建立信心,
不清晰的范围导致决策缓慢,
每份提案都隐含风险分配,
文件应匹配买家的注意力持续时间和决策风格,
更多页数不等于更多说服力
],
常见失败原因: [
过多关于卖家,
没有清晰的问题框架,
可交付成果与商业价值脱节,
范围隐藏在模糊语言中,
定价呈现没有逻辑,
没有明确的决策号召,
试图给人留下印象而非澄清
],
纠正措施: [
以买家的目标为先导,
展示为什么方法合适,
将工作与成果和约束联系起来,
清晰定义范围和排除项,
使决策步骤显而易见,
减少不必要的复杂性
]
}
~~~
提案输出格式
提案摘要
- - 买家或利益相关者:
- 目标:
- 问题或机会:
- 推荐方法:
- 范围:
- 时间表:
- 定价或商业结构:
- 关键假设:
- 风险或未解决问题:
- 推荐下一步:
边界
这项技能有助于构建和改进提案、报价和决策文件。
它不能替代法律、税务、财务、采购或合同建议。
对于受监管、高价值或高风险交易,输出应根据用户的司法管辖区、内部政策和正式协议进行审查。
交付前质量检查
- - [ ] 买家的目标已明确说明
- [ ] 提案解释了为什么这种方法合适
- [ ] 范围和排除项明确
- [ ] 时间表和定价易于理解
- [ ] 假设和责任可见
- [ ] 提案支持决策,而不仅仅是供阅读
- [ ] 下一步是具体的