sales-proposal-template

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Design Reusable Qwilr Proposal Templates

设计可复用的Qwilr提案模板

Help the user design a system of reusable Qwilr templates that their whole sales team can use — with standardized structure, consistent branding, and token-ready fields for API/CRM auto-population.

帮助用户设计一套可供整个销售团队使用的可复用Qwilr模板系统——具备标准化结构、统一品牌风格，以及支持API/CRM自动填充的token就绪字段。

Step 1 — Gather context

步骤1 — 收集上下文

Ask the user:

What does your team sell?
- Product/service description, typical deal sizes, buyer personas
How many distinct deal types do you have?
- A) One product, one buyer type — just need one template
- B) 2-3 variations (e.g., SMB vs. enterprise, or different products)
- C) 4+ variations (verticals, regions, product lines)
- D) Not sure — help me figure it out
What's broken with proposals today?
- A) Every rep builds from scratch — inconsistent quality
- B) We have templates but they're outdated or hard to customize
- C) Proposals take too long to create
- D) Pricing is presented inconsistently
- E) We're starting fresh — no templates exist yet
How do you want reps to use these templates?
- A) Manually in Qwilr — pick a template, customize, send
- B) Auto-generated from CRM data via API
- C) Both — auto-generated with manual customization
- D) Not sure — what do you recommend?

If the user's request already provides most of this context, skip directly to the relevant step. Lead with your best-effort answer using reasonable assumptions (stated explicitly), then ask only the most critical 1-2 clarifying questions at the end — don't gate your response behind gathering complete context.

询问用户：

你的团队销售什么产品/服务？
- 产品/服务描述、典型交易规模、买家画像
你们有多少种不同的交易类型？
- A) 单一产品、单一买家类型 — 只需1个模板
- B) 2-3种变体（例如：中小企业版 vs 企业版，或不同产品）
- C) 4种及以上变体（垂直领域、区域、产品线）
- D) 不确定 — 帮我梳理清楚
当前提案流程存在哪些问题？
- A) 每个销售代表都从零开始创建 — 质量参差不齐
- B) 我们有模板，但已过时或难以自定义
- C) 提案创建耗时过长
- D) 定价展示不一致
- E) 我们从零开始 — 尚无任何模板
你希望销售代表如何使用这些模板？
- A) 在Qwilr中手动操作 — 选择模板、自定义、发送
- B) 通过API从CRM数据自动生成
- C) 两者结合 — 自动生成后可手动自定义
- D) 不确定 — 你有什么建议？

如果用户的请求已提供大部分此类上下文，可直接跳至相关步骤。 先基于合理假设给出最佳方案（需明确说明假设），最后仅询问1-2个最关键的澄清问题 — 不要要求用户提供完整上下文才给出回复。

Step 2 — Template strategy

步骤2 — 模板策略

Based on the context, design the template system:

基于收集到的上下文，设计模板体系：

How many templates do you need?

需要多少个模板？

Use the minimum number of templates that covers your deal types. A good rule of thumb:

Scenario	Templates needed
One product, one buyer	1 master template
One product, SMB + Enterprise buyers	2 templates (different depth/formality)
Multiple products, same buyer	1 template per product
Multiple products + buyer segments	Matrix — but cap at 5-6 and use conditional sections

使用覆盖所有交易类型的最少模板数量。参考准则：

场景	所需模板数量
单一产品、单一买家	1个主模板
单一产品、中小企业+企业买家	2个模板（深度/正式程度不同）
多种产品、同一买家群体	每个产品对应1个模板
多种产品+多买家细分	矩阵式 — 但最多控制在5-6个，并使用条件性板块

Fixed vs. variable sections

固定板块 vs 可变板块

Every template should have:

Fixed sections (same across all proposals):

Company intro / "About Us" — consistent brand story
Team / contact section — auto-populated per rep
Legal / terms section — standard terms, rarely changed
CTA / acceptance section — standard accept flow

Variable sections (customized per deal):

Executive summary — tailored to each prospect's situation
Problem/solution framing — adapted to the buyer's pain points
Scope of work — specific to the deal
Pricing / quote block — deal-specific line items and amounts

