# AI智能化客户经营团队启动会议章程

> 内部共识文件 / 启动会议使用
> 核心目的：建立一支新型销售团队，不是传统意义上的“卖课、卖软件、卖项目”，而是围绕企业智能化，建立客户经营、认知升级、场景发现、商务推进与项目落地之间的协同体系。

---

## 一、这次会议的目的

这次会议不是一次普通的销售动员会。

我们要达成的共识是：**接下来我们要建立的，不是传统销售团队，而是一支“AI智能化客户经营团队”。**

这个团队要解决几个问题：

1. 我不能再长期同时承担专家、商务、销售、方案、谈判、客户关系维护等所有角色。
2. 客户对AI智能化的理解差异很大，需要有人在前端帮助识别客户、筛选客户、引导客户。
3. 不是所有客户都适合直接上智能化系统，必须先判断客户是否具备基础。
4. 我需要继续把自己的现实IP定位为“学者型专家”，把更多商业推进工作交给可信任的人。
5. 我们过去靠我个人推动项目，现在要升级为靠团队、流程、工具和方法论共同推动项目。

所以，这次会议的核心任务是：

> **统一认知，重定义角色，明确分工，建立规则，启动培训。**

---

# 二、为什么要这样做

## 2.1 我们公司的发展逻辑

我最早是企业管理咨询公司的老板。

在做咨询的过程中，我发现很多管理咨询如果不能落到系统里，最后很容易停留在方案、制度、PPT和口号层面。于是，我又进入信息化领域，成为信息公司的老板。

ChatGPT出现以后，企业智能化成为新的方向。为了真正理解AI、使用AI、推广AI，我又做了两件事：

1. 自己系统学习AI。
2. 面向企业和个人做AI科普。

为了更好地在客户那里讲清楚AI，尤其是站在第三方专家角度讲清楚AI，我又取得了大学AI实验室主任、客座教授等身份。

这几个身份并不是割裂的，而是一条连续路径：

> **管理咨询 → 信息化落地 → AI智能化 → 企业智能化转型方法论**

我们真正要做的，不是卖一个AI工具，也不是卖一个系统，而是帮助企业从“想用AI”走向“能用AI、用好AI”。

---

## 2.2 为什么我要继续强化“学者型专家”身份

我个人的性格和能力，更偏向于学者、研究者、方法论构建者，而不是传统意义上的商人。

过去几年，我做了大量AI学习、写作、科普和培训：

* 在AI学习过程中，几年下来写了上百万字内容，大部分与认知科学相关。
* 其中有一个系列，大约10篇，专门讨论AI开发的方法论。
* 也写过商业、生产、管理、经营方面的内容。
* 在AI科普过程中，整理了近千页PPT。
* 正式讲座、培训接近百场。

这些积累决定了，我最适合站在客户面前讲：

* AI到底是什么。
* AI和企业经营管理有什么关系。
* 为什么AI不是简单采购工具。
* 企业该不该做智能化。
* 该从哪里开始做。
* 哪些场景适合做，哪些场景不适合做。
* 信息化、数字化、智能化之间是什么关系。
* 企业如何把知识、流程、经验和决策转译成AI可以参与的系统。

所以，我未来在客户面前的主要身份应该是：

> **企业智能化转型的学者型实践专家。**

而不是传统销售，不是商务谈判代表，也不是项目经理。

---

## 2.3 为什么需要新的客户经营团队

过去，很多商业部分都是我亲自出面。

这带来几个问题：

1. 我既要讲专业，又要谈价格，角色容易混杂。
2. 客户会把所有问题都集中到我身上。
3. 我一旦进入老师状态，容易讲得天马行空，偏离商务目标。
4. 商务谈判没有防火墙，价格、边界、承诺都容易集中到我一个人身上。
5. 项目越多，我越容易成为瓶颈。

因此，我们需要建立一支新的客户经营团队。

这支团队的核心价值，不是单纯“卖东西”，而是：

> **识别客户，经营关系，管理预期，发现机会，保护边界，推动合作。**

---

## 2.4 为什么销售人员不需要一开始就懂信息化和AI

现在准备加入销售体系的人，大多有以下优势：

1. 深谙人情。
2. 了解自己领域里客户的真实业务运行。
3. 与我之间互相信任。
4. 有多年甚至几十年的社会经验、客户经验和谈判经验。

他们的劣势也很明显：

1. 不懂信息化。
2. 不懂AI。
3. 不熟悉我们过去的系统建设逻辑。
4. 不知道AI智能化项目的边界和风险。

但这并不是无法合作的理由。

因为在AI智能化项目里，销售最重要的能力不是“假装自己是技术专家”，而是：

* 能不能看懂人。
* 能不能读懂客户组织。
* 能不能发现谁是真正决策者。
* 能不能判断客户是真想做，还是只是凑热闹。
* 能不能识别客户的焦虑、犹豫、阻力和真实需求。
* 能不能在会前做好准备，会后做好复盘。
* 能不能借助AI工具提高自己的判断力和表达力。

所以，我们对销售团队的第一阶段要求不是“懂AI”，而是：

> **会带着AI工作。**

---

## 2.5 为什么传统技术团队不能直接承担Agentic转型

过去三年，我一直希望现有技术团队向AI开发、Agentic工程方向转型。

但最近我得出一个重要判断：

