摘要：组织结构开始围绕工作流重新设计
企业 AI 改造的下一步，是重新安排职责、执行与管理。一个负责人统筹业务目标和关键决策，原来分散在多个部门的标准化工作，由相互连接的 AI 工作流执行；项目验收从专门等人汇报、逐项核对的岗位，转为飞书 CLI 驱动的规则校验、证据记录与异常处理；线索和客户管理能力则按业务需要，由本地部署系统逐步承接。
这是一套目标组织模型，适用于能够定义输入、输出和验收条件的业务。它改变的是工作如何分配、交接和完成，具体岗位配置仍取决于业务量、专业要求和异常复杂度。最终目标很明确：同样的团队承担更多业务，一名负责人能够掌握过去需要跨部门会议才能拼齐的信息。
一、一个负责人，掌握整条业务链
传统的工作推进通常沿着岗位接力：销售收集需求，项目人员整理资料，执行团队完成任务，验收人员核对结果，管理者再从各自的汇报中理解进展。每多一次交接，就可能增加一次等待、补充说明或重复录入。
FDE 模型把职责围绕同一条业务记录重新连接。一个负责人可以统筹获客、销售、交付和运营的进展，工作流承接内容整理、线索录入、任务分配、执行检查和提醒。负责人直接看到目标、状态、结果与异常，按需要调动专业人员处理关键问题。
| 职责 | 原来的组织方式 | 改造后的承接方式 |
|---|---|---|
| 业务统筹 | 多部门分别汇报，负责人还原全局 | 一名负责人查看同一业务记录与异常队列 |
| 内容与获客 | 反复制作、发布、整理回复 | 内容复用、平台适配、线索识别工作流 |
| 销售跟进 | 业务员录入后再汇报进展 | 本地系统汇总活动、阶段、待办与超时事项 |
| 项目验收 | 专岗逐项追问、核对与催办 | 飞书 CLI 校验清单、归档证据、提醒与升级 |
| 专业判断 | 分散在个人经验和会议中 | 规则写进流程，复杂判断进入负责人或专家任务 |
一人统筹要求把经验变成可执行的步骤。资深人员设计字段、模板、判断条件和审核标准，实习生或初级员工沿着明确的流程完成标准任务。负责人保留对客户承诺、业务优先级和结果质量的判断。
二、项目验收专岗，转为飞书 CLI 执行的流程
在目标组织中，原来专门负责收集材料、核对清单、追问进度的验收岗位，可以退出这部分重复执行。验收职责继续存在，以规则和事件的形式运行。
这里的“飞书 CLI”指连接企业系统与飞书的定制命令行工作流：读取任务和交付证据，执行约定检查，将结果写入记录，并发送提醒或升级事项。具体能力由项目开发实现。飞书提供协作入口，企业定义验收规则和责任边界。
验收可以拆成三层。第一层是字段和文件检查，例如交付物是否齐全、规格是否一致、链接能否访问。第二层是业务规则检查，例如任务是否超期、前置审批是否完成、关键数据是否落在允许范围。第三层是结果判断，例如客户是否接受、表达是否符合品牌、异常是否允许放行，这一层由明确的责任人确认。
一次交付验收事件怎样发生
假设团队提交一批产品内容，任务记录已经约定产品编号、渠道、素材数量和审核人。提交动作触发飞书 CLI，流程读取交付清单，检查编号、文件、必要字段和审批状态，再把每项结果写回同一任务。
检查通过，任务进入负责人确认队列；缺少文件，流程将缺项发给执行人并保留重提记录；超过处理时限，提醒升级到备选责任人。最终确认记录包含操作者、时间、规则版本和证据链接，方便追溯。
这样，负责人每天首先看到的是需要决定的事项，执行人员看到的是明确的缺项与下一步。验收状态来自业务事件，不必等待下次例会才更新。
三、本地系统承接 CRM，管理围绕业务记录运转
客户管理可以从“先买一套产品，再要求员工按产品流程录入”，逐步转为“先定义业务怎样发生，再让系统自动形成记录”。本地部署让字段、规则、接口和数据交接能够围绕企业自身流程持续开发。
线索从已授权的邮箱、表单或其他接入渠道进入后，系统提取信息、映射字段、去重并分配负责人。销售活动继续关联到同一记录，管理者直接查看客户阶段、最近互动和下一次跟进。人工补录与校正入口保留，识别不确定的信息进入复核队列。
客诉也可以形成独立的处理事件。业务员下班、忙碌或漏跟进时，接入渠道中的客诉信号仍可按规则提醒负责人及市场团队，处理超时后继续升级。管理信息由流程持续产生，减少对个人主动汇报的依赖。
替代范围应逐项确认：线索录入、客户字段、分配、阶段识别、跟进提醒和管理看板，可优先由本地系统承接；复杂销售预测、特殊权限、历史数据迁移和供应商独有模块，需要单独评估。企业可以先替代高频环节，再决定哪些 CRM 模块继续保留。
ERP 与本地智能系统采用相同思路。订单、单据、库存异常和跨部门交接适合从具体流程切入；关键财务和库存账务仍需沿用经过确认的业务规则、审核与审计。飞书、钉钉和已有系统通过接口接入，信息能够回到企业自己的业务记录中。
四、6–12 个月后，成本与单位人效怎样改变
前 1–3 个月，成熟的代运营或外包团队可能更快形成可见交付。FDE 前期需要整理业务知识、搭建工作流、处理例外并培训团队。收益评估应覆盖后续持续运行，而不是只比较启动速度。
6–12 个月的价值主要来自复用：相同规则处理下一批线索，相同模板适配下一组内容，相同验收流程承接下一次交付。随着重复执行减少，同一名员工可以维护更多任务，负责人也能减少用于收集状态的时间。
订阅费用可以单独测算。以业务评估输入 ¥200／人／月计算，20 人团队每年席位费为 ¥48,000。若本地方案在同等使用范围内减少 50%–80% 的同类订阅支出，年节省约 ¥24,000–¥38,400。该参数不是第三方官方统一报价，也不是总成本降幅；开发、部署、模型调用、硬件和维护费用需要另外计入。
线索识别的 85%+ 同样属于方案参考，项目需先定义样本、正确判定方式和复核规则，再以真实数据验收。一次录入正确，并不自动代表后续分配、跟进和客户结果都正确。
五、把组织改造分阶段实施
第一阶段，选择一条高频业务链，记录任务量、人工耗时、等待时长、返工和现有费用。明确负责人、授权范围、最终确认人及需要升级的异常。
第二阶段，将这条链上的输入、字段、交付物和验收条件写清楚。连接已有工具，开发本地记录与飞书 CLI 验收流程，用真实任务试运行，修正缺失规则。
第三阶段，让工作流成为日常入口。执行人按清单提交，管理者按异常处理，业务状态随事件更新。确认记录完整、结果稳定后，再调整原来重复录入、催办和验收岗位承担的工作。
第四阶段，复制到相邻流程。把销售接到交付，把内容接到线索，把验收接到跟进。在 6–12 个月的持续运行中，按结果决定扩展范围，而不是一次性重做全部系统。
六、验收组织变化，要看这些指标
| 指标 | 需要回答的问题 |
|---|---|
| 单位人效 | 在质量标准相同的前提下，每人有效完成量是否提高？ |
| 任务工时 | 一条业务从进入到完成，需要多少人工操作时间？ |
| 管理耗时 | 负责人用于听取状态、追问和整理汇报的时间是否减少？ |
| 验收时效 | 提交后多久完成规则检查，异常多久获得处理？ |
| 交付质量 | 返工、漏项和重复错误是否下降？ |
| 客诉响应 | 从客诉出现到责任人、市场团队收到提醒，需要多久？ |
| 业务连续性 | 人员下班或更换后，记录、待办和责任链是否仍完整？ |
| 总成本 | 同等业务量下，订阅、人工、模型和维护合计是多少？ |
七、组织更精简，责任链必须更清楚
一名负责人能够统筹更多职责，前提是系统能够持续提供可信记录。每个流程都应有明确的业务所有者、异常处理人和最终确认人；每次关键写入、规则修改和结果放行都能追溯。
组织改造可以从今天开始：找出一个反复录入的环节、一场主要用于汇报进度的长会，以及一个总在等人催办的验收节点。把它们连接成可以执行、检查和追责的工作流，再用真实业务验证，一个人究竟能够统筹多大的业务范围。
八、技术依据与适用范围
飞书开放能力提供消息与事件连接，企业仍需开发自己的验收规则和执行程序。以下资料用于说明技术路径；本文组织架构是 FDE 提出的目标模型，不代表所有企业均已完成这种转型。
- 飞书机器人概述：应用机器人连接消息与处理入口，可用于通知和人工确认。
- 飞书通用事件触发器说明：事件变化能够触发下游业务逻辑、提醒与记录。
- Frappe CRM 官方部署文档：自托管是 CRM 的一种部署路径，实际能力与成本仍取决于实现范围。