Conditionally included sections (used for some deals, not others):

Case studies — pick the one most relevant to the prospect's industry
Technical architecture — only for technical buyers
ROI / business case — only for enterprise or executive buyers
Security & compliance — only when procurement requires it

每个模板应包含：

固定板块（所有提案保持一致）：

公司介绍 / “关于我们” — 统一品牌故事
团队 / 联系方式板块 — 按销售代表自动填充
法律 / 条款板块 — 标准条款，极少修改
行动号召 / 接受板块 — 标准接受流程

可变板块（按交易自定义）：

执行摘要 — 针对每个潜在客户的情况量身定制
问题/解决方案框架 — 适配买家的痛点
工作范围 — 特定于当前交易
定价 / 报价模块 — 交易专属的明细项目和金额

条件性板块（仅用于部分交易）：

案例研究 — 选择与潜在客户行业最相关的案例
技术架构 — 仅面向技术买家
投资回报率 / 商业案例 — 仅面向企业或高管买家
安全与合规 — 仅当采购部门要求时使用

Step 3 — Template blueprints

步骤3 — 模板蓝图

For each template, provide a detailed blueprint:

为每个模板提供详细蓝图：

Template blueprint format

模板蓝图格式

Template name: [name] Use when: [which deal type this is for] Audience: [buyer persona]

Section	Block Type	Fixed/Variable	Content notes
Cover	Splash	Variable	`{{company_name}}` , `{{contact_name}}` , custom headline
Executive Summary	Text	Variable	Rep writes this per deal — provide a fill-in-the-blank framework
Problem & Solution	Text	Semi-fixed	Template copy with `{{industry}}` and `{{pain_point}}` tokens
Scope of Work	Accordion	Variable	Rep customizes deliverables per deal
Pricing	Quote block	Variable	Pre-configured sections and line items, rep adjusts amounts
Case Study	Text + Image	Conditional	Library of 3-5 case studies, rep picks the most relevant
Timeline	Text	Semi-fixed	Standard phases with `{{start_date}}` token
About Us	Text + Image	Fixed	Same across all proposals
Team	Text + Image	Variable	Auto-populated with rep's info via `{{rep_name}}` , `{{rep_photo}}`
Next Steps	Accept block	Fixed	Standard acceptance flow

模板名称：[名称] 适用场景：[对应交易类型] 受众：[买家画像]

板块	Block Type	固定/可变	内容说明
封面	Splash	可变	`{{company_name}}` 、 `{{contact_name}}` 、自定义标题
执行摘要	Text	可变	销售代表按交易撰写 — 提供填空式框架
问题与解决方案	Text	半固定	模板文案包含 `{{industry}}` 和 `{{pain_point}}` token
工作范围	Accordion	可变	销售代表按交易自定义交付内容
定价	Quote block	可变	预配置的板块和明细项目，销售代表调整金额
案例研究	Text + Image	条件性	3-5个案例研究库，销售代表选择最相关的案例
时间线	Text	半固定	标准阶段，包含 `{{start_date}}` token
关于我们	Text + Image	固定	所有提案保持一致
团队	Text + Image	可变	通过 `{{rep_name}}` 、 `{{rep_photo}}` 自动填充销售代表信息
下一步	Accept block	固定	标准接受流程

Copy frameworks for variable sections

可变板块的文案框架

For sections reps need to customize, provide fill-in-the-blank frameworks rather than leaving them blank:

Executive Summary framework:

[Company] is [one-line description of their situation]. Based on our conversations with [contact name] and the [team/department], the key priorities are:

[Priority 1 — from discovery]

[Priority 2 — from discovery]

[Priority 3 — from discovery]

This proposal outlines how [your company] will address these priorities with [solution overview], delivering [primary expected outcome] within [timeframe].

Problem/Solution framework:

The challenge: [Industry] companies like [company] face [common challenge]. Specifically, [contact]'s team is dealing with [specific pain point from discovery].

Our approach: [Solution] addresses this by [how it works], which means [outcome in their terms].

Provide similar frameworks for each variable section.

