Update nexus wiki content
This commit is contained in:
@@ -2,58 +2,55 @@
|
||||
title: "Sales Engineer Agent"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-25
|
||||
date: 2026-04-29
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/sales/sales-engineer.md]]
|
||||
- [[Agent/agency-agents/sales/sales-engineer.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：售前工程师（Sales Engineer）Agent 的角色定义、能力模型与操作框架，专注于在 B2B 技术评估中赢得技术决策
|
||||
- 问题域：B2B 软件销售中的技术售前环节——如何设计演示、执行 POC、应对竞争、处理异议、管理评估流程
|
||||
- 方法/机制：Demo Engineering（以影响力为导向的演示设计）、POC Scoping（严格限定的概念验证范围）、FIA Framework（事实-影响-行动竞争定位框架）、Evaluation Notes（交易级技术情报维护）
|
||||
- 结论/价值：技术决策先于商业决策，售前工程师必须将每一次技术对话连接到业务成果，而非单纯展示功能
|
||||
- 核心主题：Sales Engineer（售前工程师）Agent 的角色定义与核心能力框架，涵盖技术发现、Demo 工程、POC 设计、竞争技术定位和解决方案架构
|
||||
- 问题域：B2B 销售中如何赢得技术决策 —— 技术评估阶段的有效策略与方法论
|
||||
- 方法/机制：FIA 框架（Fact-Impact-Act）、"Aha Moment" 测试、POC 范围界定模板、竞争技术分层（Winning/Battling/Losing Zones）、结构化评估笔记
|
||||
- 结论/价值：技术销售的核心在于技术能力与业务结果的连接；没有技术胜利，就没有销售胜利
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 售前工程师赢得技术决策，销售才能赢得商业合同——技术层是整个交易的关键门槛
|
||||
- 演示不是产品tour，而是叙事——买家在演示中看到自己的问题被实时解决
|
||||
- POC 不是免费试用，而是有二元结果的结构化评估：成功或失败，标准在开始前就已明确定义
|
||||
- 竞争定位应采用 FIA 框架（Fact-Impact-Act），保持事实基础和可操作性，而非情绪化和反应式
|
||||
- 永远不要攻击竞争对手——认可竞争对手的优势，同时清晰表达差异化
|
||||
- 技术发现必须揭示架构、集成需求、安全约束和真实的技术决策标准，而非仅看公开 RFP
|
||||
- Demo 是叙事而非产品 tour —— 先量化问题，再展示产品，最后反向讲解机制
|
||||
- 每个 Demo 必须产生至少一个 "Aha Moment"，否则 Demo 失败
|
||||
- POC 是有二元结果的定向评估，而非免费试用；模糊的成功标准导致模糊的结局
|
||||
- FIA 框架保持技术定位基于事实，而非情绪化和反应式
|
||||
- 技术异议很少是表面问题；必须解码真实诉求
|
||||
- 精准优于大量：30 分钟精准命中三件事，胜过 90 分钟覆盖十二件事
|
||||
|
||||
## 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." — 永远不要攻击竞争对手
|
||||
> "A demo is not a product tour. A demo is a narrative where the buyer sees their problem solved in real time." — Demo 的本质定义
|
||||
> "You can't get the sales win without the technical win — but the technology is your toolbox, not your storyline." — 技术与商业的关系
|
||||
> "A proof of concept is not a free trial. It's a structured evaluation with a binary outcome: pass or fail, against criteria defined before the first configuration." — POC 的本质定义
|
||||
> "Technical objections are rarely about the stated concern." — 技术异议解码原则
|
||||
> "Credibility compounds. One dishonest answer erases ten honest ones." — 诚信的复利效应
|
||||
|
||||
## Key Concepts
|
||||
- [[Demo Engineering]]：以影响力为导向的演示设计，先量化问题，再展示产品，最后证明效果
|
||||
- [[POC Scoping]]：严格限定的概念验证范围设计，以成功标准、硬性时间线和检查点为支柱
|
||||
- [[FIA Framework]]：Fact-Impact-Act 竞争定位框架，保持事实基础和可操作性
|
||||
- [[Evaluation Notes]]：交易级技术情报维护，结构化记录每个活跃交易的技术环境、决策者、竞争态势和演示策略
|
||||
- [[Technical Objection Handling]]：技术异议处理，解码真实问题而非表面问题
|
||||
- [[Aha Moment]]：演示中让买家产生"这正是我们需要的"那一刻，是演示成功的核心标志
|
||||
- [[Technical Discovery]]：结构化需求分析，揭示架构、集成需求、安全约束和真实技术决策标准
|
||||
- [[Demo Engineering]]：影响优先的演示设计，在展示产品前量化问题，量体裁衣
|
||||
- [[POC Scoping]]：严格限范围的 POC 设计，包含前置成功标准、明确时间线和决策门槛
|
||||
- [[FIA Framework]]：Fact-Impact-Act，竞争技术定位框架，保持定位基于事实而非情绪
|
||||
- [[Aha Moment Test]]：每个 Demo 必须产生至少一个买家说"这正是我们需要的"时刻
|
||||
- [[Competitive Technical Positioning]]：竞争技术分层（Winning/Battling/Losing Zones）
|
||||
- [[Technical Objection Handling]]：技术异议解码，识别表面问题背后的真实诉求
|
||||
- [[Evaluation Management]]：端到端技术评估过程管理，从发现电话到 POC 决策和技术关闭
|
||||
- [[Solution Architecture]]：将产品能力映射到买方基础设施，设计降低感知风险的部署方案
|
||||
- [[Demo Tailoring]]：基于买家术语、数据模型和工作流语言定制 Demo，而非使用产品词汇
|
||||
|
||||
## Key Entities
|
||||
- [[Sales Pipeline Analyst Agent]]：同属销售团队的数据分析 Agent，共同支撑销售闭环
|
||||
- [[Sales Outbound Strategist Agent]]：同属销售团队的对外策略 Agent，共同支撑销售闭环
|
||||
- [[Deal Strategist Agent]]：同属销售团队的交易策略 Agent，共同支撑销售闭环
|
||||
- [[Account Strategist Agent]]：同属销售团队的客户策略 Agent，共同支撑销售闭环
|
||||
- [[Sales Proposal Strategist]]：同属销售团队的建议书策略 Agent，共同支撑销售闭环
|
||||
- （本文档为 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]]
|
||||
- [[Sales Pipeline Analyst]] ← related_to ← [[Sales Engineer]]：两者共同支撑销售管道分析
|
||||
- [[Sales Outbound Strategist]] ← related_to ← [[Sales Engineer]]：外呼策略与技术发现共享买家需求理解
|
||||
- [[Sales Deal Strategist]] ← related_to ← [[Sales Engineer]]：交易策略与技术评估协同
|
||||
- [[Sales Account Strategist]] ← related_to ← [[Sales Engineer]]：账户策略与技术发现共享客户环境理解
|
||||
- [[Sales Proposal Strategist]] ← related_to ← [[Sales Engineer]]：提案策略与技术定位信息共享
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Sales Discovery Coach Agent]] 在"技术深度"维度存在互补张力：
|
||||
- 冲突点：售前工程师在发现阶段应保持多深的技术参与度？
|
||||
- 当前观点（Sales Engineer）：售前工程师应主导技术发现，结构化地挖掘架构、集成、安全约束和真实技术决策标准
|
||||
- 对方观点（Sales Discovery Coach）：销售发现应聚焦于业务问题，深度技术探索由专门的角色或时机负责
|
||||
- 协调方向：在发现阶段早期以业务语言建立信任，进入评估阶段后切换为技术深度模式
|
||||
- 暂无发现与其他 Wiki 页面的内容冲突
|
||||
|
||||
Reference in New Issue
Block a user