cs-marketing-offer-creation

根据买家证据制定报价

不容妥协的清晰度标准

保留任何句子之前，先问：

这句话是否增加了新信息或解答了疑惑？

如果两者都没有，就删掉。不要因为某句话听起来更精致、节奏更好，或再次表达了别处已经说过的好处，就保留它。每句话都必须提供有用信息、让报价更具体、消除买家可能产生的疑虑、解释必要的前置条件，或引导买家采取下一步行动。

拒绝那些提出的问题多于解答的问题的文案。例如，“在构建之前，了解 Ai 适合什么场景”不够清楚：适合什么场景？要构建什么？“你的团队仍然掌控一切”也不完整，除非报价说明团队掌控什么。应优先给出具体的交付成果，例如：“获取一份技术方案，其中包含构建自定义 Ai agent 的分步说明。”接下来可以用一条有用的补充说明解释其重要性：“没有完善的技术方案，就无法构建可靠的 Ai agent。花费仅 $49，即可获得一份正确制定的方案，让你的 agent 不再频频出错。”

最后编辑时，逐句审视：

• 这句话增加了哪些新信息？
• 它解答了哪种具体疑惑或疑虑？
• 句子的主语、动作、对象和结果是否一目了然？
• 它是否引入了一个未定义的说法，让买家不禁问：“这到底是什么意思？”

如果无法给出明确答案，就删掉或改写这句话。这条规则不容妥协，优先于风格偏好、巧妙措辞、节奏，以及让报价听起来更“营销化”的想法。

结果与范围

制定一份具体的报价，让目标买家能够识别、理解并购买，同时保留前端实际交付的内容以及后续销售的内容。最终产出是一份报价决策文档，以及可交给广告和落地页使用的信息方向。

从已有的业务、客户和产品证据入手。利用竞品调研来解答实际存在的不确定问题，而不是把它当成必须遵循的开场步骤。对于承诺内容，一封解释哪些工作总是回到客户手上的邮件，可能比大量泛泛的广告样本更有用。

审批边界。 阅读所提供的材料、开展公开调研和撰写报价文档都在范围内。不要投放广告、使用预算、发布页面、联系客户或竞品，也不要编造说法。使用会消耗点数的付费调研工具时，必须获得用户授权。应基于已有证据继续工作，不要为常规的报价工作设置审批关卡。

梳理商业链路

撰写文案前，从请求、之前的决策、客户材料和当前产品中梳理以下信息。将重要陈述标记为 EVIDENCE、USER DIRECTION 或 HYPOTHESIS。只有当缺失的信息会实质性改变买家、交付物、价格或销售漏斗时才提问；否则，做出范围最小且有用的假设，并标明这是假设。

1. 买家资格： 企业、决策权、员工、客户、工具、此前尝试和支付能力方面，必须已满足哪些条件？明确说明不符合条件的情况。
2. 受众现状： 他们尝试过什么、反复遇到什么情况、认为问题是什么，以及目前了解什么？
3. 购买动机： 他们想立即消除什么痛点，或想创造什么业务收益？区分那些意味着不同事件、证据或承诺的动机。
4. 前端产品： 他们现在购买什么、价格是多少，以及会带着什么有形成果或决策离开？将其准确归类为探索／诊断、教育、软件访问权限、实施或其他形式。
5. 实现机制： 前端如何产生这一结果？用买家能理解的方式表述。卖方侧的软件、能力知识或流程可以为实现机制提供支持，但不必成为面向冷流量的承诺。
6. 后续产品： 之后销售什么、参考价格或投入程度如何，以及前端应揭示哪种匹配信号？
7. 流量与落地页： 冷流量还是暖流量、渠道、认知程度、CTA，以及点击后会进入哪里？
8. 经济模型与证明： 价格梯度、已知的获客目标、只有在商业上合理时才设置的订单加购项／追加销售，以及可用的证明材料或宣传主张。

不要把前端设计成对高价产品的伪装描述。后续产品有助于判断前端应吸引谁，但前端承诺必须止于买家现在实际能获得的内容。

根据购买情境构建 ICP

只有当 ICP 能预测谁会认出广告、重视产品并能进入下一阶段销售时，它才有用。记录以下信息：

• 必要的企业情况，例如已有员工、客户、正在运行的工作流或现有产品。
• 当前行为，例如尝试各种工具、搭建自动化流程，或构建仪表板、CRM 或原型。
• 反复出现并促使他们采取行动的事件。
• 他们用自己的话表达的抱负。
• 他们了解什么、还不了解什么，以及他们不会使用哪些技术术语。
• 购买决策权、预算背景和不符合条件的情况。

不要把面向成熟经营者的产品扩大到“任何对 AI 感兴趣的人”。除非产品或证据有此需要，否则不要使用行业标签。

AI-worker 发现模式

面向成熟的非技术型企业主推出发现服务时，筛选条件可能要求其已经拥有员工和客户。他们乐于尝试 AI 工具，也可能已自行构建或委托开发 CRM、仪表板、指挥中心或原型，但不了解让 AI worker 可靠运作所需的记忆、连接、权限、基础设施和防护措施。