对于销售代表需要自定义的板块，提供填空式框架而非空白：

执行摘要框架：

[客户公司]目前[一句话描述其现状]。基于我们与[联系人姓名]及[团队/部门]的沟通，核心优先级为：

[优先级1 — 来自需求调研]

[优先级2 — 来自需求调研]

[优先级3 — 来自需求调研]

本提案概述了[你的公司]将如何通过[解决方案概述]解决这些优先级问题，在[时间范围]内实现[主要预期成果]。

问题/解决方案框架：

挑战：[行业]公司如[客户公司]面临[普遍挑战]。具体而言，[联系人]的团队正面临[来自需求调研的特定痛点]。

我们的方案：[解决方案]通过[工作原理]解决此问题，这意味着[用他们的语言描述成果]。

为每个可变板块提供类似框架。

Step 4 — Token design

步骤4 — Token设计

Design the substitution tokens for API/CRM auto-population:

设计用于API/CRM自动填充的替换token：

Standard tokens (use across all templates)

标准token（所有模板通用）

Token	Source	Example
`{{company_name}}`	CRM: Company name	Acme Corp
`{{contact_first_name}}`	CRM: Contact first name	Jane
`{{contact_last_name}}`	CRM: Contact last name	Smith
`{{contact_title}}`	CRM: Contact title	VP Engineering
`{{contact_email}}`	CRM: Contact email	jane@acme.com
`{{rep_name}}`	CRM: Deal owner name	Alex Johnson
`{{rep_title}}`	CRM: Deal owner title	Account Executive
`{{rep_email}}`	CRM: Deal owner email	alex@company.com
`{{deal_amount}}`	CRM: Deal amount	$48,000
`{{close_date}}`	CRM: Expected close date	March 30, 2026

Token	数据来源	示例
`{{company_name}}`	CRM：公司名称	Acme Corp
`{{contact_first_name}}`	CRM：联系人名字	Jane
`{{contact_last_name}}`	CRM：联系人姓氏	Smith
`{{contact_title}}`	CRM：联系人职位	VP Engineering
`{{contact_email}}`	CRM：联系人邮箱	jane@acme.com
`{{rep_name}}`	CRM：交易负责人姓名	Alex Johnson
`{{rep_title}}`	CRM：交易负责人职位	Account Executive
`{{rep_email}}`	CRM：交易负责人邮箱	alex@company.com
`{{deal_amount}}`	CRM：交易金额	$48,000
`{{close_date}}`	CRM：预计成交日期	March 30, 2026

Custom tokens (deal-type specific)

自定义token（特定交易类型）

Token	Source	Example
`{{industry}}`	CRM: Industry field	Financial Services
`{{company_size}}`	CRM: Employee count	500 employees
`{{product_name}}`	CRM: Product field	Enterprise Plan
`{{seat_count}}`	CRM: Custom field	25 seats
`{{pain_point}}`	Manual or CRM notes	Slow incident response times
`{{start_date}}`	CRM: Custom field	April 15, 2026

Token	数据来源	示例
`{{industry}}`	CRM：行业字段	Financial Services
`{{company_size}}`	CRM：员工数量	500 employees
`{{product_name}}`	CRM：产品字段	Enterprise Plan
`{{seat_count}}`	CRM：自定义字段	25 seats
`{{pain_point}}`	手动输入或CRM备注	Slow incident response times
`{{start_date}}`	CRM：自定义字段	April 15, 2026

Token guidelines for the team

团队使用token的准则

Always auto-populate: company_name, contact names, rep info, deal amount — these should never be manually entered
Semi-auto: industry, company_size, product — auto-populated but rep should verify
Always manual: executive summary, pain points, custom scope — these need human judgment
Fallback values: Set sensible defaults for optional tokens so the page doesn't show raw
```
{{token}}
```
text if a field is empty

始终自动填充：company_name、联系人姓名、销售代表信息、交易金额 — 这些绝不应该手动输入
半自动：industry、company_size、product — 自动填充但销售代表需验证
始终手动输入：执行摘要、痛点、自定义工作范围 — 这些需要人工判断
回退值：为可选token设置合理默认值，避免字段为空时页面显示原始
```
{{token}}
```
文本