> 传统软件工程师和Agentic工程师，不是技术栈的简单迭代，而是两个截然不同的物种。

传统软件工程师更擅长确定性工作：

* 接需求。
* 写代码。
* 调接口。
* 做数据库。
* 做权限。
* 做报表。
* 做部署。
* 做测试。
* 做系统维护。

但Agentic工程师面对的是另一类问题：

* 目标不清晰。
* 路径不确定。
* 业务上下文复杂。
* 客户表达含混。
* AI输出不稳定。
* 结果需要反复验证。
* 需要用自然语言组织任务。
* 需要重构业务流程，而不是简单实现功能点。

传统软件工程师更像“API水管工”，擅长在旧框架里处理确定性问题；而Agentic工程师更像“问题的业主”，要用自然语言处理不确定性，重构核心业务流。

所以，我们未来不是简单让传统技术团队全部转型成Agentic工程师，而是要重新分工：

> **让低技术包袱的人负责探索，让传统工程团队负责兜底。**

---

## 2.6 我们真正要建立的是“双轨体系”

未来的企业智能化项目，要分成两条轨道：

### 1. 探索轨

探索轨负责发现价值。

主要工作包括：

* 客户访谈。
* AI培训。
* 认知统一。
* 场景梳理。
* 业务流程理解。
* 智能体原型。
* Vibe Coding。
* 试点验证。
* AI工具配置。
* 轻量级部署。

参与人员包括：

* 我。
* 客户经营负责人。
* AI商务助理。
* AI业务工程师。
* 未来可能培养出来的外行、高中生、年轻学徒。

### 2. 工程轨

工程轨负责兑现价值。

主要工作包括：

* 正式系统建设。
* 数据库。
* 权限体系。
* 系统接口。
* 部署运维。
* 日志审计。
* 安全控制。
* 测试验收。
* 长期维护。

参与人员包括：

* 项目经理。
* 技术负责人。
* 传统工程师。
* 运维团队。

这两条轨道不能混乱。

过去的问题，是想让工程轨的人去干探索轨的活。
未来的风险，是让探索轨的人直接干工程轨的活。

我们要避免这两种错误。

---

# 三、我们要卖的到底是什么

我们不是简单卖培训，也不是简单卖顾问，更不是简单卖系统。

我们真正提供的是：

> **企业从“想用AI”到“能用AI、用好AI”的路径。**

这个路径分为三级服务。

---

## 3.1 第一级：培训

培训以前很多时候不收费，因为它被当成智能化系统的引子。

以后，培训要逐步开始收费。

培训的价值不是单纯讲课，而是：

1. 帮助客户建立AI基本认知。
2. 统一老板、高层、中层对AI的理解。
3. 判断客户是否真的有智能化意愿。
4. 发现客户内部潜在场景。
5. 筛选出适合进入顾问或系统阶段的客户。

培训不是终点，而是入口。

### 销售在培训阶段的角色

销售不能只是居间人。

销售在培训阶段要成为：

> **客户组织入口采集员。**

培训前，销售要了解：

* 谁发起培训？
* 为什么要做这场培训？
* 老板是否参加？
* 哪些高层参加？
* 客户最关心什么？
* 客户有没有预算意识？
* 客户是否有下一步合作可能？
* 客户现在的信息化基础如何？

培训中，销售要观察：

* 谁认真听？
* 谁提问？
* 谁质疑？
* 谁沉默？
* 谁总把话题拉回业务？
* 谁只关心工具？
* 谁关心风险？
* 谁可能是推动者？
* 谁可能是阻力者？

培训后，销售要推动：

* 会后总结。
* 客户反馈。
* 场景收集。
* 高层闭门交流。
* AI就绪度诊断。
* 顾问或试点项目。

---

## 3.2 第二级：顾问

不是所有客户都适合直接上系统。

很多客户存在以下问题：

* 信息化基础不足。
* 数据和资料积累不足。
* 组织对AI认知不统一。
* 老板很热，但中层不配合。
* 高层想象太大，业务场景不清。
* 员工担心被替代。
* 客户只是想“听听AI”，并没有真正准备投入。

这类客户，可以先做顾问。

顾问的价值是：

1. 帮助客户判断自己适不适合做AI。
2. 帮客户梳理业务场景。
3. 帮客户识别信息化和数据基础短板。
4. 帮客户设计智能化路径。
5. 帮客户形成阶段性行动方案。

### 顾问阶段的销售角色

顾问项目中，销售可以低调，但不能完全消失。

销售要承担类似“客户成功”或“商务秘书”的角色：

* 安排会议。
* 跟进纪要。
* 确认事项。
* 维护客户关系。
* 观察客户情绪。
* 发现续费机会。
* 识别系统建设机会。
* 防止顾问项目变成无边界陪聊。

---

## 3.3 第三级：系统

系统是最重的服务。

只有客户具备一定条件时，才适合进入系统阶段。

系统项目包括：

* 信息化建设。
* 智能化建设。
* 数据整理。
* 知识库建设。
* 智能体开发。
* 业务流程改造。
* 系统集成。
* 权限与运维。
* 培训与验收。

系统项目不能乱卖。

系统项目的前提是：

