1669 lines
41 KiB
Markdown
1669 lines
41 KiB
Markdown
# 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业务工程师转译场景，由工程团队兑现系统。**
|
||
|
||
这就是我们下一阶段要建立的新型销售团队。
|