Company 公司层：让一群人做好一件事
一句话： 当一个目标大到单个岗位扛不动，就需要把多个 Post 组织成一个 Company，靠协作流程、任务分配、长程运行把复杂目标做成。
一、是什么
Company（公司/部门）是多个 Post 协作的组织，用来完成单岗位无法独立完成的复杂目标。
Company = 多个 Post + 协作流程 + 任务分配 + 长程运行与自我反馈
类比：一个「电商运营部门」= 客服专员 + 投诉升级专员 + 数据分析师，各司其职，协作完成整个店铺的日常运营。
什么时候升到 Company 层？ 当你发现一个岗位的职责越塞越多、闭环率上不去、越界率降不下来时，说明该拆成多个岗位协作了。不要为了「显得高级」而强行组公司——单岗位能干好的事，就别拆。
二、为什么用
OPC 三层是递进的：Skill → Post → Company，每一步解决上一层的瓶颈。
| 问题 | 在 Post 层的表现 | 需要 Company 层才能解决 |
|---|---|---|
| 岗位扛不住全量 | 闭环率卡在 60%，再优化也上不去 | 拆分职责，引入专业岗位 |
| 边界模糊导致乱答 | 一个岗位又要安抚又要处理投诉又要分析数据 | 按职责拆成多个岗位 |
| 长周期任务无法追踪 | 只能响应单次请求，无法跟踪长期目标 | 设计任务编排和异常监测 |
| 复杂目标需多人协作 | 单一岗位不可能同时做客服和供应链调度 | 定义岗位间协作流程 |
三、怎么用
第 1 步：定岗位组成
先明确这个部门/公司由哪些岗位组成，每个岗位的职责边界（见 03 · Post 层）：
电商运营部门的岗位组成：
- 客服专员（对客沟通、常规问题处理）
- 投诉升级专员（处理疑难/情绪激烈客户）
- 数据分析师（汇总服务数据、发现共性问题、生成改进建议）
拆分原则： 当一个岗位闭环率卡在某个值上不去，且瓶颈来自「这件事不是它该管的」，就把这部分拆成独立岗位。
第 2 步：定协作流程
画清楚任务在岗位之间怎么流转、在什么条件下交接：
客服专员接待
→ 常规问题自行处理
→ 遇到无法解决 / 情绪激烈 / 差评 → 交接给 投诉升级专员
→ 每日服务记录 → 汇总给 数据分析师
→ 数据分析师发现共性问题 → 反馈给客服专员优化话术
交接时带什么信息？ 这是多岗位协作最常翻车的地方——信息传一半，下游岗位得重新问一遍。
交接模板：
- 客户问题摘要
- 已有的处理记录（之前做了什么）
- 当前状态
- 需要下游岗位做什么
第 3 步：定任务分配
一个大目标进来，谁来拆、拆成什么、分给谁：
目标：把本月客户投诉率降到 3% 以下
→ 分解：
1. 数据分析师从历史投诉中找出 TOP3 投诉原因
2. 客服专员根据分析报告优化对应场景的话术
3. 投诉升级专员针对高频投诉类型设计标准处理 SOP
→ 跟踪：每周检查一次各项指标变化
第 4 步：定长程运行与自我反馈
Company 层最大的挑战不是「跑一次」，而是持续稳定地跑。
a. 长程任务编排
把长周期目标拆成有序的阶段，每个阶段有明确的完成标志：
长程目标：月度客户满意度 NPS 从 42 提至 55
阶段 1（第 1 周）：数据分析师输出 TOP 3 不满原因
阶段 2（第 2 周）：客服专员 + 升级专员针对原因 1 优化话术和处理流程
阶段 3（第 3 周）：灰度上线新话术，观察 NPS 变化
阶段 4（第 4 周）：全量上线 + 总结报告
b. 异常监测
持续检查运行状态，能自己发现不对劲：
| 监测项 | 异常信号 |
|---|---|
| 某个岗位输出质量下降 | 准确率/可用率连续 2 天低于阈值 |
| 岗位间交接断链 | 交接信息缺失导致下游重新问 |
| 目标偏离 | 阶段性指标不升反降 |
c. 自我修正
发现异常后，能回退、重试或调整策略：
监测到「客服专员退换货话术可用率从 80% 降到 60%」
→ 自动原因排查：是否新上了活动导致退换货激增？是否有新的退换货类型没覆盖？
→ 临时策略：可用率 < 70% 的退换货请求转人工处理
→ 永久修复：管理员补充新场景的训练样本，迭代 Skill
→ 复测：恢复后自动切换回数字员工处理
四、案例
案例 1：电商运营部门——客服 + 升级 + 数据的三人团队
背景： 一家年销过亿的服装品牌，将原有 8 人人工客服团队改造为 3 个数字员工岗位协作的运营部门。
岗位组成与初始评估：
| 岗位 | 技能 | 闭环率 | 备注 |
|---|---|---|---|
| 客服专员 | 查物流 / 退换货 / 活动规则 / 安抚 | 81% | 日常对客 |
| 投诉升级专员 | 识别差评 / 安抚升级 / 生成补偿方案 / 决定是否人工介入 | 无法用闭环率衡量（大部分需要人工） | 兜底 |
| 数据分析师 | 提炼高频问题 / 分析话术效果 / 生成优化建议 | 无需闭环（面向内部） | 驱动改进 |
协作流程设计与调试：
初始阶段（第 1 周）：三个岗位独立跑，各自都能完成任务，但各岗位之间没有信息流动——数据分析师不知道客服处理了什么，客服也不知道哪些话术该优化。
调整后（第 2 周）：
客服专员每条对话自动存档 → 数据分析师每日提取 →
发现「退换货场景的客户满意度最低」
→ 分析具体原因：话术太生硬、缺乏共情
→ 建议升级专员重新设计退换货安抚话术模板
→ 客服专员接到新模板后重新测试
长程运行 30 天结果：
| 指标 | 第 1 周 | 第 4 周 |
|---|---|---|
| 客服闭环率 | 81% | 85% |
| 客户 NPS | 42 | 55 |
| 人工介入率 | 25% | 15% |
| 异常自恢复次数 | 0（需人工） | 4 次自动处理 |
| 数据分析师提出有效建议 | 0 | 7 条，采纳 5 条 |
简历句： 3 个数字员工岗位协作，客服 NPS 从 42 提升至 55，人工介入率从 25% 降至 15%，数据分析师驱动的优化闭环持续运转。
案例 2：餐饮连锁——多门店运营中枢
背景： 一家 12 家分店的连锁快餐，店长每天盯排班、盯库存、回点评、处理差评，精力极度分散。尝试用 3 个数字员工岗位协作代替店长手动管理。
岗位组成：
| 岗位 | 职责 |
|---|---|
| 运营值班专员 | 排班、生成交接班记录、监测门店运营指标 |
| 库存补货专员 | 预测备货、生成缺货预警、输出采购建议 |
| 口碑维护专员 | 识别差评、生成回复话术、汇总顾客反馈 |
协作流程：
运营专员每天早晨输出各店排班和营收预测
→ 库存专员基于营收预测调整备货建议
→ 口碑专员监测各平台（美团/大众点评/小红书）差评
→ 差评涉及某款菜品时 → 通知库存专员检查该食材备货
→ 涉及服务问题时 → 通知运营专员调整排班（高峰期人手不够）
关键设计： 三个岗位之间不是线性流水线，而是网状协作——口碑专员的发现能同时触发库存和运营的调整。
运行 90 天结果：
| 指标 | 前（人工） | 后（数字员工 Company） |
|---|---|---|
| 店长每天管理耗时 | 6 小时 | 1.5 小时（只看报告和异常） |
| 差评响应时间 | 平均 4 小时 | 平均 15 分钟 |
| 缺货发生率 | 8% | 3% |
| 异常自恢复率 | 0% | 65% |
简历句： 12 家门店的店长管理耗时从 6 小时降到 1.5 小时，差评响应从 4 小时压到 15 分钟。
五、运行效果怎么评估
| 维度 | 看什么 | 简历式说法 |
|---|---|---|
| 完成度 | 复杂目标最终达成到什么程度 | 「月投诉率从 6% 降到 2.4%」 |
| 稳定性 | 长程运行中断/出错次数 | 「连续运行 72 小时，异常自恢复 5 次，零人工介入」 |
| 自我修正能力 | 出错后能否自己纠回 | 「异常自愈率 65%」 |
| 协作损耗 | 岗位交接是否丢信息 | 「交接返工率从 20% 降到 5%」 |
评测后产出运行优化报告：哪层是瓶颈、下一步怎么改。
完整的三层量化评估方法论见 07 · 数字员工效果评测。
六、常见误区
| 误区 | 表现 | 为什么错 |
|---|---|---|
| 过早组公司 | 单岗位能干好的事非要拆成多岗位 | 协作是有成本的——三个岗位信息没传好，不如一个岗位直接处理 |
| 交接丢上下文 | 岗位之间传递信息不完整 | 客户被转来转去，每次都要重说一遍 |
| 只求跑通不求长程 | 演示一次成功就以为完成 | 长时间运行中的累积错误和偏离才是真正的考验 |
| 没有自我修正 | 一旦某一步出错，整条链路一路错到底 | 异常不纠偏，越跑越偏 |
| 岗位拆得太细 | 把 3 个能干的事拆成 8 个岗位 | 协调成本大于分工收益 |
| 没有数据分析岗位 | 客服 + 升级双岗位，但没有分析角色 | 不知道哪里该优化、怎么优化——团队在跑但没有在进步 |
七、与其他工具的关系
- 上游：03 · Post 岗位层——每个 Post 先独立跑稳，再组 Company
- 上游：05 · 细化分析法——从行业拆出公司级协作需求
- 瓶颈诊断：Company 出问题 → 查 Post 职责和协作；Post 出问题 → 查 Skill → 02 · Skill 层
- 配套：07 · 数字员工效果评测——Company 层量化指标（完成度、稳定性、自愈率）
八、下一步
Company 建在 Post 之上，Post 建在 Skill 之上。想知道整套怎么从行业一路拆到每个技能 → 05 · 从行业到员工的细化分析法