Update nexus: fix conflicts and sync local changes
This commit is contained in:
Shen Wei
@@ -1,59 +1,59 @@
|
||||
---
|
||||
title: "Sales Engineer Agent"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-25
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/sales/sales-engineer.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：售前工程师（Sales Engineer）Agent 的角色定义、能力模型与操作框架，专注于在 B2B 技术评估中赢得技术决策
|
||||
- 问题域：B2B 软件销售中的技术售前环节——如何设计演示、执行 POC、应对竞争、处理异议、管理评估流程
|
||||
- 方法/机制：Demo Engineering（以影响力为导向的演示设计）、POC Scoping（严格限定的概念验证范围）、FIA Framework（事实-影响-行动竞争定位框架）、Evaluation Notes（交易级技术情报维护）
|
||||
- 结论/价值：技术决策先于商业决策，售前工程师必须将每一次技术对话连接到业务成果，而非单纯展示功能
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 售前工程师赢得技术决策，销售才能赢得商业合同——技术层是整个交易的关键门槛
|
||||
- 演示不是产品tour，而是叙事——买家在演示中看到自己的问题被实时解决
|
||||
- POC 不是免费试用，而是有二元结果的结构化评估：成功或失败，标准在开始前就已明确定义
|
||||
- 竞争定位应采用 FIA 框架（Fact-Impact-Act），保持事实基础和可操作性，而非情绪化和反应式
|
||||
- 永远不要攻击竞争对手——认可竞争对手的优势，同时清晰表达差异化
|
||||
|
||||
## Key Quotes
|
||||
> "A demo is not a product tour. A demo is a narrative where the buyer sees their problem solved in real time." — 演示的本质是叙事，不是功能演示
|
||||
> "Every technical conversation must connect back to a business outcome or it's just a feature dump." — 技术对话必须连接到业务成果
|
||||
> "Ambiguous success criteria produce ambiguous outcomes, which produce 'we need more time to evaluate,' which means you lost." — 模糊的成功标准等于失败
|
||||
> "Never trash the competition. Buyers respect SEs who acknowledge competitor strengths while clearly articulating differentiation." — 永远不要攻击竞争对手
|
||||
|
||||
## Key Concepts
|
||||
- [[Demo Engineering]]：以影响力为导向的演示设计，先量化问题，再展示产品，最后证明效果
|
||||
- [[POC Scoping]]：严格限定的概念验证范围设计，以成功标准、硬性时间线和检查点为支柱
|
||||
- [[FIA Framework]]：Fact-Impact-Act 竞争定位框架，保持事实基础和可操作性
|
||||
- [[Evaluation Notes]]：交易级技术情报维护，结构化记录每个活跃交易的技术环境、决策者、竞争态势和演示策略
|
||||
- [[Technical Objection Handling]]：技术异议处理，解码真实问题而非表面问题
|
||||
- [[Aha Moment]]：演示中让买家产生"这正是我们需要的"那一刻，是演示成功的核心标志
|
||||
|
||||
## Key Entities
|
||||
- [[Sales Pipeline Analyst Agent]]：同属销售团队的数据分析 Agent，共同支撑销售闭环
|
||||
- [[Sales Outbound Strategist Agent]]：同属销售团队的对外策略 Agent，共同支撑销售闭环
|
||||
- [[Deal Strategist Agent]]：同属销售团队的交易策略 Agent，共同支撑销售闭环
|
||||
- [[Account Strategist Agent]]：同属销售团队的客户策略 Agent，共同支撑销售闭环
|
||||
- [[Sales Proposal Strategist]]：同属销售团队的建议书策略 Agent，共同支撑销售闭环
|
||||
|
||||
## Connections
|
||||
- [[Sales Pipeline Analyst Agent]] ← team_member ← [[Sales Engineer Agent]]
|
||||
- [[Sales Outbound Strategist Agent]] ← team_member ← [[Sales Engineer Agent]]
|
||||
- [[Deal Strategist Agent]] ← team_member ← [[Sales Engineer Agent]]
|
||||
- [[Account Strategist Agent]] ← team_member ← [[Sales Engineer Agent]]
|
||||
- [[Sales Proposal Strategist]] ← team_member ← [[Sales Engineer Agent]]
|
||||
- [[Sales Discovery Coach Agent]] ← adjacent_role ← [[Sales Engineer Agent]]
|
||||
- [[Sales Coach Agent]] ← adjacent_role ← [[Sales Engineer Agent]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Sales Discovery Coach Agent]] 在"技术深度"维度存在互补张力：
|
||||
- 冲突点：售前工程师在发现阶段应保持多深的技术参与度？
|
||||
- 当前观点（Sales Engineer）：售前工程师应主导技术发现，结构化地挖掘架构、集成、安全约束和真实技术决策标准
|
||||
- 对方观点（Sales Discovery Coach）：销售发现应聚焦于业务问题，深度技术探索由专门的角色或时机负责
|
||||
- 协调方向：在发现阶段早期以业务语言建立信任，进入评估阶段后切换为技术深度模式
|
||||
---
|
||||
title: "Sales Engineer Agent"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-25
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/sales/sales-engineer.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：售前工程师（Sales Engineer）Agent 的角色定义、能力模型与操作框架，专注于在 B2B 技术评估中赢得技术决策
|
||||
- 问题域：B2B 软件销售中的技术售前环节——如何设计演示、执行 POC、应对竞争、处理异议、管理评估流程
|
||||
- 方法/机制：Demo Engineering（以影响力为导向的演示设计）、POC Scoping（严格限定的概念验证范围）、FIA Framework（事实-影响-行动竞争定位框架）、Evaluation Notes（交易级技术情报维护）
|
||||
- 结论/价值：技术决策先于商业决策，售前工程师必须将每一次技术对话连接到业务成果，而非单纯展示功能
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 售前工程师赢得技术决策，销售才能赢得商业合同——技术层是整个交易的关键门槛
|
||||
- 演示不是产品tour，而是叙事——买家在演示中看到自己的问题被实时解决
|
||||
- POC 不是免费试用，而是有二元结果的结构化评估：成功或失败，标准在开始前就已明确定义
|
||||
- 竞争定位应采用 FIA 框架（Fact-Impact-Act），保持事实基础和可操作性，而非情绪化和反应式
|
||||
- 永远不要攻击竞争对手——认可竞争对手的优势，同时清晰表达差异化
|
||||
|
||||
## Key Quotes
|
||||
> "A demo is not a product tour. A demo is a narrative where the buyer sees their problem solved in real time." — 演示的本质是叙事，不是功能演示
|
||||
> "Every technical conversation must connect back to a business outcome or it's just a feature dump." — 技术对话必须连接到业务成果
|
||||
> "Ambiguous success criteria produce ambiguous outcomes, which produce 'we need more time to evaluate,' which means you lost." — 模糊的成功标准等于失败
|
||||
> "Never trash the competition. Buyers respect SEs who acknowledge competitor strengths while clearly articulating differentiation." — 永远不要攻击竞争对手
|
||||
|
||||
## Key Concepts
|
||||
- [[Demo Engineering]]：以影响力为导向的演示设计，先量化问题，再展示产品，最后证明效果
|
||||
- [[POC Scoping]]：严格限定的概念验证范围设计，以成功标准、硬性时间线和检查点为支柱
|
||||
- [[FIA Framework]]：Fact-Impact-Act 竞争定位框架，保持事实基础和可操作性
|
||||
- [[Evaluation Notes]]：交易级技术情报维护，结构化记录每个活跃交易的技术环境、决策者、竞争态势和演示策略
|
||||
- [[Technical Objection Handling]]：技术异议处理，解码真实问题而非表面问题
|
||||
- [[Aha Moment]]：演示中让买家产生"这正是我们需要的"那一刻，是演示成功的核心标志
|
||||
|
||||
## Key Entities
|
||||
- [[Sales Pipeline Analyst Agent]]：同属销售团队的数据分析 Agent，共同支撑销售闭环
|
||||
- [[Sales Outbound Strategist Agent]]：同属销售团队的对外策略 Agent，共同支撑销售闭环
|
||||
- [[Deal Strategist Agent]]：同属销售团队的交易策略 Agent，共同支撑销售闭环
|
||||
- [[Account Strategist Agent]]：同属销售团队的客户策略 Agent，共同支撑销售闭环
|
||||
- [[Sales Proposal Strategist]]：同属销售团队的建议书策略 Agent，共同支撑销售闭环
|
||||
|
||||
## Connections
|
||||
- [[Sales Pipeline Analyst Agent]] ← team_member ← [[Sales Engineer Agent]]
|
||||
- [[Sales Outbound Strategist Agent]] ← team_member ← [[Sales Engineer Agent]]
|
||||
- [[Deal Strategist Agent]] ← team_member ← [[Sales Engineer Agent]]
|
||||
- [[Account Strategist Agent]] ← team_member ← [[Sales Engineer Agent]]
|
||||
- [[Sales Proposal Strategist]] ← team_member ← [[Sales Engineer Agent]]
|
||||
- [[Sales Discovery Coach Agent]] ← adjacent_role ← [[Sales Engineer Agent]]
|
||||
- [[Sales Coach Agent]] ← adjacent_role ← [[Sales Engineer Agent]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Sales Discovery Coach Agent]] 在"技术深度"维度存在互补张力：
|
||||
- 冲突点：售前工程师在发现阶段应保持多深的技术参与度？
|
||||
- 当前观点（Sales Engineer）：售前工程师应主导技术发现，结构化地挖掘架构、集成、安全约束和真实技术决策标准
|
||||
- 对方观点（Sales Discovery Coach）：销售发现应聚焦于业务问题，深度技术探索由专门的角色或时机负责
|
||||
- 协调方向：在发现阶段早期以业务语言建立信任，进入评估阶段后切换为技术深度模式
|
||||
|
||||
Reference in New Issue
Block a user