1. 客户有明确意愿。
2. 客户有一定信息化基础。
3. 客户有数据和资料积累。
4. 客户组织对AI有基本认知。
5. 有明确业务场景。
6. 有一号位或关键高层支持。
7. 有项目负责人。
8. 有验收和预算意识。

### 系统阶段的销售角色

系统项目中，销售前期重点出现，中后期主要做客情维护和风险预警。

销售要关注：

* 客户是否对进度不满。
* 客户是否对效果预期过高。
* 业务部门是否不配合。
* 信息部门是否有抵触。
* 老板关注点是否变化。
* 验收标准是否变化。
* 客户内部是否出现新的阻力。
* 项目经理是否只关注任务，而忽略客户情绪。

项目经理看任务，销售看人心。

这两件事都重要。

---

# 四、客户是否适合做智能化的判断标准

我们不能见客户就卖系统。

企业是否适合做智能化，至少要看四个方面。

---

## 4.1 基础建设

客户有没有信息化基础？

包括：

* 有没有业务系统。
* 有没有数据积累。
* 有没有文档资料。
* 有没有流程记录。
* 有没有知识沉淀。
* 有没有可被整理、转译和调用的信息。

如果企业没有任何数据和资料积累，智能化很容易做得很浅，只能做一些表层应用。

---

## 4.2 组织认知

客户对AI的认识是否成熟？

尤其要看：

* 创始人怎么看AI。
* 老板是真理解，还是只是焦虑。
* 高层是否理解AI。
* 中层是否愿意配合。
* 员工是否恐惧AI。
* 客户是否把AI当成万能工具。
* 客户是否以为买个软件就完成智能化。

组织对AI的认识，决定了AI能做什么、做到什么程度。

---

## 4.3 业务场景价值

客户有没有值得做的场景？

好的AI场景通常有几个特点：

* 高频。
* 重复。
* 高成本。
* 高风险。
* 高知识密度。
* 高沟通成本。
* 高依赖老员工经验。
* 存在大量文本、表格、资料、流程、判断和决策。

如果客户没有明确业务场景，或者场景价值太低，不适合直接做系统。

---

## 4.4 项目权力结构

客户内部有没有真正推动项目的人？

要判断：

* 谁是决策者？
* 谁是付款方？
* 谁是使用方？
* 谁是验收方？
* 谁是推动者？
* 谁是阻力者？
* 谁会表面支持、实际不动？
* 是否有一号位支持？
* 是否有跨部门协调能力？

AI项目不是单部门小工具，经常涉及组织协同。没有权力结构支持，项目很容易卡住。

---

## 4.5 客户分层建议

内部可以先按以下方式判断客户：

| 客户状态               | 合作建议            |
| ------------------ | --------------- |
| 只是好奇AI，没有预算，没有明确场景 | 适合培训            |
| 有兴趣，但认知混乱，基础不足     | 适合培训 + 顾问       |
| 有明确问题，但信息化和数据基础一般  | 适合顾问 + 诊断 + 小试点 |
| 有明确场景，有数据，有负责人     | 适合试点项目          |
| 有一号位支持，有预算，有基础设施   | 适合系统建设          |
| 认知不成熟、乱提需求、急于要结果   | 谨慎合作            |
| 只想免费听课、套方案、比价格     | 降低投入，不进入深度合作    |

一句话：

> **培训可以宽，顾问要筛，系统必须严。**

---

# 五、团队构成、角色及职责

我们未来不是简单的“老板 + 销售 + 技术”结构，而是要形成新的协作体系。

核心结构是：

> **学者型首席专家 + 客户经营负责人 + AI业务工程师 + 确定性工程底座**

---

## 5.1 首席专家 / 学者型专家 / 方案督导

这个角色主要由我承担。

### 我的主要职责

1. 负责企业智能化方法论。
2. 负责客户前期认知引导。
3. 负责关键场景判断。
4. 负责方案方向把控。
5. 负责重大客户的专家沟通。
6. 负责诊断报告和核心方案的质量把关。
7. 负责项目关键节点评审。
8. 在项目合作期，可以作为外聘专家或项目专家督导出现。

### 我不再主要承担的职责

1. 不再直接承担所有商务推进。
2. 不再亲自跟进所有合同细节。
3. 不再处理所有客户关系维护。
4. 不再在每个项目中深度参与日常建设。
5. 不再把所有客户问题都集中到自己身上。

### 我在客户面前的身份

前期：

> 企业智能化转型专家 / AI实验室主任 / 学者型专家

合作期：

> 首席智能化专家 / 项目专家督导 / 方案质量负责人 / 外聘专家顾问

注意：

不建议过度使用“监理人”这个词。
“监理”容易让客户理解为完全独立第三方，而我们实际与项目高度相关。更合适的表达是“专家督导”或“方案质量负责人”。

---

## 5.2 客户经营负责人

这就是我们过去说的“销售总监”，但内部不建议只理解为销售。

客户经营负责人不是传统销售。

他的核心定位是：

> **客户关系负责人 + 商业侦察兵 + 预期管理者 + 我的现场校准器。**

### 主要职责

1. 负责客户引荐和关系维护。
2. 负责客户初筛。
3. 负责会前准备。
4. 负责判断客户真实意图。
5. 负责观察客户组织结构和关键人物。
6. 负责商务推进。
7. 负责合同、报价、回款等商务事项协调。
8. 负责客户情绪管理。
9. 负责项目中后期的客情维护。
10. 负责发现项目风险。
11. 负责会后复盘，并向我提出提醒和建议。

