接手之前
不是没有系统，是信息在部门之间断掉
门店的事实，总部要等
每家店各自记账、各自报表，到总部是隔天甚至隔周的汇总表。总部看到的是一个被整理过的版本，中间被谁修过一次，事后谁也说不清。
要问「昨天哪家店退货最多」，得先等人做表
同一件事，七个部门各做一遍
一单生意从到店接待、下单、开票、入账、排产到售后，信息在七个部门之间靠截图和群消息传。每一次交接都要有人重新录一遍，错一次就在下一个部门被发现。
录入的时间比处理的时间长
线上线下是两本账
独立站的订单、商品、内容在一套后台，门店的客流、样品、调货在另一套（或者根本没有系统）。同一个客户在线上看过什么、在店里试过什么，两边对不上。
最值钱的那条线索，从来没被接起来
想加个小功能，排不上队
业务部门每个月都能想出几件能省半天的小事，但每一件都要走同一个开发队列。排到的时候，那件事的做法常常已经变了。
不是开发不够快，是所有小事共用一个队列
七个部门
每个部门实际接走了哪些动作
财务
- 采购单、发票、对账单抽取入表，不再手敲
- 门店流水与系统订单自动比对，只推对不上的那几条
- 费用合规预审：超标、缺票、重复报销当场标出
- 账龄与回款提醒按客户分级发出
- 月结数据汇总与报表草稿
留给人：付款与放账的批准、差异的定性、税务口径——一件没交出去。
人事
- 招聘渠道进来的简历初筛与结构化，按门店岗位要求排序
- 面试安排与候选人状态同步，不再有人被漏掉
- 入离职手续清单自动派发，各部门各收自己那一条
- 多门店考勤与排班异常自动挑出
- 制度问答：假期、报销、社保、门店补贴怎么算
留给人：录用、定级、绩效、谈话，以及所有涉及人的例外。
研发
- 业务部门的需求与门店反馈收敛成工单：归类、去重、关联已有模块
- 接口与配置说明随代码更新，不再是半年前那一版
- 代码初稿、测试用例、数据迁移脚本
- 线上异常日志聚类，自动翻出相似历史问题与当时的解法
- 发布说明与变更记录自动成稿
留给人：架构与选型、取舍排序、故障定性与回滚决定；评审一分钟没省。
销售业务
- 线索去重、打分与分配到人
- 客户背景与历史往来自动汇总成一页纸
- 跟进节奏提醒，到期未跟进自动升级给主管
- 报价单与合同文书起草
- 成交与失单原因回填，按原因归类
留给人：谈判、让价、关系维护，以及最后发出去的那一版报价。
电商业务
- 商品上新管线：成稿 → 配图 → 上架，人工只做终审
- 多语种内容与术语同步
- 客服首轮应答，答不上来转人工
- 订单异常与站点健康度自动预警
- 站内与投放数据归集成一张看板
留给人：定价、活动、渠道策略，以及需要让步的那一类客诉。
设计开发
- 产品图批量重绘、去背、换场景、统一光影
- 主图 / 详情 / 社媒多尺寸一次导出
- 场景效果图与短视频素材批量生成
- 按品牌视觉规范锁定风格，整批不跑偏
- 素材归档与按属性检索，找图不用再翻文件夹
留给人：定视觉规范本身、每批挑片、实物拍摄。
门店管理
- 每日营业数据汇总与异常提示：客流、成交、退换
- 到店接待记录结构化，跟进任务自动派到具体的人
- 样品与库存盘点清单、跨店调货申请自动流转
- 巡检照片与整改项归档，逾期自动提醒
- 导购随时能问的产品知识与话术，答案带出处
留给人：现场接待与议价、排班裁量、陈列与活动的决定、投诉的现场处理。
这一页为什么没有数字
不是漏了，是写了就会把别处的数字一起拖下水
客户知道它变快了，但没有一个双方都认的口径
内部岗位的效率没有像订单量那样的天然计数器。「报销从隔周变成当天」这种说法客户自己说得出来，但它不是一个能被第三方核对的数字——折算成百分比的那一步，一定是估的。
所以我们一个都不写
站上另外一页（跨境电商那套）的每条数字都标了出处，正因为那一页是真的可核对的。只要在这一页编一个漂亮的数，那些能核对的也会一起贬值。这笔账不划算。
你真正该问的也不是百分比
问这个更有用：这件事每周重复多少遍、做错一次代价多大、谁在等谁。这三个问题用你自己的数据就能答，答完你会比看任何案例数字都清楚它值不值。
写案例时我们守三条：不写品牌名与所属行业、没有可核对出处的数字一个不写、不放后台截图。这一页是这三条同时生效的样子。
交付之后
现在是他们自己在往上加
新岗位，他们自己配一个 Agent
平台在客户手上：新开一个岗位、想给它配个帮手，在界面上把触发、规则、出口和人工卡点逐项选好就行。日常这些他们自己做起来更快，遇到拿不准的再一起看。
新配的先陪它跑一段
默认只给建议、不动真数据，确认判断稳了再放开写入。先看准再放手，上手的人心里有底，这件事才铺得开。
提示词现在是他们自己在改
交付时按部门成册，并到现场分场带着写过，之后又跟了一段。现在话术与规则的日常调整由各部门自己做，当天就能落地。
系统建在他们自己的服务器上
从第一天起就装在客户自有的服务器里，源码与数据都在他们手上。需要我们搭把手时由他们开权限，事情办完再收回——谁在什么时候动过什么，双方都清楚。
这是第三套建在客户自有服务器上的系统。和前两套一样：源码进他们的仓库，日常由他们自己的人维护；需要我们搭把手的时候，开权限、办完事、再收回。
什么时候用不上
这件事有明确的边界
流程还在天天变的部门 规矩没定型就自动化，只会更快地产生混乱。那种部门我们会建议先别动。
只想先上一个部门看看的 完全可以，只是那更接近单模块起步，按这条线的范围谈反而不划算——我们会直接说。
指望它替代 ERP / 人事系统的 它叠在那些系统上面，从它们读、往它们写，不取代它们。
把「减编制」当项目目标的 这套系统划走的是动作，不是人。拿它当裁员工具，落地时一定被消极对待。
常见问题
你大概率会问的几个问题
七个部门是一次做完的吗？+
不是，一次做完这件事本身也很难成。先做的是重复量最大、而且做错了能改回来的那一块，跑顺之后再往外接下一个部门。这个顺序不是技术考虑，是推动力考虑：第一个部门跑出来的运行记录，是说服第二个部门的唯一有效材料——比任何方案书都有效。底座只建一次，所以从第二个部门开始明显轻，但「轻多少」我们不给数字，那取决于那个部门的数据现状。
线下门店那一块，一线真的会用吗？+
这是这类项目最大的落地风险，比技术大得多。做法上有两条是硬的：入口放在他们本来就在用的沟通工具里，不装 App、不记新密码；先上的一定是替他省时间的那部分（问产品知识、自动生成盘点清单），统计与监控放在后面。顺序搞反过的项目我们见过结果——东西做得再好，一线也会把它当成一个用来考核自己的东西，然后集体不用。
产品自动上架和图片生成这部分，和你们其它案例重复吗？+
做法是同一套，所以这一页不再展开讲第二遍——它在这家客户的流程里只是「电商业务」那一格里的两条。想看这一块本身怎么做、边界在哪，去看视觉资产工厂那条线和营销内容管线那个案例，写得比这里细。
交付之后，他们加新东西还要找你们吗？+
日常那些不用：平台和源码都在他们手上，配一个新的岗位 Agent，把触发、规则、出口和人工卡点在界面上选好就行。会一起坐下来谈的是另一类——接一个还没接过的外部系统，或者想要平台目前还没有的能力。这类范围与计价在动手之前谈妥，不会等上线之后才提。