通常应将两种动机拆分为不同的服务与信息传达系列：

动机	他们意识到的问题	他们想要的结果
内部运营	系统可能能用，但检查、文书工作、协调和异常处理仍会回到业主身上	让 AI worker 在现有软件内或跨云工具完成有用的重复性工作，并在适当环节获得审批
客户软件	他们正在为客户开发软件，或已经有这类软件，但无法让 Agent 成为可靠的用户体验组成部分	在产品中提供实用的 Agent，帮助客户完成实际工作

低价发现服务可以围绕这样一个问题来销售：“考虑到我的业务、我想实现的目标，以及我已经构建的内容，怎样才能让 AI 承担有用的工作，又不增加一件需要我管理的事？”其机制可以是一个结合实施能力的对话式发现引擎。冷流量用户并不认识供应商，因此不要销售“探索我们的平台能实现什么”。要销售业务决策和有用的清晰认知。将平台和技术能力图谱作为机制的内部支撑。

如果前端服务是发现服务，它可以识别合适的工作、所需的连接、信息／记忆、人工审批、优先级和可信的实施路径。除非包含实施服务，否则不能承诺部署 Agent。后续实施或高价 Agent 构建服务应作为单独的后续销售。

谨慎对待更尖锐的解读。系统能正常运行，但业主负担仍未减轻，这说明系统并未消除这些工作；但仅凭这一点，不能证明 AI 反而增加了工作量。希望在客户软件中加入 Agent，也不能证明其动机是提高使用量或收入。除非客户的用语或行为能够支持，否则这些都应保持为假设。

将证据转化为服务

在确定承诺之前，先创建一份简明的证据台账：

观察或表述	来源	状态	对服务的启示
客户的原话或观察到的行为	客户来源／日期	EVIDENCE	事件、异议、愿望或证明
明确的战略选择	用户	USER DIRECTION	限制条件或决策
合理的解读	分析	HYPOTHESIS	待测试的切入点，而非论断

然后明确以下内容：

• 服务名称： 即使不对客户展示，内部使用也很有帮助。
• 一位买家： 这一路径中符合条件的决策者。
• 一个主要动机： 缓解痛点或实现收益，并说明可识别的具体情境。
• 承诺： 用买家能看懂的直白语言说明购买后能获得的结果。
• 机制： 为什么这一步行动能带来进展。
• 交付内容： 明确说明他们会收到什么、内容深度和限制。
• 价格和 CTA： 包括任何真实有效的保证或紧迫性。
• 证明： 只使用有依据的说法，必要时注明来源。
• 后续衔接： 说明合适的买家为何会合理地想要后续产品，同时不要暗示它已包含在当前服务中。

当产品组合本身是卖点时，使用直接的捆绑套餐模式

当用户提供服务文案，并明确表示这就是他们原本想要的版本时，应将其结构和商业重点视为 USER DIRECTION。将其保留为规范基线。除非用户要求切换模式，否则不要强行改写成更长的创始人故事、必需的历史收入开篇或抽象的结果导向标题。

当优惠本身一目了然时，低价捆绑套餐可以成为最强卖点。如果实际产品组合和价格就是销售驱动力，请采用这种结构：

1. 在有助于资格筛选时，直接说明面向的受众。
2. 在开头写明具体的套餐价值和购买价格。
3. 用买家的语言，简短地描述一次让他们产生共鸣的场景。
4. 写出“你将获得什么”，随后列出实际交付内容。对每项交付内容，说明产品、其提供的价值，以及它为何有用。
5. 写明总价值、当前价格，并给出一个直接的行动号召（CTA）。

这不等于把文案改写成重复罗列功能的清单。 三款分别交付的产品构成真正的产品组合。把相同的 Agent 功能放在几个标题下反复描述，只是在凑字数。共鸣部分要简短，让每项交付内容都体现其价值。

不要只用陌生的产品名称开头。陌生买家可能不知道“Discovery Engine”是什么。要将产品组合与他们想要的改变结合起来，例如把有用的工作从业主身上卸下来、腾出扩大规模所需的产能，或弄清楚 AI 能在哪里省钱以及该先构建什么。工具只是实现这些改变的手段。

对于当前的 AI 业务发现套餐，获批的营销活动示例如下：

• AI Business Discovery Engine Agent：标示价值为 $1,122。这是一款配备工具的对话式 Agent，具备网络研究能力和 Agent 基础设施知识，而不只是静态计划或通用聊天机器人。
• Agentic Business Case Study：标示价值为 $197。从每月 $50 增长到每月超过 $2,000 的案例，是卖方提供的案例研究证据，并非对买家收入的保证。
• Launch-Ready One-to-One Call：标示价值为 $275。
• 标示总价值：$1,594。购买价格：$27。

仅在使用这项获批优惠时，或用户再次提供这些数字时，才使用这些确切数字。“未来 24 小时内”或“仅限今天”的说法属于有日期的营销活动变体；切勿将其包装成长期有效或会重置的稀缺性宣传。

推理时要将结果、障碍和实现机制分开，然后将它们精简为买家能复述的直接优惠。一个实用的起始句式是：