### 不是他的职责

1. 不负责独立判断技术可行性。
2. 不负责随意承诺AI效果。
3. 不负责越权报价。
4. 不负责替我做专业判断。
5. 不负责给客户画无法兑现的大饼。
6. 不负责用大学、实验室、专家名头做不恰当背书。

### 最重要的能力

客户经营负责人最重要的能力不是讲AI，而是：

* 识人。
* 识局。
* 识势。
* 识别真实需求。
* 识别关键人物。
* 识别客户情绪。
* 识别合作风险。
* 识别下一步机会。

---

## 5.3 渠道伙伴

有些人暂时不适合直接作为客户经营负责人，但可以作为渠道伙伴。

### 渠道伙伴职责

1. 引荐客户。
2. 提供客户背景。
3. 协助建立初次信任。
4. 协助组织饭局、会议、培训等场景。
5. 帮助判断客户基本情况。

### 渠道伙伴不能做的事

1. 不能代表公司承诺方案。
2. 不能代表公司承诺价格。
3. 不能代表公司承诺效果。
4. 不能独立与客户签订合作。
5. 不能夸大我或公司的能力。

---

## 5.4 AI商务助理

销售团队培训后，可以先形成AI商务助理角色。

这是从渠道伙伴走向客户经营负责人的过渡角色。

### 主要职责

1. 使用AI做客户背景分析。
2. 使用AI准备会前计划。
3. 使用AI设计谈判目标和话术。
4. 使用AI整理会议纪要。
5. 使用AI做会后复盘。
6. 使用AI分析客户组织和关键人物。
7. 协助客户经营负责人推进下一步。

### 核心要求

AI商务助理不一定懂技术，但必须养成一个习惯：

> **事前问AI，事后用AI复盘。**

---

## 5.5 AI业务工程师 / Agentic业务工程师

这是未来非常关键的新岗位。

这个角色不是传统程序员，也不是普通销售。

他的核心任务是：

> **把客户的业务问题转译成AI可以参与执行的任务系统。**

### 主要职责

1. 梳理客户业务流程。
2. 整理客户知识资料。
3. 设计智能体任务链。
4. 配置轻量智能体。
5. 做Vibe Coding原型。
6. 做客户侧工具培训。
7. 协助完成AI场景试点。
8. 帮助客户从“会用AI”走向“把AI嵌入流程”。

### 适合来源

1. 没有严重技术包袱的年轻人。
2. 外行转型人员。
3. 善于表达、理解业务、愿意深度使用AI的人。
4. 高中生、大学低年级中学习能力强、动手能力强的人。
5. 部分销售人员，如果能真正掌握Agentic / Vibe Coding，也可以向这个方向发展。

### 边界

AI业务工程师可以做：

* 知识库整理。
* 智能体配置。
* 前端轻量部署。
* 流程表单配置。
* 提示词优化。
* 原型搭建。
* 客户使用培训。

但不能随意碰：

* 正式数据库。
* 生产环境。
* 核心接口。
* 权限体系。
* 客户敏感数据迁移。
* 安全策略。
* 自动化高风险操作。

---

## 5.6 项目经理 / PMP

项目经理负责项目建设期的具体推进。

### 主要职责

1. 制定项目计划。
2. 协调人员和资源。
3. 跟进任务进度。
4. 管理项目风险。
5. 组织客户会议。
6. 管理交付物。
7. 推动项目验收。
8. 协调技术团队和客户方。

### 项目经理与我的关系

项目建设期以项目经理为主，我不会深度参与所有具体事项。

我主要出现在：

1. 方案关键评审。
2. 重大风险判断。
3. 重要客户会议。
4. 项目验收会。
5. 需要专家身份背书的节点。

---

## 5.7 技术团队 / 工程底座团队

技术团队不是被淘汰的团队。

他们是确定性工程底座。

### 主要职责

1. 信息化系统建设。
2. 数据库设计。
3. 系统接口。
4. 权限控制。
5. 部署运维。
6. 系统安全。
7. 性能稳定。
8. 测试验收。
9. 维护升级。

### 不强求他们承担的职责

1. 不强求他们成为Agentic工程师。
2. 不强求他们直接面对客户做业务场景创新。
3. 不强求他们用自然语言重构客户业务流。
4. 不强求他们从传统工程师直接变成AI业务专家。

技术团队的价值在于：

> **把探索出来的价值，变成稳定、可用、可验收、可维护的系统。**

---

## 5.8 维护团队

维护团队负责项目验收后的长期服务。

### 主要职责

1. 系统日常维护。
2. 客户问题响应。
3. 小范围功能调整。
4. 使用问题解答。
5. 运行状态跟踪。
6. 将客户新需求反馈给客户经营负责人、项目经理和专家团队。

---

# 六、项目协作流程

## 6.1 合同前期

合同前期过去以我为主，包括方案把控和商务谈判。

未来调整为：

### 客户经营负责人负责

1. 客户引荐。
2. 客户初筛。
3. 客户背景收集。
4. 会前准备。
5. 商务机会判断。
6. 客户关系维护。
7. 商务条件沟通。

### 我负责

