“大家都能用”往往是最危险的需求
销售想让 AI 根据客户情况准备跟进话术，客服想快速查售后规则，运营则要批量整理活动内容。管理层看三个部门都需要问答和生成，便决定做一个统一助手。上线时功能很多，员工打开后却不知道该从哪里开始，问同一个产品问题还会得到不适合自己岗位的答案。
问题不在部门多，而在任务目标不同。销售的回答要推动下一步沟通，客服的回答要准确执行政策，运营的内容要符合公开表达。把三类任务放在同一提示、同一权限和同一输出里，系统只能给出最安全、最通用的答案，结果谁都觉得不够贴近工作。
冲突通常出现在口径、权限和动作三处
销售可以看到客户历史和报价范围，运营不一定需要；客服能查售后细则，却不能随意承诺折扣。即使引用同一份产品资料，不同岗位的可见字段和可执行动作也不一样。权限如果做得过宽有风险，做得过窄又会让答案失去价值。
输出后的动作也不同。销售需要把结果写回客户记录，客服要生成工单并保留证据，运营要进入审核和发布流程。一个孤立聊天框只能给出文字，无法接住三个部门各自的下一步，员工自然又回到原来的表格和系统。
- 先按岗位列出真实任务，不从通用功能开始。
- 明确每个角色能看什么、能改什么、能执行什么。
- 让结果进入原业务系统，减少复制和二次录入。
共享底座，分开入口和规则
企业不必真的开发三套完全独立系统。产品资料、公司政策和客户主数据可以共用，但入口按角色设计。销售看到客户跟进和方案准备，客服看到工单查询和回复草稿，运营看到选题、素材和审核。底层知识共享，检索范围、模板和动作各自配置。
跨部门内容还需要明确主责。例如产品参数由产品部门维护，售后规则由客服负责人确认，公开品牌口径由运营审核。AI 可以调用这些资料，却不能替企业决定哪份文件是最终版本。主责清楚后，多个助手才能围绕同一事实工作。
先让一个部门用顺，再复制方法
预算有限时，不要一开始同时铺三个部门。选一个高频、数据相对完整、负责人愿意参与的场景，跑通任务、权限、复核和回写。等指标稳定后，再把可复用的知识底座和技术组件扩展到其他部门。
企业 AI 的规模化不是把同一个助手账号发给更多人，而是让共享能力在不同工作里正确发挥作用。一个入口看起来省事，三个部门返工却更贵。分角色设计多花一点前期时间，后续采用和治理会轻松得多。
要点总结
- 可以共用基础资料，但应按角色配置检索范围、权限、模板和后续动作。
- 通常因为任务目标、使用者、数据范围和输出标准没有具体定义。
- 优先选择任务高频、样本充足、结果可检查且有明确负责人的部门。
参考来源说明
本文围绕“一个 AI 助手服务三个部门，为什么最后谁都觉得不好用”展开，结合 5 份公开资料及一路凯歌在“企业 AI 服务”方向的执行经验整理，重点看它对官网可引用结构、FAQ 设计和后续获客复盘的影响。