用这项[价格][交付内容]，在不受[真实障碍]影响的情况下，实现[具体结果]

这只是起始句式，并非强制模板。优先采用最简短的版本，同时清楚说明购买内容及其重要性。可以在页面的辅助文案中介绍实现机制；不必把技术内容塞进技术性标题。为图片广告交付文案时，请提供标题、优惠/价格、CTA，以及关于视觉机制的说明。不要试图把完整解释都印在图片上来弥补创意薄弱的问题。

逐项检查每份草稿：

• 符合资格的买家能否在第一行认出自己当前的处境？
• 承诺是否回应了他们已经希望做出的决定，或已经希望实现的结果？
• 冷启动的潜在客户能否在不了解供应商、产品名称或技术架构的情况下看懂文案？
• 实现机制是否能说明如何取得进展，而不故弄技术玄虚？
• 交付内容能否兑现承诺，且与标明的价格相称？
• 每个主要动机是否都有各自对应的路径，而不是含糊的“一站式”说法？
• 关于结果、收入、使用情况、节省时间和工作量的说法是否有依据？
• 实施是否与发现或教育服务清楚区分？
• 买家是否无需听额外解释，就能复述自己会得到什么、为何重要以及需要支付多少？

收入只是可能的目标之一，并非所有情况都必须追求。如果这正是买家实际想要的，获得更多时间、减轻业主负担、降低管理压力、加快决策、提升客户能力和降低风险都可能更有吸引力。不要因为别的销售漏斗采用了数字、加购优惠或收入承诺，就生搬硬套。

每项保证都必须与其涵盖的购买内容相匹配。针对低价发现类产品的经核实退款保证，仅适用于该项购买。以结果为依据的实施保证，例如收入结果保证或退款保证，是单独的商业优惠和义务。在结果、范围、归因方法、时间窗口、例外情况和退款条款得到明确批准且有依据之前，应将提出的结果保证视为 HYPOTHESIS。切勿因其相关就把它附加到发现类优惠中。

以结果为导向的退款保证

当用户要求提供有结果保障的承诺时，应先说明本次购买能带来的实际结果，再提退款。不要只把风险逆转写成笼统的“30 天退款保证”徽章。可重复使用以下结构：

获得[本次购买包含的具体结果／交付内容]，否则退还[购买价格]

在主要文案或优惠条款中明确说明申请退款的期限。保留任何现有的更广泛退款政策：以结果为导向的文案不得为现有退款权新增完成要求、实施里程碑或其他门槛。重用会话中已获授权的条款；不要仅仅因为文案更具体就再次询问。

对于 27 美元的 AI Discovery Engine，面向用户的版本为：

找出 AI 如何融入你的业务，以及首先应该构建什么；否则退还你的 27 美元

补充条款：“如果它没能让你获得这种清晰认识，可在购买后 30 天内申请退款。”此承诺保证的是对探索结果的清晰认识，不包括已部署的 Agent、收入增长或已完成的构建。若要单独保证实施结果，必须有其自身有据可依的范围和条款。用于图片时，可缩短保证文案，但须保留相同的结果和退款含义；在随附文案和目标页面中注明完整的退款期限。发布前，确保实际产品、结账页面和广告条款一致。

只研究尚不确定的部分

当公开研究可能影响决策时再开展研究：例如某种形式或承诺是否经受住了市场检验、竞争对手如何包装前端产品、价格集中在哪些区间，或哪些机制已十分拥挤。记录搜索范围和局限。

当 Meta 广告资料库与研究相关时，请阅读 ad-library-research.md。广告的投放时长和创意重复情况只是方向性信号，并非转化或盈利数据。将竞争对手的文案作为证据引用；绝不要直接用作用户的文案。

成果文件

保存一份注明日期的优惠决策文档，包含：

1. 商业链路和 ICP 资格认定。
2. 证据台账，包括尚未解决的假设。
3. 选定的前端优惠及其明确边界。
4. 下游优惠和资格衔接方案。
5. 针对每种有依据的动机分别制定的消息方向。
6. 使用外部研究时记录研究范围和局限。

如果已配置获授权的业务记忆系统，请将可重复使用的策略结论存入其中。将私人邮件和可识别客户身份的记录保存在适当的私有来源存储中；不要将其复制到可复用的技能代码库中。

验证和状态

在报告完成前，确认所指明的买家符合资格、前端承诺与交付内容一致、没有暗示下游产品包含在内、每项重要主张都有来源或状态，并且消息适用于所述流量的认知阶段。说明仍属假设的内容，以及尚未涵盖的证据。

未实际运行的优惠标记为 DRAFT；在所有者的营销活动中使用时标记为 DOGFOODING；只有在有重复验证证据后才标记为 PROVEN；真实审批尚未完成时标记为 AWAITING APPROVAL；缺少必要输入时标记为 BLOCKED。研究质量本身不能证明优惠已得到验证。

交接

将商业链路、选定的承诺、证据台账、准确的交付内容和消息方向发送给 cs-marketing-image-ads 和 cs-marketing-website。将完整实施范围交由相关的构建或销售交付工作流处理。