1. 专家身份出场。
2. AI认知引导。
3. 业务场景判断。
4. 智能化路径建议。
5. 方案方向把控。
6. 是否适合深入合作的判断。

### 内部评审负责

1. 判断能不能做。
2. 判断怎么做。
3. 判断风险在哪里。
4. 判断是否报价。
5. 判断报价范围。
6. 判断是否进入培训、顾问、试点或系统。

---

## 6.2 项目建设期

项目确定落地后，建设期以项目经理为主。

### 项目经理负责

1. 项目计划。
2. 任务分解。
3. 进度推进。
4. 客户会议。
5. 交付管理。
6. 验收准备。

### 技术团队负责

1. 系统建设。
2. 数据处理。
3. 接口开发。
4. 部署实施。
5. 测试修改。

### AI业务工程师负责

1. 业务流程转译。
2. 智能体配置。
3. 知识库整理。
4. 原型验证。
5. 客户使用培训。

### 客户经营负责人负责

1. 客情维护。
2. 客户情绪观察。
3. 风险预警。
4. 商务事项协调。
5. 续费和二次合作机会发现。

### 我负责

1. 关键节点专家评审。
2. 重大问题判断。
3. 必要时作为外聘专家或专家督导出现。
4. 出席重要会议和验收会。

---

## 6.3 项目验收阶段

项目验收阶段，我一般出席验收会。

### 项目经理负责

1. 验收材料。
2. 验收流程。
3. 问题清单。
4. 客户确认。
5. 项目总结。

### 客户经营负责人负责

1. 客户满意度判断。
2. 客户后续需求识别。
3. 维护期合作沟通。
4. 复购机会判断。

### 我负责

1. 验收会专家出席。
2. 项目价值总结。
3. 与客户高层沟通后续方向。

---

## 6.4 维护阶段

维护阶段转由维护团队负责。

客户经营负责人继续保持客户关系。

项目经理和技术团队根据问题需要介入。

我只在重大客户、重大问题或重大升级机会时出现。

---

# 七、商务防火墙与责任边界

我们设置商务防火墙，不是为了互相推责，而是为了分层决策、保护团队、保护客户，也保护我个人的专家身份。

## 7.1 基本原则

1. 专业问题由专家判断。
2. 商务问题由商务负责人处理。
3. 技术可行性由内部评审确认。
4. 项目承诺以书面方案和合同为准。
5. 销售不能越权承诺。
6. 我也不直接承担所有商务细节。

---

## 7.2 对客户的标准表达

可以统一使用这样的表达：

> “技术可行性和智能化路径，由专家团队判断；商务条款由我们的商务负责人统一对接。今天沟通可以确认方向，正式承诺以后续书面方案和合同为准。”

这句话要成为团队共识。

它不是推脱，而是专业分工。

---

# 八、销售承诺规则

AI项目最怕过度承诺。

销售人员必须牢记：

> **可以确认方向，不能随意承诺结果。**

---

## 8.1 两类基本情况

### 1. 已经内部确定能做的

如果是我们内部已经达成共识、做过类似项目、能力边界清晰的，可以当场做方向性承诺。

但表达上必须保留边界：

> “这个方向我们有成熟经验，可以做。但具体范围、周期和费用，需要根据贵司实际情况形成正式方案。”

### 2. 不确定能否做的

如果现场不能判断，必须记录下来，事后反馈。

标准表达：

> “这个问题我们先记录下来，需要回去结合数据、流程和系统情况做一次评估，不能现场直接承诺。”

---

## 8.2 四级承诺矩阵

| 等级 | 类型                | 是否可以当场承诺      | 标准表达                        |
| -- | ----------------- | ------------- | --------------------------- |
| A类 | 已有成熟模块，做过类似项目     | 可以方向性承诺       | “这个方向我们有成熟经验，但具体范围以正式方案为准。” |
| B类 | 原理上可做，但要看数据、流程、权限 | 不能承诺结果，只能承诺评估 | “这个需要看贵司实际情况，我们先列为评估项。”     |
| C类 | 探索性场景，需要PoC验证     | 只能承诺可以设计试点    | “这个不能直接承诺生产效果，但可以小范围验证。”    |
| D类 | 高风险、低价值、违规或超出能力边界 | 不能承诺，应建议放弃或调整 | “这个方向不建议直接做，风险可能大于收益。”      |

---

## 8.3 销售绝对不能说的话

以下表达禁止使用：

1. “这个肯定能做。”
2. “AI可以替代你们很多人。”
3. “老师出面就没问题。”
4. “我们大学实验室支持这个项目。”
5. “先签了，后面都能调。”
6. “这个系统上了马上见效。”
7. “不用看数据，也能做。”
8. “你们只要买了系统，就完成智能化。”
9. “这个很简单。”
10. “价格我现在就能定。”

这些话会给项目埋雷。

---

# 九、“魏征机制”：销售要成为我的现场校准器

我和客户交流时，容易进入老师状态，讲得太多、太深、太散，有时会天马行空。

AI也会给我反馈，但AI说得对，我未必听得进去。

你们作为多年合作伙伴、朋友，更了解我，也更容易用我能接受的方式提醒我。

所以，我们要建立“魏征机制”。

---

## 9.1 会前提醒

每次重要客户会议前，客户经营负责人要和我一起明确：