Step 5 — Asset library and rollout

步骤5 — 资产库与推广

Template asset library

模板资产库

Recommend supporting assets to create alongside templates:

Case study library: 3-5 case studies tagged by industry/use case, stored as Qwilr saved blocks
Headshot library: Professional photos of team members for the "Team" section
Logo library: Customer logos for social proof sections
Quote block presets: Pre-configured pricing structures for common deal types

建议随模板一同创建配套资产：

案例研究库：3-5个按行业/使用场景标记的案例研究，存储为Qwilr已保存板块
头像库：团队成员的专业照片，用于“团队”板块
Logo库：客户Logo，用于社交证明板块
报价模块预设：针对常见交易类型预配置的定价结构

Team rollout plan

团队推广计划

Build: Create templates in Qwilr using saved blocks
Document: Write a one-page guide per template — when to use it, which sections to customize, token reference
Train: Walk the team through 1-2 live examples in a 30-minute session
Test: Have 2-3 reps create proposals from the templates and collect feedback
Iterate: Refine based on rep feedback and buyer engagement data (via
```
/sales-proposal-analytics
```
)
Automate: Once templates are stable, connect to CRM for auto-generation (via
```
/sales-qwilr-automation
```
)

搭建：使用已保存板块在Qwilr中创建模板
文档化：为每个模板撰写一页指南 — 适用场景、需自定义的板块、token参考
培训：通过30分钟的现场演示向团队讲解1-2个实例
测试：让2-3名销售代表使用模板创建提案并收集反馈
迭代：基于销售代表反馈和买家互动数据（通过
```
/sales-proposal-analytics
```
）优化模板
自动化：模板稳定后，连接至CRM实现自动生成（通过
```
/sales-qwilr-automation
```
）

Gotchas

注意事项

Don't make templates too rigid. Templates should give reps a strong starting point, not a straitjacket. If reps can't easily customize the executive summary, scope, and pricing for their specific deal, they'll stop using the template. Use fill-in-the-blank frameworks, not fixed copy.
Don't forget variable placeholders. Every template should use
```
{{token}}
```
syntax for fields that will be auto-populated (company name, contact info, rep info, deal amount). Claude sometimes writes templates with hardcoded example values instead of tokens.
Don't design for one deal type when the team handles multiple. Ask how many distinct deal types exist before building templates. A single template for "SMB SaaS" and "Enterprise Financial Services" will serve neither well. But also don't over-segment — most teams need 2-4 templates, not 15.
Don't forget mobile responsiveness. Qwilr pages are web-based and will be viewed on phones and tablets. Avoid designs that depend on side-by-side layouts or wide tables that break on small screens. Test the template on mobile before rolling out.
Don't create templates without a rollout plan. A great template that reps don't know about or don't know how to use is wasted effort. Always include guidance on when to use each template and how to customize the variable sections.

不要让模板过于僵化：模板应为销售代表提供坚实的起点，而非束缚。如果销售代表无法轻松自定义执行摘要、工作范围和定价以适配特定交易，他们将不再使用模板。使用填空式框架，而非固定文案。
不要忘记变量占位符：每个模板应使用
```
{{token}}
```
语法标记将被自动填充的字段（公司名称、联系人信息、销售代表信息、交易金额）。Claude有时会用硬编码的示例值而非token来撰写模板。
不要在团队处理多种交易类型时仅设计一种模板：在搭建模板前询问有多少种不同的交易类型。一个同时适用于“中小企业SaaS”和“企业金融服务”的模板无法很好地服务于任何一方。但也不要过度细分 — 大多数团队需要2-4个模板，而非15个。
不要忘记移动端响应式：Qwilr页面基于网页，会在手机和平板上查看。避免依赖在小屏幕上会失效的并排布局或宽表格。推广前在移动端测试模板。
不要在没有推广计划的情况下创建模板：一个优秀但销售代表不知道或不知道如何使用的模板是白费功夫。始终包含关于何时使用每个模板以及如何自定义可变板块的指导。