1. 这次会议的目标是什么？
2. 哪些话题可以深入讲？
3. 哪些话题点到为止？
4. 哪些问题不能现场承诺？
5. 客户最关心什么？
6. 我今天应该重点讲什么？
7. 我今天应该少讲什么？

---

## 9.2 会中提醒

必要时，销售可以使用约定话术提醒我收回来。

例如：

> “这个问题我们回去做一次结构化评估。”
> “这个地方可以会后形成一个书面方案。”
> “老师，这部分我们后面结合客户资料再展开。”
> “这个问题我先记录，后面由团队统一反馈。”

这些话不是打断我，而是保护会议节奏。

---

## 9.3 会后复盘

每次重要客户会议后，都要做会后复盘。

复盘要回答：

1. 我今天有没有讲太多？
2. 我有没有说出可能被客户理解成承诺的话？
3. 客户真正关心的是什么？
4. 谁是推动者？
5. 谁是阻力者？
6. 谁是决策者？
7. 谁只是旁观者？
8. 下一步应该推培训、顾问、诊断、试点，还是系统？
9. 这次会议的风险是什么？
10. 下次会议应该怎么调整？

复盘时，客户经营负责人先说，我后说。

避免我先定调以后，大家不敢提意见。

---

# 十、AI工具使用要求

未来销售团队必须养成AI工作习惯。

我们不是要求大家一开始懂AI原理，而是要求大家：

> **工作前问AI，工作后用AI复盘。**

---

## 10.1 会前使用AI

与客户交流或谈判前，要使用我提供的智能体完成：

1. 客户背景分析。
2. 客户行业分析。
3. 客户组织结构初步判断。
4. 沟通目标设计。
5. 谈判目标设计。
6. 风险预判。
7. 关键问题清单。
8. 可能异议与应对话术。
9. 我在会议中应该注意的事项。
10. 销售自己在会议中应该观察的事项。

---

## 10.2 会后使用AI

交流结束后，要使用智能体完成：

1. 会议纪要。
2. 客户真实需求分析。
3. 客户关键人物分析。
4. 客户组织画像。
5. 客户情绪判断。
6. 客户阻力判断。
7. 商机阶段判断。
8. 下一步行动建议。
9. 对我现场表现的反馈。
10. 对销售自己表现的反馈。

---

## 10.3 AI分析的原则

AI分析只能作为假设，不能直接当事实。

所有客户画像和组织判断，都要区分三类内容：

| 类型   | 说明                    |
| ---- | --------------------- |
| 观察事实 | 会议中实际发生了什么，谁说了什么，谁没说话 |
| 可能解释 | 我们基于事实做出的推测           |
| 需要验证 | 下一次沟通中要通过什么问题验证       |

不能把AI画像当成“算命”。

---

# 十一、销售团队一个月培训结构

培训目标不是把大家培养成技术专家。

培训目标是：

> **让大家成为AI增强型客户经营人员。**

一个月后，大家至少要做到：

1. 会用AI做会前准备。
2. 会用AI做会后复盘。
3. 会使用我提供的智能体。
4. 会判断客户是否适合继续推进。
5. 会问客户基本问题。
6. 会识别客户组织中的关键人物。
7. 会区分培训、顾问、系统三类合作。
8. 会遵守承诺边界。
9. 会在会议中做我的“魏征”。
10. 会把客户信息转化为下一步行动。

---

## 11.1 第一周：和AI交朋友

### 目标

让每个人真正开始使用AI，而不是只听AI概念。

### 训练内容

1. 每天用AI制定工作计划。
2. 每天用AI复盘一个沟通场景。
3. 每天用AI整理一个客户、行业或人物判断。
4. 熟悉我提供的智能体。
5. 形成自己的AI工作习惯。

### 第一周交付物

每个人提交：

> 《我的AI工作流说明书》

内容包括：

1. 我准备用AI解决哪些工作问题。
2. 我每天什么时候用AI。
3. 我会前如何用AI。
4. 我会后如何用AI。
5. 我最需要AI帮助我的地方是什么。

---

## 11.2 第二周：客户沟通与业务理解

### 目标

让销售学会用AI辅助客户分析，学会问对问题。

### 训练内容

1. 客户背景分析。
2. 行业基本分析。
3. 客户需求判断。
4. 客户组织结构判断。
5. 初次拜访计划。
6. 沟通目标设计。
7. 关键问题清单设计。
8. 客户异议应对。

### 必须会问的问题

销售不需要一开始懂AI技术，但必须学会问客户：

1. 贵司现在有哪些业务系统？
2. 哪些数据已经在系统里？
3. 哪些资料还在Word、Excel、微信、钉钉、飞书里？
4. 哪些流程高度依赖老员工经验？
5. 哪些岗位每天在重复处理大量信息？
6. 哪些工作最耗时间？
7. 哪些工作最容易出错？
8. 哪些工作最依赖人判断？
9. 老板最想解决的是效率、成本、风险、增长，还是管理透明度？
10. 这个项目谁使用？
11. 谁买单？
12. 谁验收？
13. 谁可能支持？
14. 谁可能反对？
15. 客户有没有预算意识？
16. 客户是想先听课，还是已经准备做项目？

---

## 11.3 第三周：产品边界与承诺规则

### 目标

让销售知道什么能说，什么不能说；什么能承诺，什么不能承诺。

### 训练内容

1. 培训产品边界。
2. 顾问产品边界。
3. 系统产品边界。
4. 客户筛选标准。
5. 四级承诺矩阵。
6. 禁止话术。
7. 报价边界。
8. 合同边界。
9. 免费培训边界。
10. 客户要求现场承诺时的应对方式。

### 第三周必须通过

每个人要通过一次“红线考试”。

如果不能遵守承诺边界，就不能代表团队独立面对客户。

---

## 11.4 第四周：模拟拜访、陪访与认证

### 目标

把前三周学到的东西用于真实或模拟场景。

### 训练内容

1. 模拟客户拜访。
2. 真实客户资料分析。
3. 会前计划。
4. 会中观察。
5. 会后复盘。
6. 对我的“魏征式”反馈。
7. 下一步合作建议。
8. 承诺边界测试。

### 第四周交付物

每个人至少完成：

1. 一份客户背景分析。
2. 一份会前计划。
3. 一份会议纪要。
4. 一份会后复盘。
5. 一份客户关键人物判断。
6. 一份下一步推进建议。

---

# 十二、销售人员分级与成长路径

不是所有人一开始都叫销售总监。

我们采用分级机制。

| 级别 | 角色       | 权限                      |
| -- | -------- | ----------------------- |
| L0 | 渠道伙伴     | 只能引荐客户，不能独立承诺           |
| L1 | AI商务助理   | 可以参与会前准备、会后复盘           |
| L2 | 客户经营负责人  | 可以独立做客户初筛和客户跟进          |
| L3 | 商务负责人    | 可以在授权范围内谈报价、合同、回款       |
| L4 | AI前端部署顾问 | 可以做工具配置、知识库整理、轻量原型和客户培训 |

头衔不是先给的，而是通过训练和行为拿到的。

---

# 十三、我们对销售团队的基本要求

## 13.1 不装懂

不懂信息化，可以学。
不懂AI，也可以学。
但不能装懂。

遇到不懂的问题，标准表达是：

> “这个问题我先记录下来，回去请专家和技术团队评估后给您正式反馈。”

---

## 13.2 不乱承诺

所有正式承诺必须来自：

1. 内部共识。
2. 正式方案。
3. 合同文件。
4. 项目评审结论。

---

## 13.3 不卖错客户

不是所有客户都值得深度投入。

有些客户只适合培训。
有些客户适合顾问。
有些客户可以试点。
少数客户适合做系统。

销售的价值，不只是找到客户，也包括筛掉不合适的客户。

---

## 13.4 不消耗专家信用

我的学者身份、大学身份、AI实验室身份，是长期信用资产。

不能为了短期成交过度使用这些身份。

尤其不能对客户暗示：

* 大学会为商业项目背书。
* 实验室会直接参与商业交付。
* 客座教授身份等于项目官方认证。
* 有专家名头就一定能保证效果。

我们可以使用专家身份建立信任，但不能滥用身份。

---

## 13.5 必须复盘

没有复盘，就没有进步。

每次重要客户沟通后，都要形成复盘。

复盘不是写流水账，而是回答：

1. 客户真实需求是什么？
2. 客户真正担心什么？
3. 谁是关键人？
4. 下一步怎么推进？
5. 我们今天哪里做得好？
6. 哪里可能埋雷？
7. 哪些事情要书面确认？

---

# 十四、未来我们要形成的标准流程

## 14.1 客户进入流程

```text
客户线索
  ↓
客户经营负责人初筛
  ↓
AI辅助背景分析
  ↓
内部判断客户类型
  ↓
安排培训 / 专家沟通 / 顾问诊断
  ↓
形成客户初步画像
  ↓
判断是否进入试点或系统
```

---

## 14.2 培训转化流程

```text
培训需求
  ↓
培训前客户信息采集
  ↓
培训实施
  ↓
培训中观察关键人物
  ↓
培训后反馈收集
  ↓
场景清单整理
  ↓
推动高层闭门交流或AI就绪度诊断
```

---

## 14.3 顾问转化流程

```text
顾问合作
  ↓
企业AI就绪度判断
  ↓
业务场景梳理
  ↓
信息化和数据基础评估
  ↓
智能化路径建议
  ↓
试点项目建议
  ↓
判断是否进入系统建设
```

---

## 14.4 系统项目流程

```text
系统意向
  ↓
客户基础评估
  ↓
业务场景确认
  ↓
内部技术和方案评审
  ↓
报价与合同
  ↓
项目启动
  ↓
项目经理主导建设
  ↓
专家关键节点评审
  ↓
客户经营负责人维护客情
  ↓
验收
  ↓
维护与二次合作
```

---

# 十五、近期待办清单

以下内容后续需要逐步整理成正式文件、模板或流程。

---

## 15.1 团队类

* [ ] 销售团队成员名单确认。
* [ ] 每个人的初始角色定位确认。
* [ ] L0-L4分级标准细化。
* [ ] 培训考核标准制定。
* [ ] 销售团队日常沟通机制确定。
* [ ] 客户经营负责人权限边界确认。
* [ ] 渠道伙伴合作规则制定。
* [ ] 佣金与分成机制制定。

---

## 15.2 产品类

* [ ] 培训产品介绍整理。
* [ ] 顾问产品介绍整理。
* [ ] 系统产品介绍整理。
* [ ] AI就绪度诊断产品设计。
* [ ] 90天试点项目产品设计。
* [ ] 年度AI顾问服务设计。
* [ ] 报价区间和报价规则整理。
* [ ] 不同客户类型对应产品路径整理。

---

## 15.3 销售工具类

* [ ] 客户背景分析模板。
* [ ] 会前计划模板。
* [ ] 会议纪要模板。
* [ ] 会后复盘模板。
* [ ] 客户组织画像模板。
* [ ] 关键人物判断模板。
* [ ] 客户分层判断表。
* [ ] 销售话术库。
* [ ] 异议应对话术库。
* [ ] 禁止承诺清单。
* [ ] 四级承诺矩阵正式版。

---

## 15.4 流程类

* [ ] 客户线索进入流程。
* [ ] 客户初筛流程。
* [ ] 培训转顾问流程。
* [ ] 顾问转试点流程。
* [ ] 试点转系统流程。
* [ ] 系统项目立项流程。
* [ ] 内部项目评审流程。
* [ ] 报价审批流程。
* [ ] 合同审批流程。
* [ ] 项目交接流程。
* [ ] 验收流程。
* [ ] 维护移交流程。

---

## 15.5 AI工具类

* [ ] 销售可用智能体清单。
* [ ] 每个智能体的使用说明。
* [ ] 会前智能体使用流程。
* [ ] 会后智能体使用流程。
* [ ] 组织画像智能体使用规范。
* [ ] 人员画像智能体使用规范。
* [ ] 智能体输出审核规则。
* [ ] AI生成内容的人工确认机制。

---

## 15.6 培训类

* [ ] 一个月培训课程表。
* [ ] 第一周AI习惯训练材料。
* [ ] 第二周客户沟通训练材料。
* [ ] 第三周产品边界与承诺训练材料。
* [ ] 第四周模拟拜访与认证材料。
* [ ] 红线考试题库。
* [ ] 模拟客户案例库。
* [ ] 真实客户复盘案例库。
* [ ] 培训结业标准。

---

## 15.7 项目协作类

* [ ] 专家、销售、项目经理、技术团队分工表。
* [ ] 项目前期交接清单。
* [ ] 销售转项目经理交接模板。
* [ ] 项目经理转维护团队交接模板。
* [ ] 项目风险预警机制。
* [ ] 客情维护记录模板。
* [ ] 项目复盘模板。
* [ ] 客户满意度反馈机制。

---

# 十六、启动会议要达成的几个共识

本次会议结束后，所有人至少要达成以下共识。

---

## 共识一：我们不是传统销售团队

我们不是靠话术卖课、卖软件、卖系统。

我们要成为客户智能化过程中的：

> **入口、雷达、翻译器、推进器和防火墙。**

---

## 共识二：销售不是技术专家，但必须成为AI增强型商务人员

销售不需要一开始懂AI原理。

但必须做到：

1. 会用AI做准备。
2. 会用AI做复盘。
3. 会用AI分析客户。
4. 会用AI提高表达。
5. 会使用公司提供的智能体。
6. 会识别自己不懂的边界。

---

## 共识三：我的角色要从“全能型老板”转为“学者型首席专家”

我以后更多承担：

* 认知引导。
* 方法论输出。
* 场景判断。
* 方案把关。
* 专家督导。

不再承担所有商务细节和客户跟进。

---

## 共识四：客户经营负责人不是普通销售

客户经营负责人要做的是：

* 读人。
* 识局。
* 建信任。
* 管预期。
* 防风险。
* 推合作。
* 做复盘。
* 做我的魏征。

---

## 共识五：系统项目不能乱卖

培训可以宽，顾问要筛，系统必须严。

我们宁可少做项目，也不能做错项目。

错项目会消耗团队、消耗客户、消耗信用。

---

## 共识六：所有承诺必须有边界

客户现场可以谈方向，不能乱承诺结果。

正式承诺必须来自书面方案和合同。

---

## 共识七：未来核心岗位是AI业务工程师

AI业务工程师不是传统程序员。

他要做的是：

> **把客户业务问题转译成AI可以执行、可以协同、可以迭代的任务系统。**

这是我们未来非常重要的能力建设方向。

---

## 共识八：我们采用探索轨和工程轨双轨协作

探索轨负责发现价值。
工程轨负责兑现价值。

两条轨道互相配合，不能互相替代。

---

# 十七、结束语

我们这次建立销售团队，不是为了多几个人出去卖东西。

我们要建立的是一套新的客户经营体系。

过去，很多事情靠我个人的经验、判断和表达来推动。
未来，我们要靠团队分工、AI工具、流程机制和方法论共同推动。

销售团队不是站在专业之外的人。
销售团队是客户智能化旅程的第一线。

你们要帮助我看见客户，理解客户，筛选客户，提醒客户，也提醒我。

我们共同要做的，不是把AI说得多神，而是帮助客户判断：

> **该不该做AI？
> 先做什么AI？
> 怎么做AI？
> 谁来推动AI？
> 做到什么程度才算真正有价值？**

这支团队真正的价值，不是成交一单，而是建立一种新的合作方式：

> **由专家定义问题，由客户经营负责人推进合作，由AI业务工程师转译场景，由工程团队兑现系统。**

这就是我们下一阶段要建立的新型销售团队。